Posts Tagged: ipod

iOS and Android Fragmentation – A Developer’s Perspective

Disclaimer: The impetus for writing this article is in response to the naysayers in the Android camp who would have consumers and developers alike believe that Android fragmentation is a myth. I’m here to prove that it is not only very real but very costly to dismiss as a myth. In short, I want to arm people with the correct information. I’m an iOS developer and an Apple fan. I have never owned an Android device although I’ve participated in a development project where Android fragmentation reared its ugly head and I’ve also developed extensively for feature phones which exhibited the same characteristics as Android with regard to fragmentation.

What Is Device Fragmentation?

It helps to define fragmentation before going any further.

In a broader context, fragmentation is simply taking one thing and splitting it into fragments. In the context of technology, fragmentation is the act of offering instances of one thing that, while labeled as a single brand, are distinct enough from one another to be considered separate.

By this definition Android is fragmented, as is iOS (albeit to a much lesser degree which will explored later on), and even computers.

Android Fragmentation

So what makes Android so fragmented?  The short answer: Android device makers.

They have to fragment Android in order to compete. Consider the alternative. If Sony offered essentially the same device as Samsung with the same technical specs what advantage would there be in purchasing one over the other? The only alternative would be to compete only on price but that could start a price war resulting in diminished profit margins for both companies. It is therefore in the interest of every serious Android device maker to innovate and outgun its competitors in the Android space (as well as against the offerings of Apple and Microsoft).

Now that I’ve established that the only thing Android device makers share in common is the word “Android” and that they have little choice but to fragment, it’s time to ask the next pertinent question: How does this fragmentation actually take place?

Since Google doesn’t itself manufacture Android devices (Google does work closely with some manufacturers however) there is a lot of wiggle room for device makers. To understand this better let’s look at the breakdown of an Android device…

  • The maker specific hardware
  • The base Android OS
  • The maker specific platform added to the base Android OS

The hardware plays the biggest role in fragmentation. Device makers cater to their respective markets. Some devices lack bells and whistles in a bid to remain affordable for consumers not willing to pony up for a premium phone for instance. At the other end of the spectrum are the Samsungs and Sharps of the world. Below is a list of some areas where makers customize their devices.

  • CPU speeds
  • RAM memory capacity
  • Antenna strengths
  • Storage space
  • Storage I/O speeds
  • Display resolution
  • Display color output
  • Display input accuracy/sensitivity
  • Presence/absence of hardware accelerated graphics
  • Presence/absence of various ports for external media and devices
  • Camera resolutions
  • Battery life
  • The list goes on…

The base Android OS is arguably the area with the least fragmentation. This is the part for which Google is responsible. Some like to view the low penetration of the latest Android OS on newer devices as a kind of OS fragmentation. It’s not quite the type of fragmentation I want to discuss here but it is true that since device makers stand between Google and the consumer, OS updates don’t occur as optimally as with iOS.

The maker specific platform that is slapped on top of the base Android OS is an interesting topic. It renders Android more a meta-platform than a real platform. The Kindle Fire is an example of an Android device that takes great liberties with regards to the UI. In fact, it almost doesn’t expose its Android heritage at all. The look and feel of this layer is one apps that hold themselves to high standards should strive to match when possible and this forces the apps to choose certain devices to support. As an aside, Ars Technica recently reported how Amazon’s market leadership is rendering Google’s control of Android weakened.


iOS Fragmentation

Okay I’ve discussed Android a bit, it’s time to take a look at iOS. Unlike the multi-party affair that is Android, iOS and the devices on which it runs are made only by Apple. While this leads to a much less fragmented platform, iOS is not perfectly immune to fragmentation.

Each new iOS device boasts a slew of hardware improvements over its predecessor and with them, you guessed it, fragmentation. Even at a single point in time there are 3 flagship iOS devices: iPhone, iPod touch, iPad with different specifications.  Most of the elements I mentioned for Android above are present on iOS as well.

Supporting many generations of iPhones or iPads can be tedious. However one generation per year is more manageable on the pocketbook. The 4th generation iPod touch is relatively cheap at $199 US and aside from its lack of telephony components is essentially an iPhone 4 and can substitute it for most testing.

Wikipedia has a comprehensive list of iOS devicesand their specs but I’ll focus on the types of fragmentation I have personally found on iOS.

  • The color output on my iPod touch is slightly bluer than that of my iPhones and I’ve had to take that into consideration when designing icons and graphical elements.
  • The iPod touch has only 256MB of RAM despite offering Retina Display resolution which means developers of memory hungry apps need to hand test them thoroughly and optimize for these constraints.
  • GPS accuracy diminishes with the iPod touch and Wi-Fi only iPad since they cannot avail themselves of cell tower triangulation.

And that is basically where fragmentation ends.

To the delight of developers, the resolution of the iPhone and iPod touch has remained 320×480. When Retina Display was introduced the only change was the resolution unit from pixel to point (1 point being a 2×2 pixel area). The new iPad has followed the same approach of staying with a resolution of 1024×768. The iPad’s split view design with its left side table view having the same width as the iPhone’s screen makes it easy to port iPhone apps to the iPad while retaining the same look and feel.

Why should all this make developers happy? We have only ever needed to consider one resolution for our apps on each device class. This gives us the time and freedom to strive for a pixel perfect look without having to contend with container based stretching and contracting layouts that adjust to match various resolutions but look less polished.


Ramifications of Fragmentation

I make fragmentation sound like a bad thing. I indeed view it that way. As a developer fragmentation introduces more work and incurs more cost to deliver a quality product.

