The Fragmentation of Mobile Fragmentation

Shattered by LexnGer via FlickrMobile1 fragmentation is going to get significantly worse over the next few years. While this fragmentation will be bad for end users in some cases, it will be particularly bad for developers.

The number one problem that app developers tell me they face today is how to deal with platform fragmentation. How can they target all the varied mobile platforms out there in a sane way? There are things they can do that help, but no silver bullets.

I explained how Google has irrevocably lost control of Android in my piece titled Fragmentation is Not the End Of Android. There, I described the five axes of mobile fragmentation. It’s worth covering this taxonomy again because I believe fragmentation in the mobile ecosystem2 is getting worse, and will continue to get worse before it gets better (actually, I don’t think it will ever get better).

I’m not talking specifically about Android here; I’m discussing the totality of the mobile ecosystem, with a focus on developers.

The Five Axes of Mobile Platform Fragmentation

Each side of the mobile ecosystem (End Users, Channels, Device Manufacturers, OS Providers, Services, and Developers2) contributes to and is (sometimes positively, sometimes negatively) impacted by fragmentation. When fragmentation is positive, it’s called “choice” or “variety.” When fragmentation is negative it’s, well, fragmentation. Since this piece is focused on developers, and fragmentation is rarely good for developers, I’m emphasizing the negativity.

From a developer’s perspective, there are five axes along which fragmentation exists:

  • User Interface
  • Device
  • Operating System
  • Marketplace
  • Service

A different degree of fragmentation can exist along each of these axes. For example, Apple’s iOS platform has almost no fragmentation along the Marketplace axis because Apple has been so hardcore about ensuring that the App Store is the only marketplace supported. A relatively small amount of fragmentation on the User Interface axis exists because Apple has been consistent with UI. Likewise, there is only a small amount of Device fragmentation with iOS due to different generations of iOS devices having different hardware capabilities (such as front-facing cameras and Retina displays).

On the other hand, the fragmentation of Android is severe, across all of these axes, regardless of how Eric Schmidt tries to spin it. Fragmentation of Android is most obvious along the Operating System axis where the majority of Android devices are still running a version three generations old. Across the other axes, the fragmentation is significant, if just not as well understood. And it’s getting worse. Recently we’ve seen, by example, increased fragmentation along the Services axis in Android with Google’s defining Play-specific APIs. Amazon building its own Android app marketplace for its Kindle Fire devices is fragmentation on the Marketplace axis.

Fragmentation Exists Within and Across Platforms

In 2009-2010, while Android was still a nobody, and the Apple App Store, essentially, had no competition, (smart) developers had it easy: just target iOS.

However, today, cross-platform mobile development is something that all developers must do in order to reach the largest audience. I’ve covered this here3. Today, Amazon is selling enough Kindle Fires to make it meaningful and Windows 8, even if it is a failure (it won’t be) will have an installed base of hundreds of millions in the next 12 months.

How do developers view this?

User Interface: Consider the poor developer who needs to build a high-quality, immersive experience for the largest number of phone and tablet users. How many UI frameworks must the developer target? How many UI metaphors (e.g., single home button on iOS and the weirdly inconsistent jumble of buttons on Android devices; live tiles on Windows vs. widgets on Android) must he/she take in to account?

Device: How about screen resolutions, color depths, and input methods (touch, pen, keyboard, mouse, voice, gesture)? Developers have to deal with the varying modalities of input, ranging from voice prompts via Bluetooth in the car to finger swipes on a phone to keyboard shortcuts on a tablet with keyboard attached.

Operating System: While I’ll argue that all three major operating systems are now fundamentally the same (I mean, really, at least MS is finally close to getting rid of Windows CE), they still all have varied APIs for accessing OS functions. For what it’s worth, I include language choice here. As a developer needing to target multiple platforms, how do I deal with the Objective-C, C#, Java, and JavaScript mess?

Marketplace: Build the app. Submit the app. Have it rejected. Approved. Sign up to get your 70%. Or call APIs for in-app commerce. Do this at least five times in five different ways (Apple App Store, Google Play, Windows Phone Store, Windows 8 Store, Amazon Appstore). Oh, and even after all that, you have to deal with at least the same number of update, feedback, analytics, and user review systems. Oh, and even after all that, you have to market your app for it to stand out. Let’s say you have $10k to spend on app marketing to get it to rise above the hundreds of thousands of other items across all the marketplaces in which you need to participate. How are you going to divide that marketing spend up?

