This post was also published in VentureBeat.
At Transpond, when we were building apps on the iPhone and Android platforms last year, all of our engineers were enamored with the iPhone and annoyed with the pesky Android devices.
The iPhone environment was remarkably consistent. There was a single 480×320 screen resolution and API consistency across iPhone, iPhone 3G, and iPhone 3GS. Even though the original iPhone doesn’t have GPS, it provided an approximation based on cell towers, and our customers like CBS and NBC are more interested in syndicating video and engaging users, so we did not need the 3D graphics of the newer generation iPhones. All in all, the iPhone platform presented a clean, wonderful experience for our engineers where they could write one piece of code and it would run beautifully on all of the iPhone and iPod Touch devices.
Android, by comparison, was a disaster. Every Android device had a different screen resolution. Every hardware feature had to be checked, since every Android device had different hardware configurations. Android was a huge, fragmented environment where the engineers had to constantly test for different things. What’s the screen size? Is there a camera? Is it running proprietary extensions that would conflict with the app? Compared to the iPhone, supporting Android was a huge pain from development to quality assurance to production.
This all changed in the first half of 2010. The engineers at Google, with backgrounds in Java and UNIX, recognized this problem and came up with a solution: the Nexus One. A lot of people thought that the Nexus One was Google’s entry into the handset market. This was actually far from the truth. The Nexus One is the equivalent of the Java Reference Implementation or UNIX POSIX and X/Open: a baseline of what handset manufacturers would have to support in order to create a real Android handset. If a developer wrote an app that ran well on the Nexus One, but it did not run well on a Motorola Droid or HTC EVO, the problem was clearly with Motorola or HTC, not with Android. In addition, Google obsoleted the 1.5/1.6 generation of handsets. So a developer could now target the Nexus One, adjust for various screen resolutions, test for hardware features such as a camera, and feel confident that their app would run on Android 2.0/2.1/2.2 devices. If a problem arose, it was a problem for Motorola or HTC to fix in their next patch, not for the developer or Android.
Apple, on the other hand, took the pristine iPhone OS platform and has added a ton of changes in the past two months. The iPad introduced a new screen resolution and did not include a camera. The iPhone 4 added yet another screen resolution and a front-facing camera. iOS programmers now have to make their apps run on three different resolutions and check for hardware features like cameras. While the variations are not as extensive as in Android, iOS has almost all of the same permutations. Especially from a programmer’s perspective, since programmers do not check for device type, they check for feature. For example a programmer is not writing “if iPhone or iPhone 3G or iPhone 3GS or iPhone 4 then there is a camera”, they are writing “if there is a camera”.
Apple’s form factor and feature disparity had to happen at one point or another. Although Apple presents a limited product line, market requirements between phones, music players, and tablets is fragmented and has inherently resulted in fragmented features. However, it is incredibly bad timing for iPhone programming to become as complicated as Android programming when compounded with Apple’s onerous App Store policies, Android outselling the iPhone in Q1, and forcing developers to program in an obscure language such as Objective C.