Here’s why making apps for Android is so difficult


If you’re an Android user, you could be forgiven for feeling a little hard done by: Why does iPhone get all of the new apps first? Why did lots of major apps – like Vine – start life on Apple’s platform before taking a while to reach Android?

It turns out that part of reason is fragmentation: Whilst there are only a handful of different types of iPhone (and currently two screen sizes), there are tonnes of different Android handsets. This means that when you make an Android app, you need to make sure it works on all of these different phones:


Similarly, the software running on iOS is more consistent: When Apple releases a new version of iOS it pushes it out to all iPhone users simultaneously whereas Android relies on individual mobile networks and manufacturers organising the updates – which isn’t as quick. (Complicating things further, some manufacturers like Samsung likes adding its own skin over the top, and other apps, slowing the upgrade process).


These images are from OpenSignal which has released a report showing that Android is now apparently more fragmented than ever – which is bad news for developers, and the reason that Google is currently working with manufacturers to remedy this with its “Android One” programme.

But for the time being, it is still going to be a headache.

James O’Malley
For latest tech stories go to

One thought on “Here’s why making apps for Android is so difficult

  • Well, no, fragmentation isn’t the issue. With simple good practices (like not fixing a screen-size in your app, but get the screen size from the API, testing to see if a certain feature is available before attempting to use it, etc.), the same code can easily be run across pretty much any android device without compatibility fears, except where there’s an explicit conflict, (e.g. trying to take a picture without a camera) as is the more common case in computer programming. The majority of the issues of developing for android, I believe, come from the poor API and locking into the JVM.

Comments are closed.