Android isn’t going away anytime soon, and should continue to bring in significant revenue for Google for many years to come. But without radical changes, it will never be the top winner on mobile. From a development perspective, here are ten reasons why:
1. Lack of a world-class IDE. Both Microsoft (Visual Studio) and Apple (Xcode) have invested enormous sums into creating stellar development tools, while Google chose a 3rd-Party IDE — Eclipse — that, while championed by some, is despised by many developers. Google’s decision here almost brings into question their fundamental understanding of client software development — ironic, considering Google’s reputation as an engineering-focused company.
2. Emulation instead of simulation. Google chose to emulate real devices in software instead of simulating, or approximating them, on development hardware. Not surprisingly, this approach is slow, buggy and frustratingly difficult to manage for all but the simplest apps. The icing on the cake is that their emulators emulate no better — and perhaps worse — than simulation.
3. API. The Android API itself is an over-engineered clunker in some areas (XML configuration files, UI scope, resolution scaling) and quite half-assed in others (native development, gimped high-level controls, view hierarchy). Versions change a bit too radically and methods tend to deprecate a bit too quickly. While the amount of work that appears to have gone into the API is impressive, it seems to ignore the hard-won lessons of its ancestors, notably J2ME and BREW. Part of this is due to the nature of Java itself; once an ensign of OOP, it has steadily devolved into OOPS on practically anything but a server.
4. Buggy debugging. Debugging on Android is at best incomplete, at worst unreliable. The threading approach feels oddly out of sync with the app, Java by nature doesn’t do an adequate job of pinpointing line numbers, and breakpoints don’t work on every development system. Roll this into the quirkiness of Eclipse and debugging an Android app is, more often than not, a black box.
5. Documentation. Unlike Apple (and if history is any guide, Microsoft in the near future), Google decided not to invest in detailed docs, real-world examples and a ton of sample apps. This might be okay if the Android development community at large wasn’t so fragmented and, in general, un-helpful. For docs and support, it’s the worst of both worlds.
6. Expense. Testing, in terms of both hardware costs and man hours, is far more expensive on Android. There are hundreds of notably different devices and Google (unlike Microsoft with Windows, for example) has done a poor job of enforcing standards. Admittedly this is herculean task, but the result significantly raises the barrier-to-serious-development-entry.
7. Loosy-Goosy marketplace. Developers can’t stop users from installing their apps on unsupported devices or older Android OS versions. Users can’t stop themselves from leaving inappropriate and irrelevant bad reviews. Piracy is easy.
8. Too much crapp. This is a problem that Apple shares and Microsoft is acquiring, but the barrier-to-entry for putting anything on Google Play is ridiculously low. With Apple, it’s an unlocked door; with Android, it’s an open door, resulting in even more low-quality crapps that muddy up the virtual aisles and make finding legitimately useful or fun apps even more difficult.
9. Platform fragmentation. The same Android version on different devices doesn’t deliver the same experience to users. Different devices pre-load dozens of bewildering garbage apps and services. While this is to expected to some extent (much like buying different PC brands), it’s an order of magnitude or two worse than what most users would reasonably expect.
10. Hard to make money. Alas, Google Play has become a bigger race to the bottom than Apple’s App Store. With the exception of the occasional developer-lottery-winner, it’s takes a ton of stamina and funding to make Android your business model.