Android’s F-Word mostly irrelevant, but affects Apple similarly
Yesterday marked an impressive milestone for Android – Google Play Services version 3. For such an important milestone, though, you’ll find no Android statue on the lawn in front of building 42, no dessert themed easter egg in the settings menu, and little more than a general “meh” heard from Android users. So what, exactly, is the big deal?
Like the first release, this hit all Google Play supported devices. Yesterday, version 3 brought Google Plus features, and revamped the entire Google Account usage concept for authentication inside your apps, and no device was left behind as all Google Play supported devices are seeing this update. I should also make note that the very popular Honeycomb Fragments UI API was even backported to prior versions of Android.
So what, then, is a Google Play supported device? Quite simply, it’s an Android device that has the Google Play store installed on it, running Android 2.2 (Froyo) or higher. Taking a look at the most recent Android OS Distribution Statistics, that means that Google Play Services is enabled for 97.6% of all Android devices captured in that report. While this obviously excludes non-Google Play devices (the Kindle comes to mind), it’s still a very impressive and important milestone.
Why, then, does fragmentation no longer matter? Simple: Android is now designed for it. Google provides tools for developers to write applications, and the capabilities they provide are now mostly version-agnostic. Sure, Ice Cream Sandwich has the new Holo UI, and tablets have a higher display resolution than phones (but for how much longer?), but Android has built frameworks for this. You can specify multiple layouts for your application, if you choose – a tablet layout for larger screens, and a phone layout for smaller screens. A Holo UI for Android 4.0+, and a regular UI for non-Holo devices.
The restriction of apps to specific versions of Android is only necessary in only two viable cases. In the first case, developers might be targeting a specific feature such as Google Now, or the new Lockscreen Widget found in Jelly Bean 4.2. Like applications targeting Siri on the iPhone 4s and 5s, the OS obviously has to support these features for developers to develop against them. In the second case, the developer doesn’t wish to provide an alternative layout for their application.
As a developer myself, I’ll admit that sometimes it’s easier to cut my losses (and my customer base potential) by giving the axe to older devices. They’ll be running Android 4.0+ eventually, so it’s a time-saver to not implement two different UIs in my application. I might not have the debugging capability (the emulator only goes so far) to support legacy UIs as well as Holo UIs, or I might want to break up my app into a tablet and phone variety for other reasons. But those are all developer choices, not technical requirements.
Apple on the other hand, seems to have bigger problems. Between the retina display devices and the non-retina display devices, to get an application truly compatible across all of Apple’s devices, you need to include 4 different UIs, which includes different resolution textures, graphics, and layouts. While the retina display iPhones have the same resolution as the non-retina display iPads, they can’t utilize the same layouts. While this concept makes no sense to me, it’s obvious that Apple thinks different.
For non-static content, such as OpenGL rendered objects, a developer needs to render at retina display density to support those devices (even if it isn’t necessary, in which case the resulting render gets scaled back, causing it to lose detail), or render at lower density, and have your renders look blocky on the retina display devices. Or double your code, one renderer for each device, and double your fun!
Both implementations of mobile operating systems have their drawbacks with support for multiple devices, but both custodians of those operating systems have provided plenty of tools to tackle the problems at hand, and they’re beyond sufficient for most apps. While Google and Apple will both continue to release more devices and newer versions of their operating systems on them, we’re finally beyond the days where apps have to be dependent on those versions.
It’s always harder to support two layouts inside an app than one, but it’s a necessary evil if you want your application to run on the latest and greatest innovations out of Silicon Valley, and it’s a trend that is only going to continue. So maybe that F-word isn’t so scary now after all. Does it still have you trembling in your boots?