Service: So far, most business critical services, such as mapping, search, social networks, and cloud storage are generally available on all platforms (e.g., a developer can use Google mapping APIs on iOS, Android, and Windows by calling the same REST APIs). But not all services are created equal on all platforms. For example, developers can call Siri APIs on iOS. But once they do, what do they do on Android or Windows Phone 8?

Fragmentation is Getting Worse

When all we had were Windows PCs, things were relatively simple. Even with the browser wars and the “great thing about standards is that there are so many from which to choose” world of the late ’90s, developers coped.

But the mobile ecosystem adds far more complexity with six market sides and five axes of fragmentation. Radical innovation in UI metaphors, device form factors, input methods, display resolutions, programming languages, commerce systems, and Web services will continue.

Just wait until Amazon finally ships the Kindle Phone — likely with unique hardware capabilities — and starts to more strongly push more of its own service APIs.

And watch what happens when the flood of cheap (sub $100?) tablets start selling at Walmarts en masse.

Then there’s Google: At some point, its shareholders are going to say enough and insist that the company either starts making money directly from Android, or simply writes the whole thing off as a $20B Titanic. If Google starts really trying to directly monetize Android, it will be through Google-specific services that will be unique to Android.

Consider what happens when TV platforms such as Xbox, Google TV, and whatever Apple finally does take off. Yes I know TV is not really “mobile,” but once TVs gain app marketplaces — and they will — it’ll really be part of the same broad ecosystem… and I’ll have to rewrite this post.

Through all of this, developers will have the suckiest time because they will be expected to cope.

At the same time, though, I believe that this means opportunity. It means that smart, agile developers who figure out how to cope will do very well. There will continue to be no shortage of jobs for developers. I believe that Mark Andreeson is right: Software is eating the world. I also believe in the corollary: The (mobile) world is causing more software to be written.

I also believe that the pain of fragmentation will cause an acceleration of larger and larger pieces of “apps” being pushed to run in the cloud instead of on a device. This bodes well for the PaaS and SaaS providers of the world (especially those focused on easing mobile developer pain like The Buddy Platform, a company in which I’ve invested and for which I advise).

I’m skeptical that any of the big players representing the other market sides of the mobile ecosystem will do much to ease fragmentation for developers. It’s just not in their interests. Apple couldn’t care less. Google may try (it’s not evil, after all), but its current course and speed mean that things it does try will only make the situation worse. Who knows about Microsoft; I see signs MS is serious about enabling Experiences across all devices, but other than supporting Xamarin’s cross-platform tools, it doesn’t seem to be doing much to ease developers’ cross-platform pain.

I’m also skeptical (as I’ve made clear) that HTML5 will help any time soon (it’s simply not real on the majority of mobile devices).

Mobile fragmentation is bad today. Due to continued innovation, competition, and a broadening complexity of the “mobile ecosystem,” it’s going to get worse. As someone who builds products to delight consumers, I am both frustrated and pleased by this. I’m frustrated because it makes some things harder for me. I’m pleased because it means that innovation and competition are alive and well, and at the end of the day, that’s what moves the technology world forward.

Charlie Kindel is building a Seattle startup doing innovative things where space and time collide (milelogr.com). He is active in the Seattle startup community as an angel, advisor, and mentor. Charlie was previously the GM for the Windows Phone 7 app platform at Microsoft. During his 21 years tenure at Microsoft, Charlie built a broad range of products. He started his first software company while in high school in 1983 and built some of the earliest shareware for Windows. He is passionate about customer focus, lean methods, going deep technically, soccer, and cars. Read his musings about startups, technology, and other random things on his blog and follow him on Twitter.

1How I Define Mobile

2The Market Sides of the Mobile Ecosystem

3Apps Must be Cross Platform

Image shared by LexnGer via Flickr

Article Written by

