There have been a couple of interesting contributions in the last week to the ongoing HTML5 vs native mobile app debate. Firstly, Compuware APM published some research that indicates that 85% of smartphone users prefer to use native apps rather than mobile web apps. Secondly, the team behind the popular accounting software Xero announced that they are switching focus to native apps following difficulties in delivering an acceptable mobile web offering.

The Xero team were keen to exploit their existing web development talents when building a mobile version and acknowledge that this, not user experience, was their primary justification for choosing the HTML5 route. But when their efforts failed to yield acceptable results they changed tack:

Xero prides itself on not compromising on customer experience, and when it comes down to it, the question isn’t “How can we use our existing skills to build a mobile application?” but “What is going to enable us to deliver the best customer experience on the mobile devices that our customers use?”

This is a similar conclusion to that reached by Facebook last year when it replaced HTML5 with native on iOS.

As we’ve mentioned previously, one of the key promises of HTML5 is that you can build one app that works everywhere. If you’re targeting multiple mobile platforms this is supposed to make it easier as you don’t have to duplicate effort by creating native apps for each operating system. What’s interesting about the Xero announcement is that they’ve acknowledged that the reality is somewhat different. They’ve concluded that with the current state of the tools and mobile web browsers they would have to put in more effort than it would take to build native apps:

…the lesson we’ve learnt over the last 12 months has been that 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.

Current trends show that the mobile market is consolidating on just two major platforms, with Google and Apple squeezing out BlackBerry, Microsoft and others. That makes focusing on just the big two a viable mobile strategy. And if there are only two platforms that really count then, as things stand at present, native apps are the way to go.

The picture will of course change as the HTML5 ecosystem matures but for the likes of BlackBerry and Microsoft that can’t happen soon enough. Right now developers may well choose an excellent experience for ~90% of users over a mediocre one for everybody.

iOS 5.0 and Android 4.0 were unveiled a week apart in October 2011. 15 months later the Apple offering has achieved near universal uptake (over 96% according to some third-party figures) whereas the majority of users of Google’s OS are still waiting. Many will never receive an upgrade for their current devices.

With less than 40% of Android users running Ice Cream Sandwich (Android 4.0) or Jelly Bean (Android 4.1/4.2), app developers find themselves having to support outdated versions of the operating system in order to reach the widest audience of Android users. To be runnable by 90% or more of users, an Android app must run on Android 2.2 (Froyo), an OS that is four months short of its third birthday. iOS developers on the other hand need only support a 10-month-old version (iOS 5.1) in order to reach the same percentage of users.

This pattern seems set to continue (iOS 6 already has twice the penetration of Android 4.x despite being only four months old) and while it does Android developers will not be able to rely on recent OS features if they intend their app to be usable by the majority. In contrast, an iOS app developer can happily forget about the limitations of all but the last couple of versions of the platform, which leads to a much more straightforward development process with far fewer workarounds and compromises.

With many Android device manufacturers failing to provide updates for older phones, existing Android users are typically only getting the new OS when they upgrade to new hardware. At that pace it is likely to be mid 2014 before app developers can consider dumping Android 2.x completely.

Today I attended Day 1 of Apps World at Earls Court in London. Events such as this provide a useful snapshot of the current state of the mobile app economy. Listening to the talks and seeing who is exhibiting you notice certain trends.

Whereas 12 months ago you might have expected similar events to be inundated with mobile ad companies, this year the focus appears to be more on solving the more pressing problem of discoverability. With over one million different apps available on the two leading app stores, making sure that users actually find your offering in the deluge of alternatives is paramount. Whatever your monetisation strategy, it can only be effective if you can attract enough users.

The other thing that was immediately obvious is that both RIM and Microsoft are investing heavily in wooing developers to build apps for their platforms. The two companies are currently fighting for a distant third place, behind Android and iOS, in both platform market share and developer mind share.

Microsoft is pushing Windows 8 hard, and with it attempting to blur the distinction between desktop/laptop computers and tablets. This differs from the iOS/Android approach that treats tablets as very different devices to PCs with very different operating systems. With Windows 8 it seems it is the smartphone that is more the odd-one-out in the trio of device types, although the picture isn’t complete since the Windows Phone 8 development tools haven’t been unveiled yet. The non-phone Windows 8 is available to the general public at the end of this month.

