So you want to make an app. The most basic technical question you’ll need to answer is: native app or web-app? What’s the difference though, and why should you care? And isn’t a web-app just a website? Read on.
Definitions
A native app is a piece of software installed onto your device. It is downloaded from your phone’s app store – the iTunes App Store for iPhones and Google Play for Android phones. Apps are interactive. Most people who use Facebook or Twitter on their mobile use the native apps.
To explain web apps, we must begin with their predecessor: traditional webpages. They are just that: a series of pages connected by links. Most sites on the internet are still organised this way – especially those of smaller companies. However, this form of user experience isn’t suited to interactive products like Facebook and Twitter.
With Facebook and Twitter, you never really know when you’ve ‘changed page’. Messaging, for example, is often done through just a part of your screen. You navigate around these sites like they’re an app. That’s what makes them a web app.
Dipping our toes in technical waters
Hi, my name is Samsung and I speak a language called Java. I don’t understand iPhone language. I am learning a web language called HTML5 though. HTML5 is like the Esperanto of devices.
That is my crude parallel between our students and their devices. When we make an app, we can either make it in a device’s native language (a native app) or we can make it in their second language (a web app).
User experience
OK now some basics are out of the way, let’s focus on the most important thing: how does this affect your users?
Hi, my name is iPhone and I will respond better if you are nice enough to speak to me in my own language.
Put simply, the user experience of a native app is superior to that of a web app. A native app responds more quickly to interaction than a web app. A native app is loaded from the phone itself; a web app needs to be loaded from the Internet each time it is accessed. Web apps can’t usually access phone features like the microphone, the camera, or the calendar.
However, finding a web app is far easier. Google searches are far more common than App Store searches. It is simpler to open a web app than to download a native app: you simply press on the link.
Reach
A perfect user experience on your Android app is nothing if you can’t reach anyone with it. A native Android app will only work on Android devices. Your app may be perfect, but what if your users are in a market with iPhones? Maybe you’re not even sure if your users are mobile or desktop yet (or if you have users!). Are you ready to commit to one group of devices? Are you willing to risk enough money to build for both iPhone and Android?
A web app gives you the flexibility to put off these decisions. A web app, well-designed and tested, can work on any device. If you can’t build a market on any device, why build for a subset?
Design
Design is difficult, regardless of whether it’s a web app or a native app.
Designing for native apps means multiple designs for a known set of screen sizes. Think about how many different-sized Samsung phones you’ve seen, and that gives you some idea.
Designing for web apps means one or more designs for everything from the smallest phone to a desktop. This is usually through Responsive Design.
Testing
All these screen sizes need to be tested with both native apps and web apps.
The complicating factor here is that testing a web app is more complex. When any device, using any browser (Chrome, Firefox, etc) can access your app (and try to understand web Esperanto), decisions need to be made about which
- features are well supported across the ecosystem
- browsers/devices your market is using
- browsers are simply too non-standard to support (eg Internet Explorer)
In the next instalment I’ll talk about how this decision affects product development and business model, and a way to make a web-app work like a native app (just to confuse the issue further). Also, if anyone is interested, I’ll delve into some of the technical details of the technologies I’ve skipped over in this post. As usual, let me know below.
Featured Photo Credit: <a href=”http://www.flickr.com/photos/9078261@N07/5161185416/”>Nimbuzz</a> via <a href=”http://compfight.com”>Compfight</a> <a href=”http://creativecommons.org/licenses/by/2.0/”>cc</a>. Text and recolouring by eltjam.
Thanks Lindsay for an interesting spotlight on a confusing area. Web apps have always looked like the poor relations of Native Apps, but they have a distinct advantage in terms of cost and coverage, and so appeal to small operators – like displaced elt writers. Looking forward to your next post.
Looking forward to the second installment.
Thanks Lindsay for an informative and fun article. I particularly enjoyed the conversations with Samsung and iPhone (!) In your next installment, it would be great if you could expand a bit more on design and testing, perhaps with some examples. Yes, please share your experience with the technical aspects of the technologies you’ve used to develop your own apps. Thanks for sharing.