Dan is the founder of Rectangular Software, an independent UK software company that provides development services and builds its own mobile and web applications. Dan has over a decade of experience in the software industry, building a wide variety of systems including casino, poker and spread-betting platforms, mobile applications, e-commerce websites, and network security software. His other programming interests include artificial intelligence, particularly evolutionary computation, and functional programming in Haskell. He has authored, or contributed to, a number of open source Java projects. Dan has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Google’s Lag Problem – Or Why Android App Development is 22 Months Behind iOS

01.24.2013
| 6600 views |
  • submit to reddit

On 12th October 2011 Apple unveiled iOS 5.0 to the world. 7 days later Google released Android 4.0 (Ice Cream Sandwich).

Apple rarely announces how many devices are running each version of its mobile operating system but, according to third-party stats[1], today only a few percent of iPhone/iPad/iPod Touch owners are still running an earlier version of iOS.

In contrast, Google is much more up-front about how many people are running each version but it doesn’t compare favourably. Just 39.3% of users have access to the 15-month-old Android OS or one of its later revisions.

Of course, there are some mitigating factors. Android is a much more open ecosystem with dozens of manufacturers needing to test and approve updates for hundreds or even thousands of devices. Apple on the other hand retains a strict control over its (smaller) mobile empire and is able to push out updates directly to end users. But whatever the reasons, and despite Google’s recent efforts to rein in manufacturers and network operators, the fact remains that, unlike their iOS counterparts, Android app developers cannot target a recent version of the operating system and hope to have their app runnable by the majority of device owners.

Google has tried to address this issue with its support library, which brings some of the more recent API additions to earlier Android versions but this is only a partial solution that adds complexity and does nothing to resolve the vast visual differences between Android 4.x and its predecessors.

Today if you want to reach over 90% of iOS users you must support iOS 5.1, which was released in March 2012, and later versions. To reach the same proportion of Android users you would have to target Android 2.2 (Froyo), which dates back to May 2010.

The many comparisons of the relative merits of the latest iOS versus the latest Android version are largely irrelevant to Android app developers who are working from a baseline that is almost two years older than that of their iOS counterparts. An iOS developer can build an app that requires the absolute latest version of the operating system confident that the user base will soon be there (iOS 6 has reached 78.5% penetration in four months). Android developers will always need to be more conservative.

1. These stats may not be fully representative of all iOS users but they provide useful ballpark figures.

 

Published at DZone with permission of its author, Dan Dyer. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Silvio Bierman replied on Thu, 2013/01/24 - 3:04am

Today if you want to reach as many as possible mobile users you use HTML5.

Native apps are legacy and will be replaced with HTML5 applications much faster than desktop apps where ever overtaken by web applications. Already, HTML5 apps have become first class citizens on both Android and iOS. I expect only a handfull of core apps will survive the coming years.


Otengi Miloskov replied on Thu, 2013/01/24 - 5:11am in response to: Silvio Bierman

LOB or specialised apps I believe HTML5 is the answer but for some type of apps that need good performance, small footprint of memory and access the hardware, native apps is the way to go on Android or iOS.

Type of native apps are games, photo editing software, cad software, medical or instrumentation that show high performance graphics, and some more.

Everything else I agree HTML5 is the way to go, but when we could replace the above mentioned when WebGL or GPU with HTML5 is supported full into the mobile platforms.


Silvio Bierman replied on Thu, 2013/01/24 - 8:33am in response to: Otengi Miloskov

True, apart from the fact that game development in HTML5 is already very possible and games like AngryBirds prove it. HTML5 graphics is already very powerfull in most browsers and I expect heaps of improvements and extensions to the current HTML5 state of affairs.

Greg Brown replied on Thu, 2013/01/24 - 11:10am in response to: Silvio Bierman

Both native and HTML-based apps are going to be around for a long time. They each address different use cases. Neither one is going to replace the other.

 

Silvio Bierman replied on Thu, 2013/01/24 - 4:46pm in response to: Greg Brown