RIM is betting everything on its still-not-quite-ready-yet BlackBerry 10 operating system. Perhaps most significantly, it is offering the most eye-catching incentive for app developers on any platform. The Canadian company guarantees that your paid-for native BlackBerry app will make at least $10,000 in revenue. If it doesn’t RIM will write you a cheque for the difference (so long as you were able to generate at least $1,000 in 12 months).

Developer Relations VP Alec Saunders reiterated that Java is now dead on BlackBerry. It remains to be seen whether existing BlackBerry Java developers will migrate to the new BlackBerry developer tools, as RIM hopes, or instead jump ship to Android where their Java skills are more transferable. RIM may also have inadvertently pushed developers towards an Android-only future by providing the ability for BlackBerry 10 to run repackaged Android apps, thereby obviating any pressing need for a native BlackBerry app.

On a related note, the Apps World organisers did RIM no favours by scheduling the BlackBerry talks beneath the imposing figure of a giant inflatable Android. The symbolism was inescapable.

I was interested to read (via the Guardian) that Facebook has replaced its HTML5 mobile web app with a native app for the iPhone and iPad and is most likely preparing to introduce a native Android app too.

This is significant because there has been a growing trend for companies to favour mobile web apps over native apps (that is apps tailored specifically to one mobile platform, such as iOS, Android or BlackBerry, using tools and technologies that are incompatible with the other platforms). The obvious attraction of the web-based approach is that a single application will, in theory, work across all major smartphones and tablets, regardless of which operating system they run. Facebook’s move is an acknowledgement that while this is clearly a cost-effective way of reaching the widest user base, it does not offer the best possible user experience:

“So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth.”

That native apps offer the potential for the richest user experience is not controversial. Being tailored to a single platform, a native app can integrate seamlessly with the device and take advantage of the full range of hardware and operating system features in the most efficient way possible. In contrast, there will always be an element of lowest common denominator compromise in any cross-platform alternative.

The downside to native apps has been the cost of supporting multiple mobile platforms. Build an iOS app and you have an app that runs on iOS devices. You’ll have to build a separate app to reach Android users and then you still don’t have a solution for BlackBerries. So it’s unsurprising that as HTML5 becomes more mature, mobile devices become faster, and mobile network bandwidth increases, more companies are deciding that mobile web apps are good enough. They are happy to trade platform-specific fit and finish in favour of reduced development costs compared to developing several different native apps.

But before dismissing the idea of building separate native apps it’s worth considering how many platforms you would actually need to support. Over the last year the mobile ecosystem has become considerably less diverse, as these recent figures from Gartner show. Whereas in Q2 of 2011 there were four mobile platforms with a double-digit share of devices sold worldwide, in the same quarter this year Android accounts for almost two thirds (64.1%) and Apple’s iOS (18.8%) is the only other big player. Nokia has all but abandoned Symbian, BlackBerry maker RIM has shed more than half of its market share and, despite Microsoft and Nokia’s best efforts, Windows Phone (2.7%) is still languishing in 6th place behind even Samsung’s low-end Bada OS.

In light of these numbers, it appears that in many cases it may be sufficient to target just two platforms for your mobile app – at least initially. In that case the cost differences compared to developing a single HTML5 mobile web app might not be that significant. Cost is of course not the only consideration. Some apps have requirements that make them inherently more suited to one approach or the other. Here are some of the other factors that may influence your decision:

HTML5 Advantages

• A single app will work on many different devices
• Can build on existing non-mobile web app infrastructure
• Retain full control over app distribution/subscriptions (not subject to app store rules/fees)
• Ability to update the app immediately if required (no need to wait for a review)

Native App Advantages

• Faster / smoother user experience
• Native look and feel (familiar user interface that will function exactly like other apps on the device)
• Access to all hardware/platform functionality (cameras, Bluetooth, accelerometers, NFC, calendar, contacts, notifications, widgets, etc.)
• Better offline experience (for apps that can function without Internet)
• Easier to sell/distribute (hosting and payment processing are provided by the app store)

One of the more interesting developments in the Android ecosystem in recent months has been Amazon’s announcement of its forthcoming Android App Store. The web retailer is poised to take on Google on its own turf.

