“Fragmentation What Fragmentation?”
The Android Developer’s Blog ignited a firestorm recently bypublishing an entry on the purported fragmentation of the Androidecosystem.
It’s worth a read. Too bad the same can’t be said to most of theresponses to it.
When the topic concerns either Android or the iPhone, and thearguable failings of each platform, it’s seldom debated by peoplegenuinely interested in seeing the target of their criticismsimprove in any meaningful way. Instead it’s pundits (lessgenerously called fanboys) hoisting their flag, pushing infor their chance to line drive some talking points.
Rabble rabble rabble, Steve Jobs will eat yourfirstborn
Rabble rabble rabble, Android is fragmented andanarchist.
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, ifthey do at all. There is a wide disparity in performance andfunctionality among devices, leading to unpredictable userexperiences.
It parallels the dark days of Windows Mobile, when unloveddevices were shat onto the market and promptly forgotten, thevendors more interested in prepping you for the next iterationthat, they assure you, will fix all of the problems of thelast.
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 theminimum functionality you need without restricting your market toomuch. You need to perform the same analysis on the target hardwarecapabilities, as the simple reality is that a rich graphical 3Dapplication won’t run acceptably on a wide range of deployedAndroid devices. A high-end game might run well on a Samsung GalaxyS, for instance, while being unusable on every other Androiddevice.
Do you target 2.1 and take advantage of Quick Contacts, forinstance, and limit yourself to 45% of the potential customer base,maybe preparing yourself for the future Or do you target 1.6 andsimply go without those refinements Do you build a 3D renderinginterface that will choke on all but the latest handset, or do youcater to the lower common denominator?
It’s a serious concern. There are brand new Android devices thatare hitting shelves today with Android 1.5 on them. There are newdevices with mediocre processors, limited memory, and barelyfunctional GPUs.
Isn’t that weird It isn’t optimal.
Add that there are all of the various skins that the vendors puton their devices to differentiate: HTC’s SenseUI, Motorola’sMotoBlur, Sony’s Rachael, among others.
Android devices come in all sizes and capabilities: There arebig screens and little screens; devices with keyboards and thosewithout; cutting-edge super phones and feature phones on steroids;tablets and netbooks; processors with NEON instruction sets andwithout; with SSE or without.
An Android device is not a homogenous experience for eitherusers or developers.
Crazy isn’t it Anarchy reigns! Contrast this to the land ofiPhone where there is a very strong uniformity and developmentconsistency among experiences and development and devices.
Shouldn’t Android be more like the iPhone Shouldn’t Google laythe hammer down and demand that vendors refrain from customizing,they upgrade in lockstep, they build a consistent, uniformplatform, and nothing deviates from the reference implementation?Everyone building a Nexus One with a vendor label on it?
Fragmentation is the Reason the Android Platform HasSucceeded
The progress of Android over the past year, or even just thepast 6 months, has been nothing short of extraordinary.
From being a marginal wannabe, largely adopted by thoseideological few willing to turn a blind eye to its many, manyfaults, Android is now a very serious competitor among mainstreamconsumers.
It’s an accomplishment that Google could never have pulled offalone. They needed a lot of help from a lot of very capablepartners, and their strategy with the Android platform and the OpenHandset Alliance is entirely the reason we got to where we aretoday.
HTC, Motorola, LG, Samsung, Sony, nVidia, Intel, ARM, among aslew of others…a lot of very smart, very capable companies workingto make their own success story, pulling up the Androidplatform at the same time.
Motorola wants to sell you a Droid, yet by investing so muchinto making their devices a success they’ve build an ecosystemwhere you benefit from their success even if you choose anothervendor’s phone.
Fragmentation is progress.
Instead of releasing a single iteration yearly, a singlelockstep uniform device and experience, a Darwinist battle istaking place, the best choices and experiences triumphing. The Evo4G is hitting shelves today, yet already we’re hearing about thenext superstar, a purported HTC Scorpion device with a 1.5Ghzprocessor coming soon.
When people argue that Android should be more like the iPhone,they lose sight of this very beneficial side effect of theso-called fragmentation.
If Google ran the Android platform like Apple, it would havebeen 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 Androidfragmentation is bunk. Horror stories about incompatible apps andterrifying development processes are largely exaggerated.
But there are some issues.
Google Earth, Google Goggles and the official Android Twitterapplication (an excellent application that was built with Google’shelp) all require Android 2.1 or above. It’s fairly obvious thatGoogle intentionally limits the best to a recent version in effortsto motivate vendors to hasten their upgrades, and to showcase themost recent platform additions, such as the animated backgrounds inthe Twitter applications.
Those are the reason that customers demand that vendors updatetheir phone, and it helps keep them motivated to push out upgrades.Motorola just released the Backflip on 1.5, and Sony released theX10 on 1.6. Both of them have gotten a lot of criticisms in reviewsfor this choice, and they both will pay for lagging behind. Theirmotivation to get upgrades to the market quickly is verystrong.
As a developer, when you develop an application you need totarget a given version knowing that you’re cutting out anyonerunning something older (thus cutting out some prospectivecustomers). In a subset of cases you can target an old version andoptionally target newer features using runtime reflection andfeature sniffing.
And there are compatibility quirks. In developing an app thatintegrates the camera I’ve encountered a number of issues,including devices that invert the preview output, some that onlyreturn greatly scaled down pictures when a picture is taken, amonga variety of other little variations and surprises, and that’s justamong the devices I’ve tested with.
There are known issues when dealing with OpenGL where somedevices demand a certain magic quadrant of environment conditionsto operate at their peak.
All in all, though, it is an absolute walk in the park comparedto most other development efforts I have pursued. The Android SDKabstracts most everything to a shockingly effective degree, and thevery clever, HTML-like (and thus XAML-like) layout manager allowsyou to very effectively run your application on a huge variety ofdisplays.
You can build high-performance code in the NDK, includinghand-crafted ARM assembly, but you can do it in a way that willonly optionally be used if the right conditions are available (e.g.an ARM processor with NEON instructions), otherwise falling backedto a managed version.
In many ways writing to Android is a bit like writing an HTML5application. There are quirks that you have to deal with on someclients, but they’re mostly known and documented and fade away asthe 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 pixelsto the layout manager’s multi-dot-pitch resource utilization (Iwould 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 universeof clients is extremely limited and of little variance. With thenew iPhone there are rumors that it will see a simple doubling ofeach axis’ pixel count, allowing the system to simply pixel doubleprevious applications.
It’s a bit like developing for Internet Explorer back in theearly 90s: Everything was grand and entirely consistent anduniform, and in many cases you could just target an ActiveX controlbecause you could make so many assumptions about your target.
There is limited variability build into the iPhone SDK ordevelopment process, and those hurdles are crossed when they areencountered. When the iPad came out, they updated the SDK to dealwith the second screen size. The new iPhone SDK added the abilityto deal with the new pixel density.
It makes a developer’s life simple. But it also seriouslyhobbles the rate of innovation and the ability to adapt tochange.
It’s a Long Term Strategy
In the short run the single-target approach – the ActiveXapproach – wins. In the longer run those early gains disappear,especially when you’re moving uniformly (“non-fragmented”) againstmany speedy opponents.
Just take a gander at the comments on any Android market sharestory. Just a few months ago it was gloating damnation as theiPhone ecosystem dominated the Android platform. Now it has subtlyshifted, 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 ofdubious merit: As a developer I completely care about the platformsaturation, not whether a phone is a Motorola or an LG.
And of course Apple does as well. There are millions of iTouchand iPad devices that don’t get counted in smartphone surveys, andthey give iPhone targeting developers a staggering lead still, butwe’ll see for how long.