For the vast majority of currently existing apps this is not true. They where developed as native apps just because that is what the developer knew about or wanted to have, not because the particular use case required or even favoured a native app.

Sure, there are apps that do things that would be hard to do with HTML5 apps but they form a small minority. With the addition of access to the device cameras and GPS this area became smaller. And tools like PhoneGap reduce the advantages of native apps to a minimum.

I am in the business of mobile applications and my company is very much fasing out native apps in favour of HTML5 apps and I know for a fact that all of our current competitors are doing the same.

As I already said a number of native apps will stay around. But most "branded apps" will inevitably go the HTML5 way. The only thing keeping that from happening is a complete takeover by one platform (most likely Android) making the mobile space look like it used to be with Windows on the desktop.


Anthony Rabaa replied on Fri, 2013/01/25 - 10:57am

HTML5 isn't going to solve your problem here.  Not unless (as this article points out) you're willing to wait 22 months for Android customers to catch up.  For those who are, it means the HTML5 app will always have a look and feel of yesterday. Meanwhile the native apps will be blazing fast with all the new features.  If HTML5 and Android apps want to keep pace with iOS, Google needs to change the way it handles updates.

Silvio Bierman replied on Fri, 2013/01/25 - 11:43am

I think to OP meant with version lag the differences in the native APIs for different Android versions. First of all, for many if not most most native apps differences in API versions are not very relevant. The native Android apps we have been developing until now would work on any Android version from Froyo upwards, although we had to restrain from using a couple of the more recent features. The same is true for most large scale apps like Facebook, Twitter and Whatsapp.

In HTML5 the version differences are even less prominent. The Froyo stock browser is quite recent in its HTML5 support, no need for the mobile Chrome browser which is only available for ICS or JB.

During our current HTML5 development we do frequent backward compatibility tests on Froyo tablets and phones and we hardly ever notice incompatibilties with Android stock browser, Dolphin, Firefox or Opera.

About look and feel: most users could not care less about "nativeness". It is an artificial concept that only developers talk about. Most of our Android users find our HTML5 interfaces much prettier than the native ones. Our recent iOS customers are very pleased by the "refreshing" look of the UI. Don't forget that the big native apps are already converging their look & feel across platforms, a trend which will find following. Only the occasional Android purist or iOS fanatic will protest.

Anthony Rabaa replied on Fri, 2013/01/25 - 2:02pm in response to: Silvio Bierman

Twitter and WhatsApp are simple communication applications which don't necessarily have to harness the power of true HTML5. If you need to leverage the browser for more powerful things like graphics (I'm thinking the new wave of HTML5 games or a site like http://fff.cmiscm.com/#!/main, then you want the latest and greatest of what the platform, OS and browser have to offer. You don't want to have to hold back based on 22 month old technology.

Facebook is a good example of this. Their HTML client is no comparison for either their Android or iOS clients. They abandoned it because it was too complicated to try to implement the experience they wanted users to have.  The effects, workflow and navigation all saw noticeable improvement.

Is this a hit on HTML5?  I don't think so. I think it has more to do with the variant technology they need to support.  Do I think HTML5 will come in and save the day?  No. I think the true, proper solution is to have Android users on the latest and greatest (as much as possible) and not have developers, whether native or thin, being held up with 22 month old technology.

Ideally, i'd like to see Android (and iOS) more like Chrome with regards to updating.  It'd be sweet just to wake up in the morning and have a notification that the system and/or the apps were upgraded.  Then developers can focus on implementing cool, new technology and not have to worry about testing on old platforms. 

Diederik Hattingh replied on Wed, 2013/01/30 - 1:11pm

My experience with working with older Android APIs is that it only rarely gets in the way of app development. And for most things that you want your app to do, there is usually a work around documented on StackOverflow. This, IMHO, speaks to the good design of the Android APIs even from early releases. They gave developers enough flexibility to achieve most goals.

As for the UI argument, see Action Bar Sherlock for an excellent backwards compatible lib. 

22 months behind? Only in terms of API, not necessarily functionality. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.