Despite Android’s success in catching and then overtaking Apple in the battle for smartphone market share, the Android Market remains unloved by users, developers and commentators alike. The new web market is a welcome leap forward in this area but it still suffers from a glut of junk apps and, ironically, poor search results.

Google is known to be “not happy“ with the purchase rates for paid apps on the Android Market (here at Rectangular Software, we’re not exactly ecstatic either) and has a number of initiatives in the pipeline to address these concerns.

Amazon spies an opportunity. Google may be kings of search and advertising but retailing remains outside of its corporate comfort zone. Amazon’s Android offering will benefit from targeted recommendations across the site. Buying a book on poker? Maybe you’d also like this Android poker app? Bought an Android phone and lots of MP3s? Perhaps this music player app would be of interest?

Amazon will almost certainly serve developers better when it comes to putting their apps in front of potential buyers – something that is a constant source of frustration on Google’s Android Market with its stagnant top apps lists and capricious search engine. If Android apps are included in the Amazon Associates affiliate scheme (and I’ve been unable to confirm this yet) then developers may also benefit from third parties voluntarily promoting apps on their behalf.

Where Amazon’s proposal has proved controversial is in its approach to pricing. Developers set a recommended price but Amazon is free to apply a discount or even to give the app away for free. Amazon undoubtedly has a much better insight into the most effective price for a given application, and by maximising developer revenues they maximise their own cut, but many developers are understandably reluctant to surrender control of pricing. There will be winners and losers in Android’s pricing lottery and nobody wants their app to be a loss leader for somebody else.

The terms and conditions prohibit developers from setting a higher list price than on the Android Market (or any other app store) so Amazon has effectively guaranteed that it will always have the cheapest price for a given app. The developer will be paid 70% of the purchase price of the app, or 20% of the list price, whichever is greater.

The important thing about this last point is that the developer gets paid even if the app is given away for free. At first glance, having your paid app given away for free and only getting 20% of the list price for each user, rather than 70%, seems like a bad deal but in reality it could be lucrative for the developer. On the Android Market, free apps typically get somewhere in the region of 50 times as many downloads as paid apps. If that ratio translates to Amazon’s store then instead of selling 200 copies at $2 and getting $280 out of it, the same developer could see 10,000 copies given away free and yet earn $4,000.

Apps uploaded to the Amazon Appstore will be screened for suitability and may be rejected. The challenge here for Amazon is to strike a balance between Google’s anything-goes approach and Apple’s sometimes onerous process. This human oversight comes at a cost. Developers will have to pay a $99 annual subscription (compared to Google’s one-off $25 fee) though this is waived for the first year if you sign up now.  Initially Android apps will only be available on Amazon.com (other Amazon sites will likely follow if it is a success).

Google has unveiled several incremental improvements to the Android Market in recent weeks and months. These welcome changes include availability in more countries, support for additional screenshots, longer descriptions, changelogs, related app suggestions, local currency conversion for prices, and carrier billing. All good stuff, but there is still more that needs to be done to make the Android Market truly fit for purpose. Support for even more countries is one thing. The long-awaited web interface is another. These proposed enhancements have many vocal proponents but there are other areas that need to be addressed that haven’t received as much attention.

Android developers currently find it difficult to give away free copies of paid apps, something which is necessary for providing review copies or simply for running promotional give-aways. The obvious approach of e-mailing the .apk file to the lucky recipient is sub-optimal. It’s more work for the user and apps that don’t use the licensing service are susceptible to piracy, while those that do won’t work because the licensing service will not authorise copies that were not acquired via the Android Market. Furthermore, the recipient will not be able to download updates from the Market.

The solution to this dilemma is to allow the developer to generate unique promotional codes that can each be redeemed for a free or discounted licensed copy of the application. Apple’s App Store provides this functionality for iOS developers. For each release of an app the developer can create up to 50 promotional codes. This is a somewhat arbitrary limit but it is certainly better than zero.

Adding this feature to the Android Market has obvious advantages for developers and for users who will have the opportunity to download free or discounted apps. If it leads to developers selling more apps there will also be financial rewards for Google as they will be taking their 30% slice from a bigger pie.