You could argue that fragmentation is innovation by a different name and that it is good for consumers. More choice, more competition and all that. However there are also grave demerits for consumers. The sheer selection of options can be a dizzying experience comparable to buying a DIY computer with all the trimmings. At the time of this writing Google lists 225 Android devices on its web site.


My Experience with Fragmentation

I now want to take the word “fragmentation” from being just a distant, technical concept to what it is really is, a mental and financial burden. Let me share a couple real live experiences I have had with fragmentation. Only then can you relate to the pain and truly understand what awaits you.

Before making its way to the iPhone, KEYBOX was a J2ME app for the Vodafone Japan market. J2ME was, in its day, the only real platform for mobile phone development (BREW wasnt a real competitor). But it was fraught with the identical fragmentation issues that Android developers now face. Each device had a different screen resolution, different color output, different CPU etc… But it was worse, some devices didn’t even support transparent/translucent PNG files or floating point math operations. There was no rich UI toolkit to speak of and if you wanted to make information-based apps with text boxes, buttons and the like you had to contend with the limited selection of device-specific controls with different look and feels. Sun has never been a leader in user interfaces the way Apple or Adobe/Macromedia have and didn’t think to standardize the UI the way Macromedia did with Flex.

I hold myself to a higher standard so rather than settle for inconsistent controls I rolled my own tile-based UI kit that detected the optimal dimensions for windows and such for each device. It was a pain to say the least.



I later parlayed my own creative development into professional work opportunities in mobile. The most challenging of which was a DoCoMo J2ME app named Harumin. Harumin was an avatar based television guide and remote control app for the then upcoming Foma 900i series.

(Harumin character – Designed by Spring Design)

Of the 5 devices in this lineup the flagship was the Sharp SH900i and the worst was the Fujitsu F900i. Getting the same code to send infrared signals to a TV from all the handsets was impossible. The Sharp unit was too fast and the Fujitsu unit too slow. We ended up writing device detection logic to throttle the speed. Antenna strength was flaky with the Fujitsu unit and caused us to refactor our network communications logic and last but not least button clicks were interpreted as presses on the Fujitsu unit whereas all other devices considered button releases (the correct way) as clicks.

Long story short, had we not had access to all the devices there is no way we could have made the app accessible across the entire series. Fragmentation was a pain for us, not a plus. It cost us double the time to develop and test our app because of it.

Going Forward

Where I fault Android is that it had J2ME’s failure to learn from but chose not to. Google has now dug itself into a hole from which it will prove difficult to escape.

What attracted device makers like Samsung, HTC, and Sharp to Android was its openness/cost and branding. However if Google were to begin dictating conventions and standards to device makers in a bid to steer Android in a single direction the way Apple does, it may find them abandoning Android and perhaps even spawning a competing fork of it. Even without such moves, Amazon has forked it and it has been speculated that the openness Google prizes could very well be Android’s undoing.


Cutting Apple Some Slack

Regardless of how you feel about openness you cannot deny that Apple is in an enviable position. It only needs to answer to developers as it steers the iOS platform forward. There are no device makers to appease.

Apple has kept fragmentation under control but has fallen victim to criticism concerning its tight control over its platform.

Prior to the iPhone if you wanted to make slick games that reached the masses you had to buy a development kit from Nintendo at the ever affordable cost of tens of thousands of dollars. And you had to prove you were worthy of one as well. Nintendo’s pre-sale curation process makes Apple’s look like the wild wild west.

Coincidentally, the only reason one would want to make a game for a Nintendo console like the Wii is the almost complete lack of fragmentation. If your game works on the development Wii it will work on every Wii unit in the wild. The savings in development, testing and support time might just justify the price if you have a hit game and have the money upfront. The Android of this scenario is PC gaming with DirectX or OpenGL which is harder (testing graphic cards etc…) but doesn’t require permission from anybody.

All in all, Apple has successfully struck a balance between the democratization of development for the masses and the offering of a simple platform. For less than $100 a year (and the one-time cost of a Mac and an iPhone) developers can make games and apps. $100 is quickly recuperated even with zero advertising/marketing.

The App Store is such a success that even Nintendo is feeling the heat of Apple’s foray into portable gaming.

Android has tried to emulate the success of the App Store but it has been hit and miss. Independent developers cannot afford the full gamut of even the current generation of Android devices and must pick and choose which devices to target if they are serious about ensuring full support. Such choices are not trivial and involve much research into demographics and device preferences. By the time the project is finished the devices against which it was tested are no longer the latest and greatest as well.

Potential for Further Fragmentation

The rumors of an iPad mini or a slightly larger iPhone never quit. It’s called linkbait and puts food on the table of many a tech writer. Never say never, but so far such reports haven’t panned out. Just recently mock-ups of a purported iphone 5 with a longer screen were leaked. If Apple does go this route it’ll only be if it has found a proper way to allow for existing apps to work well on it and for it to not fall out of people’s pockets. Apple is famous for internally testing products before unleashing them on the public and the form factor we see now exists because it makes sense.

The reason so many deviating form factors exist on Android is not because people are clamoring for them. The marketing departments of device makers are simply looking to “BIGGER is better” as a way to make the public buy their offerings.

It’s still too early to conclude which is better but rather than listen to pundits I’m happy to sit back and watch the market decide.


Android and the innovation it promises are great for the average technology enthusiast but for developers this means dealing with the resulting fragmentation. This can come back to hurt consumers as well. We developers either need to raise prices to justify buying more devices (recipe for failure, especially on Android) or choose certain devices and hope the user base will be big enough.

Apple’s approach is simple and well thought out. It doesn’t need to eliminate the problems that saddle Android because it never created them in the first place. The fragmentation that is present is emergent from obsoleting older models of same device but minimal and even under a severely constrained budget a developer can target a single device and still reach millions of users around the world.