The trouble with this debate is that it is a moving target. Every few months the landscape changes and the decision need to be reevaluated. Each presents advantages and disadvantages, but those lines are quickly blurring.
- Natural device interface. Consistent with the overall user experience for the device. Means using an app should be familiar.
- Access to device hardware and software. Phones, GPS, persistence, phone book, calendar, etc, etc. are all accessible when using native API
- Having all the code on the machine means only the data needs to change.
- Business logic sits inside the app. Accessing the server is only secondary.
- Power. Running directly on the machines CPU gives the app strong processing power and encryption abilities
- Lighter. Access to the native API’s means rich User Interfaces without any added bulk. A lot of choices and flexibility in the UI widgets to use
- Since app sits on machine, no need for sometimes expensive data access
- App works even when no access to internet
- Development– Each device needs to be developed separately!
- Learning Curve– Each device has it’s own quirks and catches and programming model. This takes time to learn.
- Objective-C – iPhone apps are written in objective c!
- Maintenance– Native for each device means maintaining different apps written in different programming languages
- Updates– Since the app sits on user machines pushing an update requires the user to reload the app. Can lead to app fragmentation, since not all users will update at the same time
- Cross-Platform. One app- all devices.
- Full control over the content. Since user needs to access server for content, constantly decide what to deliver.
- Dynamic– Interfaces, content, features, can very easily be added/removed based on the user
- Updates– Updating the version is invisible to the user. Just need to restart the server and the user instantly has access to latest version
- Less consistent with the user experience with the device since there will be a single site for all devices
- Unpredictability– Since different users with different size screens, hardware- hard to know how the app will look and perform (partially true for native apps as well)
- Look and Feel– Hard to get a web site to look and feel like a native app
- Touch– web wasn’t made for touch
- Speed– Slower since all content needs to be retrieved from server. Two hits- one data retrieval is slower on mobile, server needs to send process the request
- Limited access to hardware accessories and other apps features of the phone (phonebook, etc)
Many of these positions are quickly becoming no longer relevant. Web apps are very quickly gaining speed. The powerful cons against native apps, namely cross-platform and learning curve means most companies cannot afford to develop and maintain two (or more) apps. However, the historically awful user experience for mobile web-pages left little alternative.
Html5- How does this help?
Html5 capabilities are changing the landscape a bit.
- Offline mode– The app can be downloaded to the device and only refresh itself when a manifest file changes. Solves partial speed problem while still leaving open ability to easily upgrade the app
- Powerful new UI capabilities. Widgets got smarter and the phones already support this. For example form type email on iPhone automatically displays a email optimized keyboard. CSS3 is a game changer.
- Persistence– HTML5 allows local storage beyond just cookies
- Geocoding– Easy access to GPS information
The magic bullet?
Obviously not, even with HTML5 web apps, most of the cons against Web Apps persist. The youtube.com Android app is still easier to use than the mobile optimized site. However, the advantages of native are not significant enough to most users whereas the company developing these apps can save a significant amount of money by writing and maintaining only one app.
It should be noted that there are a many solutions out there that look to bridge the gap.
- Cross-platform maintenance. Since same core code is inserted into each app
- Access to hardware
- Some speed– Code is stored on the machine (this is both good and bad), though not compiled into lower level languages
- User Interface (UI) & UX (User experience) Essentially a website inserted into an app. Doesn’t use the native UI widgets.
This is only a partial solution, to be used with other solutions. See: http://www.phonegap.com/
Mobile Build Frameworks
Similar to Phonegap in principal, but these can take many different directions. These tools allow developers to write their app in the language of the tool (which varies) and use the tool’s IDE and API’s. The app will then be compiled into native language using the native UI widget sets.
I have never seriously looked into any of these solutions. I have always been quickly turned off by their walled garden approach of using their tools and IDE’s and their expensive proprietorial nature. Smelled too much like “vender lock-in”. But there a lot out there, so somebody must like these ideas. For example- http://www.appcelerator.com/, http://pyxismobile.com/ and others.
- User interface look and feel, and user interactions.
See http://www.phonegap.com/tools for a list of these types of frameworks. Hopefully another blog entry about my experiences with these frameworks another time.
As of today (mid 2011), I would timidly say apps that need good processing speed (e.g. encryption) and don’t change frequently should be made using native code.
Apps that require a lot of data coming from servers, changes frequently, need to target a lot of different devices, and do not require a lot of processing power should be a web app.
But in the end it will probably come down to a question of finance and developer know-how.