The Pro’s of Native App Development

  • “Native vs. Web?”
  • “HTML5 is the FUTURE!”
  • “The App Store is just for distribution!”
  • “Android is taking over and all the screens are different sizes!”

Heard it around the traps lately? Same. Here’s my rational as to why I’ll vote for native app development over developing a mobile web app (and putting it within a wrapper for distribution via the App Store or Android Marketplace). My opinion might change over the next few years, but these reasons are for now.

Offline/low connectivity access:

If a user has a poor connection (or none at all) and your application is HTML within a wrapper, most functionality of the app will almost always be unusable. If your app has important functionality like personalisation, that experience is unacceptable. Content should always be available for viewing offline or when a user has a poor connection, something which is difficult to achieve via anything other than a native app.

Clearer error messaging:

Error messaging on the mobile web (and within a wrapper) can be unclear and frustrating for users. Within a native app, notification windows can be used to clearly explain to a user what is wrong. Options can then be provided to a user at the touch of a button.

Push notification functionality:

When developing a native app you have access to the full push notification functionality of a device. With the recent updates to notifications on iOS 5 and how Android has handled notifications so well in recent times, this is something that cannot be overlooked. Getting important information to users without them having to use the mobile web is critical.

Overall performance improvements:

It’s quite clear that through building a native app there are significant increases in performance across the whole app. This can range from the initial loading of a splash screen and onto the home screen, right through to the rendering of core content pages.

Full suite of gestural interactions (swipe, pinch/zoom etc):

It’s fairly self explanatory but by going native you get all the touch interaction gesture features which make mobile apps fun and so easy to use. These interactions are often classed as “polish” as if it’s a negative thing, but I believe it’s these experiences which keep users coming back to applications (that do it well) over and over.

Device integration:

Native apps allow better integration with all the functionality that a mobile device presents users. GPS, the camera, voice recorder and tapping into a users contact list are examples of capabilities that can be directly hooked up with the front end and capitalised on.

Bottom line:

The success of any application is almost 100% dependant on user engagement. The way to engage users is to create great experiences. How many successful apps do you use are available via the mobile web and not an App Store?1 Would Foursquare, Instagram, and Flipboard have been so successful if they had simply delivered a mobile web app in a wrapper? I doubt it.

(image credit)


1. Worth noting: I’m not suggesting that native app development is the only way to move forward. Your mobile web app and native app should compliment each other.

iOS: Updating Two Single Applications to a Universal Application


I was recently working for an organisation where “The Business” (I hate that term, but I’ll stick with it throughout this article as that’s what they’re commonly referred to at said organisation) wanted to take their separate iPhone app and iPad app, and merge them to create one “universal” app for the App store. What they didn’t realise was, it’s not very easy. I’m going to try explain how I believe it can be done in a few clear steps, using XE Currency as a case study.

Going Universal:

It makes sense to go universal when beginning development for iOS. The benefits are clear. When a user searches for your company name or brand name in the App Store, only one app will be returned in search results. Once they’ve downloaded your universal application, the app can determine what device the user is on (i.e. an iPad, iPhone 4, or iPhone 3GS) and launch the correct experience. It’s also easier with a universal app to manage updates and roll out new features to all users, no matter what their device of choice is.

The Issue:

Unfortunately a lot of organisations have an issue where users will search for their app by name, via the iPad App Store app, or via iTunes, and both their iPhone and iPad apps are returned in results.* Why? They probably built their iPhone app within a year or so after the 3GS was released and the App Store was launched. Then along came the iPad, so they went and built an iPad app in a separate code base. The two apps are not related to each other in many ways, apart from the fact that they may be served from the same build box, or use the same API or something.

The organisation then tries to be clever and name their iPad app with some distinction from their existing iPhone offering, using terms like “HD” or “for iPad” in the name, but the icon, description, and features are usually very similar. This is the root cause of the issue.

The Solution:

So, when “The Business” asks to go “universal”, what can you do? Basically, it comes down to 4 steps:

  1. Identify the app with the the highest amount of downloads.
  2. Add the code from the less popular app to the code of the more popular app – this is now your universal app.
  3. Release an update of the universal app, with a new description that explains the change (update the icon and screenshots too if necessary).
  4. Update the description of the less popular app advising users to remove that current version of the app and download the new universal app, which is now available.

Why does the number of downloads for each app matter? Because the app you choose to not be the basis of your universal app will lose support over time (bug fixes, new features etc) and will therefore need to be deleted by all the users who have that version. In order to use your app again, those users will have to then search for your universal app and install again. You want to inflict that hassle on the least amount of your users as possible, hence selecting the least popular of your two apps for removal.

Case Study:

To make more sense of these steps, let’s follow them through with a real-life example: XE Currency.

Step One: Identify the app with the highest amount of downloads.

This is just a guess as I’m not involved with the XE Currency iOS team at all, but I’m fairly sure that their iPhone app will have received more downloads than their iPad app based on the number of iPhones/iPod Touch’s shipped over the last 3-4 years vs. the number of iPads over the same time period. I don’t know of many iPad app’s which have higher download numbers than their iPhone siblings.

Step Two: Add the code from the less popular app to the code of the more popular app – this is now your universal app.

The team behind XE Currency then merged the code of their less popular iPad app with the code of their more popular iPhone app.

Step Three: Release an update of the more popular (now universal) app, with a new description that explains the change (update the app’s icon and screenshots if necessary).

The XE Currency iPhone app update was then available in the App Store to all existing iPhone users, with information about their shift to universal highlighted in the update text: iPhone and iPad apps combined into universal app:

Step Four: Update the description of the less popular app, advising users to remove the current version of the app and download the new universal app, which is now available.

The XE Currency iPad app was then updated with a new description and icon, which highlights the move to universal. The description clearly states to new users that they should search and download the new universal app, with a different name, which is now available. Note the new icon’s use of an “!” to alert users of the change:

What’s Next?

Once you’ve completed the above steps, it will pay to monitor the level of usage from your now “old” app to see if people haven’t updated, or simply haven’t seen the new updates and are still carrying on their merry way. If usage carries on, it may pay to push out another update reminding users of the change – and then (depending on the level of success of the universal app) give up on them. Seriously, a line has to be drawn somewhere and you can only support two code bases etc for so long before cost outweighs the benefits.

In the future, I hope Apple makes this process easier as iOS 5 brings over the air updates which may facilitate some sort of automation around merging apps to one universal app. In the meantime, the benefits of going universal are clear and despite the short term hassle for your users (which may result in a drop in usage or a few negative tweets etc), you’re well positioned to release feature updates and bug fixes for all devices and users ongoing. There’s also the chance that Apple may release new products in the future, which will require a consolidated approach (did someone say an App Store for Apple TV?).

If you found this article useful, interesting, or disagree in any way, feel free to comment below.

*Searching the App Store on an iPhone will only return iPhone compatible apps, so the iPhone isn’t a problem scenario.