Guest Blogger is from all sorts of different times and places. Guest Blogger is usually less mysterious than James Bond, but often more mysterious than Austin Powers. Guest Blogger has a knowledge base that is as vast as space, and as timeless as infinity. Guest Blogger is sometimes me, and Guest Blogger is sometimes you.

  • http://www.ScienceProUSA.com SciencePro

    Very excellent post – as I start getting into app development I’m finally coming to understand these challenges first hand. Curious, how do you think solutions like PhoneGap fit into this larger puzzle?

    • http://ceklog.kindel.com/ Charlie Kindel

      Funny, I actually commented on this on Twitter this morning:

      https://twitter.com/ckindel/status/260426743800791041

      (In short, I think PhoneGap et. al. have it backwards. It is not the UI that you want to make cross-platform; that should be as native as possible. It’s the lower levels that should be made cross-platform by either moving to the cloud [if possible] or portable with something like Xamarin).

  • Walt French

    @CEK said, “At some point, its shareholders are going to say enough and insist that the company either starts making money directly from Android, or simply writes the whole thing off as a $20B Titanic.”

    Contact me if you’re unclear about who controls the voting shares of Google.

    Yes, I understand you know that three people totally run the company. And I know that you simply feel the Google/Android thing just violates all tenets of common sense. But every incremental piece of info we get — say, the announcement of Verizon carrier billing for Google Play — indicates that Google wants no corruption of Android by venal direct-revenue interests; they want to keep it as the obvious way to organize as much of the world’s info as possible.

    Does it make life tough for developers? Too bad; whose platform is it, anyway?

    More of the same in store for us, I’d say.

    • studuncan

      “every incremental piece of info we get — say, the announcement of
      Verizon carrier billing for Google Play — indicates that Google wants no
      corruption of Android by venal direct-revenue interests”

      Every? Really? Even your example, where *Verizon* bills for *Google* play means there’s venal direct-revenue interests.
      Perhaps they should not let anyone have access to the source code and free licensing.
      Also, Amazon says hi.

  • http://twitter.com/AvroArrow69 Avro Arrow

    Developers should just focus on making apps for “pure” releases of Android. Google makes the pure kernel code available for developers to download. If device manufacturers want to deviate from the original source code, their customers will find (rather unhappily) that there are apps that cannot run on their devices and will stop buying devices from that manufacturer. Of course the manufacturers will realise this in advance and will make certain that they don’t bastardise Android enough to cause such problems. It’s a rather simple solution when you think about it.

    • http://ceklog.kindel.com/ Charlie Kindel

      Focusing on “pure” android is guaranteed to result in an app that runs on a limited set of customers’ handsets. Why would any developer, trying to build a business, do such a thing?

      • http://eddieringle.com Eddie Ringle

        Uh, “pure” Android is the only thing you need to target. Every manufacturer that wants the luxury of having Google applications (e.g., Play Store, GMail, etc.) preinstalled and shipped on their devices needs to ensure they’re modifications don’t break when tested in the CTS. Even Amazon won’t do anything to break the APIs because they basically depend on developers being able to upload their apps without hassle. So when you say that targeting your application according to Google’s guidelines will result in an app that runs on a limited number of devices, I think you have absolutely no clue what you’re talking about.

        Source: I’m an Android developer.

  • http://josed.net/ Jose Dizon

    I use Android as my primary mobile device so I’ve experienced the effects of fragmentation first hand. And ya it sucks.

    I know it’s unrealistic, but phone manufacturers and carriers really need to embrace Android for what it is (an open source OS) and make things as easy as possible for people to root their phones and build custom roms. The majority of phones are still on Gingerbread, and I’ve seen many times on XDA people willing to port ICS over to specific devices, but they can’t because of locked bootloaders or the manufacturer not releasing source or drivers.

    As for the UI fragmentation, I think that developers need to do the Android equivalent of “responsive web design” which is making the UI change and adapt fluidly to the screen size, making it relatively screen-agnostic. Also, if all devices were upgraded to ICS/JB, then I think developers can just start to ignore the hardware buttons and just use the software buttons inside ICS/JB.

  • Björn Sveinbjörnsson

    But it has always been like this. That is if you happened to target different platforms. I remember writing portable code for Win16/32 and the old Mac OS (7/8/9). You would write most of your code in clean C/C++ and then try to isolate the GUI specific code, Right now the situation is simple. Windows as a mobile platform (WP7/WP8) is from a marketing perspective not there yet so we deal with iOS and Android. The screens are smaller on mobile devices so the native widget part is not a big deal. Again, write the core in portable C/C++ and use Objective-C/Java-Dalvik for the GUI or OpenGL if you want to be fancy.