Part of developing on the Android platform is dealing with the dreaded “F” word which is FRAGMENTATION.
It’s what tech blogs mention when they write about Android. It’s the word that scares some developers away from the platform. It’s what Apple love to put in a pie chart in their product launches to prove that iOS is the most amazing mobile OS yet.
Personally, I’d rather see a Fragmented Android than a Fragmented Mobile OS ecosystem. It’s likely that without Android, we’d be developing apps for Sony OS, Samsung OS, HTC OS, and so on. I can’t imagine that Apple would actually let other companies build phones using iOS.
But still, Fragmentation is a pain. If it can be minimized or eliminated entirely, I’d be happier.
Until recently, I was working at Wedding Party (http://weddingpartyapp.com) as an Android Developer. The app was supporting Android version 2.3 and above.
To create consistent UI for all versions, we used the ActionBarSherlock and HoloEverywhere libraries. Animations should be carefully done since one that runs smoothly on 4.x would, more often than not, be sluggish on 2.3.
The Wedding Party app also deals with a lot of images. High-resolution images were out of the question because it uses a lot of resources & using multiple of these images in one screen would almost certainly crash on older devices.
At Google I/O back in May, Jeff Gilfelt started giving away stickers that says ‘minSdkVersion=”14”’. It was a well-received campaign among Android developers that got this conversation started.
What struck me the most was Meier’s advice: “Skate where the puck is going” and “Create the best possible app for every user especially those on the latest devices.”
Jeff’s minSdkVersion=14 sticker campaign and Reto Meier’s talk made me think about the Wedding Party app.
Because we were supporting older Android versions, it was holding us back. We were skating where the puck was. Before we develop new features for the app, we needed make sure first that it would work on older devices.
After Google IO, I pitched the minSdkVersion=14 idea to the Wedding Party team. There were some hesitation at first but after looking at our Android stats and the pace of our development (development of Android app was at least six months behind the IPhone), we were convinced that minSdkVersion=14 was the way to go.
Installs for the Wedding Party app is constantly growing since its release for all versions of Android. While the overall number is getting bigger, Android 2.x’s slice of the pie is shrinking. Share of the Android 4.x devices, on the other hand, is growing at a fast pace.
What we did was create two versions of our code. Our current code would be for 2.x devices and we created a new branch of the code for 4.0 and above.
As a developer, it made my life easier.
We removed all the 3rd-party compatibility libraries and purged all code specific to supporting older devices. We became more adventurous with the UI especially with the animations. We switched to using high-resolution images without much issue.
Our automated (Robotium) tests run more consistently. (On Android 2.x, we had to use longer timeouts so the tests would not fail.) We also had fewer phones to do our manual testing in.
Overall, our development time was a lot quicker. For a good stretch of time, we were able to do weekly releases except when developing major features.
While we only actively developed for 4.0 and above. Our 2.x users can still download an old version of the app since Google Play has Multiple APK support.
When we made the decision to stop supporting older devices, we made several assumptions.
Owners of older devices do not expect a high-quality app. Fortunately, there wasn’t much complaints from users on why some features are not available on their phones.
Since a large part of Wedding Party users are in the US and US smartphone users would likely have newer devices, Android 2.x share would continue to shrink over time. (Android 2.x % for Wedding Party have been dropping a few percentage points every month).
Our decision was made a lot easier knowing that several developers went in the same direction.
Jake Wharton, who works on Android at Square, also popularly known for his ActionBarSherlock library, said that developer productivity was the main factor on why the Cash app only supports 4.0 and above.
“Developer productivity is #1. The app cannot ship unless it gets finished. Cash was developed primarily by one person with a tiny bit of support from other Android engineers. Could we have supported Android 2.x and hit our ship date? Probably. Could we hit our ship date only supporting Android 4.x+. Absolutely. Cash is a beautiful app. This can be achieved on Android 2.x but it requires more effort.” says Jake.
The type of app Cash is was also something they considered. According to Jake, “We conducted some simple research into our user base and have seen that the kinds of people who would be willing to download an email-based money moving product on Android are overwhelmingly on 4.0 and above.”
NPR will also support only 4.0 and above in their upcoming app which will have streaming audio and video.
According to Mike Seifollahi, one of developers building the NPR app, “codec support on older devices is hit or miss. When trying to deliver the best user experience for our streaming audio and video content, being able to support the right codecs is essential. Having to write/deal with software decoding for older device support is not a good use of resources.”
Android 4.0+ APIs also shows the maturity of the platform.
”Android 4.0 is a grass-is-greener ideal that actually is the greenest damn thing you’ll see. APIs are sane and normalized. There are new APIs for rich, dynamic, declarative development that allows you to engage the user more effectively. This version of Android is the first which actually helps you write better apps.” added Jake.
Jeff Gilfelt shares the same sentiment. “API 14 is when Android got serious. When design became a first class citizen and the default wasn’t ugly. It was a milestone release in many ways, and in 2013 I think it is a sensible line in the sand. Furthermore, multiple APK support in Google Play means you can still distribute a stable legacy version of your app to new customers who are running older platform versions.”
There may be some cases where supporting only 4.0 and above may not apply. If your app relies on network effects (similar to Twitter or Facebook) and/or target a worldwide audience (specifically India and China), you might need to support older versions.
If your app does not fall in the above categories, the positives of minSdkVersion=14 greatly outweigh the negatives.
With the holiday season coming, expect the share of Android 2.x devices to fall sharply. A huge number of Android device activations happen during this time and all of them would have at least Android 4.0. I won’t be surprised if 2.x share would be in the single digits by January 2014.
To reiterate Reto Meier’s point above, let’s start building the best possible Android app for every user.
Now go to your AndroidManifest.xml and change the minSdkVersion to 14!