So this is what developing for Android looks like, eh? Well, it's not like that's anything new - here's the FP table-of-devices back in 2005, and I can assure you that between then and 2010 (when they were all stolen in a couple of burglaries) we ended up taking our selection to over 150.

They all ran different operating systems and had radically different Java runtimes: different devices had different maximum sizes for their JAR files, screen sizes were all over the place, UI elements rendered differently, sometimes important APIs just wouldn't work (ISTR a missing implementation of available() on a Samsung device).

I hope I'm not coming over all Four Yorkshiremen. I don't think many of us who worked through those days and learned how to ship products on a few hundred devices feel too nostalgic.

My point is that even with the diversity of Android devices today, things are way better than they were: fragmentation can't be ignored, but you don't need to test on every conceivable combination of devices. Plus, not all fragmentation issues are down to the device. Here's an interesting piece from the CEO of Zipline making this point: "Yes, there were device differences but most of our problems were rooted in classic software engineering issues. We did see some crashes on specific devices, but the catalysts were devices that have less memory or run more processes which were causing the underlying issues to be exposed more often."

And let's not forget the phenomenal growth in smartphone uptake since the days of J2ME, or the fact that Real People seem to use apps in ever-increasing numbers. The audience is larger nowadays; putting in less effort to reach a larger audience feels like progress to me.

I can't help but notice that the developer TechCrunch interviewed for their story was quite accepting: "We like fragmentation as users prefer choice. We are not big believers that one size fits all". Why did they run a story complaining about the issues, based on a company who had no complaint?