You might have heard the term fragmentation being bandied about lately, usually in a flurry of FUD (fear, uncertainty and doubt) from those who don’t entirely understand it. OpenSignal, a wifi-location company, recently published an Android fragmentation report based on information they’ve collected. At first glance, it looks daunting – there’s a ton of boxes and there’s alot of red. The number of different devices pictured is mind-boggling. But let’s set have a look at what IS fragmentation and clear up some common misconceptions.
What is it and does it matter?
First off, we need to define fragmentation. There’s ‘Platform’ fragmentation, which for example, is defined by the different versions of Android that devices run. On the latest Platform Stats page, provided by Google, we can see that around 60% of devices are running 4.0 or newer, and 30% are running 2.3. This is easy to define – it’s the OS the device came with, plus any additional updates the manufacturer released for the remainder of it’s life. If people want to install their own OS, no problem – OEM’s often have source code available for their devices.
Rich Miner, co-creator of Android, points out that usually the people who make the most noise about fragmentation isn’t the average user, but technologists. Probably the same people who anguish over whether a device uses processor A or B. Guilty as charged.
The reality of the way the market works is, unless you use a Nexus device, the update has to go from Google, through the OEM (like Samsung or HTC who customise and test it for their phone’s specific hardware) and the carrier (who customise and test it for their networks and functions), before coming to your phone, both of whom have a heavy vested interest in NOT updating your phone, so that you’re more likely to upgrade sooner.Some OEM’s, like Sony, are much better at releasing source code for their devices, which they are required to do under the GPL, for people to examine and utilize for themselves. They often also contribute code back to the AOSP.
The outright number of devices in total is irrelevant. All that matters is what these devices are capable of. Having thousands of different devices is inevitable, when there’s a market full of strong competition. Basic economics say that variety and competition, like with cars, or clothes, or milk, leads to a better outcome for the consumer.
Then there’s feature fragmentation, as seen in iOS. Slightly different, but just as pervasive. Even though the majority of devices (90%+) are running the latest platform version, not all of them have all the features. Siri, Facetime, Airdrop, Panorama, photo filters are some of the features that are not present on older devices, even on the latest iOS. A table or spreadsheet is likely required to figure out which ones. This can be daunting for many. You could argue that it serves Apple’s core business perfectly – they get to champion a high take-up rate of the latest in press releases, whilst very strongly shepherding people to buy the latest hardware, in order to use all the features. Often, the limitations on older devices is questionable, at least from a technical standpoint.
Paul Thurrott, a Windows platform evangelist and one of the more balanced voices in the industry, has a far more comprehensive explanation on the irrelevancy of throwing fragmentation numbers around, which is worth a read.
“First, iOS 6 isn’t equally full-featured on each device, and some features do require newer hardware. Second, because half of all iPhone sales are of older models, developers must target the hardware specs from two and three years ago or risk losing customers. This creates a very real issue that I think is as serious, if not more so, than Android’s platform version fragmentation.“
With both of these platforms, app developers can exactly specify the minimum requirements for the app to be installed. For example, specifying a minimum API level of 10 on Android, as is quite common, results in more than 90% of the market being covered. There are additional criteria which can also be set on the Play Store, such as whether the device has GPS functionality, cameras, particular screen resolution, etc. If you don’t see an app in the Store which you know exists, it’s probably been excluded on device or regional requirements.
So does it really matter? Or more importantly, does it affect the user experience? The vast majority of users care far more about the apps and what they can do with the phone, rather than the underlying OS which powers it all. Ask people on older devices why they want the latest version of Android, and their answer will probably mention an app they want. Here is where the philosophy behind these two platforms diverge. Let’s dispel some common myths.
Myth: I can’t run the latest apps without the latest version of the OS.
On iOS, the core apps are tied closely to the version of iOS. There’s no way to upgrade Mobile Safari, for example, without updating iOS entirely. Similarly, system functions like device tracking are also tied to the version of iOS. There’s no technical reason why you shouldn’t be able to update an iPhone’s built-in Calendar app, without updating the entire OS – but the restrictions are there intentionally. ITunes will nag you every time it sees you’re not running the latest. You can see why iOS users make a big deal about what platform version they’re using.
On Android, the core proprietary apps are increasingly beginning to be separated from the platform they’re running on. Previously, where apps like GMail, Maps and Search were bundled with the OS version (resulting in lengthy delays before the next OS update went through it’s process), nowadays they’re readily available on the Play Store. Device specific functions, like App Data backups, are being rolled out discreetly by Play Services, regardless of carrier or OEM. If your device is able to access the Play Store, you can grab the app, and any subsequent updates to the apps instantly, even if you’re on an older OS (pending API level requirements). You can see the entire list here.
Myth: A developer has to customize their app for every single screen size and resolution out there.
By targeting a basic API level, and using adaptive layouts, developers can easily set up their apps for an infinite number of screen sizes, using just a few lines of XML. GQueues goes into great detail here, and the pitfalls and the differences between their development on both platforms. The mystical and drawn-out nature of publishing on iOS is also mentioned often.
“After months of intense, rigorous coding, I was forced to submit my creation to Apple and wait 7 days at which point the reviewer spent 2 minutes looking at the app before giving the almost obligatory initial rejection. I then spent a day making required changes and submitted again so I could wait another 8 days before finally getting approved. Of course there are many truly horrific App Store submission stories out there which make my experience seem like a walk in the park. Regardless though, I felt very anxious and uncomfortable relinquishing so much control over my business to such a temperamental third-party.”
ShiftyJelly, the Australian-based developers of PocketCasts, the most popular multi-platform podcasting app, addresses the misconception that because of the variety of devices, Android development takes far greater time. There are other examples of Android development being easier than iOS linked within.
“Unlike John, we actually do Android development full time, and we have for many years. We’ve made big apps, we’ve made small apps. Sorry to disappoint you John, but a talented Android developer works at roughly the same speed as a talented iOS one. They make the same apps, of the same complexity, in the same amount of time. Sure there are differences in platforms and API. Some things are quicker to do on iOS, others on Android. Long story short, there’s not a lot of difference when it comes to development time.”
Myth: I have to get a tablet-specific ‘HD’ version to use it on a tablet.
Android was designed from the start to be installed on everything, with a huge amount of devices in every possible combination of screen size and resolution. To achieve this, it utilises density-independent pixels (DPI, not to be confused with dots-per-inch), which is a method of rendering that doesn’t tie to the physical display density of the device. Instead of specifying absolute pixel dimensions (or point dimensions in iOS), elements are displayed in DPI, which scale to physical pixels on a per-device setting. There’s extensive use of 9-patch for drawing scalable screen objects, and screen elements are often drawn dynamically in independent modules, irrespective of screen size (this is why screen rotation generally takes longer on Android devices).
In addition, multiple asset classes for the various generalised DPI settings (including up to the XXHDPI) can be bundled into one .apk package. So when you purchase an app, you just purchase it once. You don’t need to buy a special ‘HD’ version for your tablet. Since the Play Store uses delta updates, bandwidth usage also remains under control.
The short version is, no matter what device you use it on, nearly all Android apps will take scale well to the bigger screens. You don’t need a ‘2X’ button in the corner to scale up to a blurry mess with black borders.
What’s the bottom line?
The call of ‘fragmentation is destroying everything’ is overblown. Ultimately, it’s much less about ‘Am I running the latest platform?‘ and much more about ‘Can I run the latest apps?‘. The variety in devices is not a flaw, but a strength. As with PC’s, there’s no single ‘perfect’ specification which suits everybody. Different people have different sized hands, different visual acuity, different preferences for functions and features, and not to mention different amounts they are willing to spend. Having a range of devices to cover every need is important, as is having an adaptable OS that can serve these needs, while delivering the most up-to-date services.