“Fragmentation? What Fragmentation?”

The Android Developer’s Blog ignited a firestorm recently by publishing an entry on the purported fragmentation of the Android ecosystem.

It’s worth a read. Too bad the same can’t be said to most of the responses to it.

When the topic concerns either Android or the iPhone, and the arguable failings of each platform, it’s seldom debated by people genuinely interested in seeing the target of their criticisms improve in any meaningful way. Instead it’s pundits (less generously called fanboys) hoisting their flag, pushing in for their chance to line drive some talking points.

Rabble rabble rabble, Steve Jobs will eat your firstborn

Rabble rabble rabble, Android is fragmented and anarchist.

It is noise that seldom inspires or enlightens.

On Android Fragmentation

We have a problem, Mountain View.

Some handset vendors are lagging on upgrading their devices, if they do at all. There is a wide disparity in performance and functionality among devices, leading to unpredictable user experiences.

It parallels the dark days of Windows Mobile, when unloved devices were shat onto the market and promptly forgotten, the vendors more interested in prepping you for the next iteration that, they assure you, will fix all of the problems of the last.

For those writing application targeting Android, such as myself, there is a need to carefully consider the current version breakdown, choosing the target that offers the minimum functionality you need without restricting your market too much. You need to perform the same analysis on the target hardware capabilities, as the simple reality is that a rich graphical 3D application won’t run acceptably on a wide range of deployed Android devices. A high-end game might run well on a Samsung Galaxy S, for instance, while being unusable on every other Android device.

Do you target 2.1 and take advantage of Quick Contacts, for instance, and limit yourself to 45% of the potential customer base, maybe preparing yourself for the future? Or do you target 1.6 and simply go without those refinements? Do you build a 3D rendering interface that will choke on all but the latest handset, or do you cater to the lower common denominator?

It’s a serious concern. There are brand new Android devices that are hitting shelves today with Android 1.5 on them. There are new devices with mediocre processors, limited memory, and barely functional GPUs.

Isn’t that weird? It isn’t optimal.

Add that there are all of the various skins that the vendors put on their devices to differentiate: HTC’s SenseUI, Motorola’s MotoBlur, Sony’s Rachael, among others.

Android devices come in all sizes and capabilities: There are big screens and little screens; devices with keyboards and those without; cutting-edge super phones and feature phones on steroids; tablets and netbooks; processors with NEON instruction sets and without; with SSE or without.

An Android device is not a homogenous experience for either users or developers.

Crazy isn’t it? Anarchy reigns! Contrast this to the land of iPhone where there is a very strong uniformity and development consistency among experiences and development and devices.

Shouldn’t Android be more like the iPhone? Shouldn’t Google lay the hammer down and demand that vendors refrain from customizing, they upgrade in lockstep, they build a consistent, uniform platform, and nothing deviates from the reference implementation? Everyone building a Nexus One with a vendor label on it?

No way.

Fragmentation is the Reason the Android Platform Has Succeeded

The progress of Android over the past year, or even just the past 6 months, has been nothing short of extraordinary.

From being a marginal wannabe, largely adopted by those ideological few willing to turn a blind eye to its many, many faults, Android is now a very serious competitor among mainstream consumers.

It’s an accomplishment that Google could never have pulled off alone. They needed a lot of help from a lot of very capable partners, and their strategy with the Android platform and the Open Handset Alliance is entirely the reason we got to where we are today.

HTC, Motorola, LG, Samsung, Sony, nVidia, Intel, ARM, among a slew of others…a lot of very smart, very capable companies working to make their own success story, pulling up the Android platform at the same time.

Motorola wants to sell you a Droid, yet by investing so much into making their devices a success they’ve build an ecosystem where you benefit from their success even if you choose another vendor’s phone.

Fragmentation is progress.

Instead of releasing a single iteration yearly, a single lockstep uniform device and experience, a Darwinist battle is taking place, the best choices and experiences triumphing. The Evo 4G is hitting shelves today, yet already we’re hearing about the next superstar, a purported HTC Scorpion device with a 1.5Ghz processor coming soon.

When people argue that Android should be more like the iPhone, they lose sight of this very beneficial side effect of the so-called fragmentation.

