Native Vs Web
Are web apps a one-size-fits-all solution to a multi-platform app?
Since HTML5, web apps have been touted as a one-size-fits-all solution to a multi-platform app. Yet even the strongest supporters of this strategy have become disillusioned, and recognize that native development remains the best means of creating quality mobile apps.
Why native, (in a nutshell)?
It is the best means of addressing differences in operating systems, hardware, and user expectations. It is also the only way of effectively managing limited mobile memory and processing power.
User interfaces should be carefully tailored to the device. An app on Android that acts like an iOS app will fail to behave the way users expect, meaning very dissatisfied users. Neither is a phone app likely to succeed for tablet - the screensizes and use cases are too different.
Are web apps ever a good idea?
If you are presenting simple content (images and text), and do not need to use any of the native hardware of the device, then yes, a web app may be appropriate. One advantage to web content can be the ability to change it without resubmitting an app. If you want to harness native features but have flexible content control like this, we can use some web elements within your native app as entry points for this content.
But isn't everyone moving to web apps?
Facebook, a web-based company, did try a web app - but they switched back to native after a huge investment of time any money, in order to enhance the user experience. 1
“Betting completely on HTML5 is one of the, if not the biggest, strategic mistakes we’ve made”
- Mark Zuckerberg 2
LinkedIn, also a web based company, switched back to native because it was impossible to debug memory-related problems, and they could not make animations smooth enough. 3
Xero, an accounting software company, switched back after 2 years of developing a web app. They found too much time was spent fixing browser-specific bugs. 4
Don't web apps mean a simpler, one-size-fits-all solution?
On top of device/OS fragmentation, you also now have to contend with browser fragmentation. As Steve Pinches, product head of the successful Financial Times web app, said: “...Does the Web gracefully work on multiple screen sizes and browser stacks? Unfortunately not." 5 It's difficult work and even then will not work on every device.
Some features are also native-only, requiring a custom wrapper for each platform.
Surely web apps are at least faster and cheaper to build?
For basic pages, perhaps. Once features, navigation and animations are needed, a huge, timely effort is required to fake native behaviour and ensure cross browser functionality.
The Financial Times web app is one example of a beautifully executed web app. However, the version for iOS took 5 developers approximately 6 months - the Android app was not released til a year later. 6
“The cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go”
- Xero, upon switching back to a native app 7
Will users even notice the difference?
Web apps are slower. Javascript in a browser is 6-10x slower than native code. 8
“...we realized that when it comes to platforms like iOS, people expect a fast, reliable experience... One of the biggest advantages we've gained from building on native iOS has been the ability to make the app fast."
- Jonathan Dann, Lead Facebook developer 9
With poor internet connections, web apps can fail in unexpected ways. Since they have no explicit memory management, they also quickly run out of memory and crash.
Plus, since web apps have no thread-management, UI-updates have to compete with network/data processing for valuable CPU time – leading to sluggish/unresponsive UI.
Aren't web apps easier to maintain?
"Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex."
- Matt Vickers, Xero developer 10
Debugging is extremely difficult for a web app. Memory leaks are untrackable, and if not initially an issue, the inability to explicitly manage memory may become a major problem as the app grows and gains users.
OS updates can even break web apps. E.g., IOS 7 eliminated the ability for web developers to hide the address bar programatically, and broke the ability to request more than 5MB of local storage. Android 3.0 also broke commonly relied on web app tools. It is clear web compatibility is not the concern of these companies.
In Summary:
Going web means: HIGHER fragmentation, higher costs for less features, a slower app, unsolvable bugs, and ongoing future headaches.
While going native means: LESS fragmentation, an established method for delivering a great mobile experience, enhanced hardware/software features, works offline, smoother animations and faster UI response, consistent behaviour, fewer on-going maintenance headaches, simpler development solutions (instead of trying to mimic tools already made by Apple & Google).