If Google ran the Android platform like Apple, it would have been a Buzzesque flop. It would have failed miserably.

But they didn’t, and it wasn’t. We are where we are.

So where are we?

Well firstly, most of what you’ve read about Android fragmentation is bunk. Horror stories about incompatible apps and terrifying development processes are largely exaggerated.

But there are some issues.

Google Earth, Google Goggles and the official Android Twitter application (an excellent application that was built with Google’s help) all require Android 2.1 or above. It’s fairly obvious that Google intentionally limits the best to a recent version in efforts to motivate vendors to hasten their upgrades, and to showcase the most recent platform additions, such as the animated backgrounds in the Twitter applications.

Those are the reason that customers demand that vendors update their phone, and it helps keep them motivated to push out upgrades. Motorola just released the Backflip on 1.5, and Sony released the X10 on 1.6. Both of them have gotten a lot of criticisms in reviews for this choice, and they both will pay for lagging behind. Their motivation to get upgrades to the market quickly is very strong.

As a developer, when you develop an application you need to target a given version knowing that you’re cutting out anyone running something older (thus cutting out some prospective customers). In a subset of cases you can target an old version and optionally target newer features using runtime reflection and feature sniffing.

And there are compatibility quirks. In developing an app that integrates the camera I’ve encountered a number of issues, including devices that invert the preview output, some that only return greatly scaled down pictures when a picture is taken, among a variety of other little variations and surprises, and that’s just among the devices I’ve tested with.

There are known issues when dealing with OpenGL where some devices demand a certain magic quadrant of environment conditions to operate at their peak.

All in all, though, it is an absolute walk in the park compared to most other development efforts I have pursued. The Android SDK abstracts most everything to a shockingly effective degree, and the very clever, HTML-like (and thus XAML-like) layout manager allows you to very effectively run your application on a huge variety of displays.

You can build high-performance code in the NDK, including hand-crafted ARM assembly, but you can do it in a way that will only optionally be used if the right conditions are available (e.g. an ARM processor with NEON instructions), otherwise falling backed to a managed version.

In many ways writing to Android is a bit like writing an HTML5 application. There are quirks that you have to deal with on some clients, but they’re mostly known and documented and fade away as the clients move closer to the specification, without restricting the innovation and uniqueness of the individual clients.

Everything about Android is built to abstract from the device, from the virtual machine runtime to the density-independent pixels to the layout manager’s multi-dot-pitch resource utilization (I would have preferred that they used vector graphics, such as SVG, but it’s better than nothing).

If Android is HTML5, then the iPhone is ActiveX

When you develop for the iPhone, you develop for the iPhone. With the iPad there’s one additional form factor, but the universe of clients is extremely limited and of little variance. With the new iPhone there are rumors that it will see a simple doubling of each axis’ pixel count, allowing the system to simply pixel double previous applications.

It’s a bit like developing for Internet Explorer back in the early 90s: Everything was grand and entirely consistent and uniform, and in many cases you could just target an ActiveX control because you could make so many assumptions about your target.

There is limited variability build into the iPhone SDK or development process, and those hurdles are crossed when they are encountered. When the iPad came out, they updated the SDK to deal with the second screen size. The new iPhone SDK added the ability to deal with the new pixel density.

It makes a developer’s life simple. But it also seriously hobbles the rate of innovation and the ability to adapt to change.

It’s a Long Term Strategy

In the short run the single-target approach – the ActiveX approach – wins. In the longer run those early gains disappear, especially when you’re moving uniformly (“non-fragmented”) against many speedy opponents.

Just take a gander at the comments on any Android market share story. Just a few months ago it was gloating damnation as the iPhone ecosystem dominated the Android platform. Now it has subtly shifted, and the argument has moved from "iPhone dominates!" to “You can’t compare the many Android makers against just Apple! Apple still beats HTC!” It’s quite a shocking adaptation, and of dubious merit: As a developer I completely care about the platform saturation, not whether a phone is a Motorola or an LG.

And of course Apple does as well. There are millions of iTouch and iPad devices that don’t get counted in smartphone surveys, and they give iPhone targeting developers a staggering lead still, but we’ll see for how long.