This is a guest column by Dan Burcaw, founder and CEO of Double Encore, which develops apps for iPhone (and now iPad). Dan is extremely passionate about why developers should work on iPhone apps instead of Android. Here he explains why Android developers don’t make money, and why Android apps will always be secondary to iPhone/iPad apps.
A few years ago, apps were novelties – a cute idea. Now there are over 250,000 of those cute ideas in the App Store alone – and the Android Market is catching up quickly.
Apps are like the Wild Wild West – and from a developer’s perspective, there’s definitely a shoot-out coming. Google vs. Apple. iPhone and iPad vs. Android. Who should you code for, and why? For that matter, as a consumer, which phone and apps should you choose?
On one hand, you’ve got Apple with the newly released iPad and iPhone – a well-established if tightly controlled platform. On the other, there’s the Shiny New Android platform, with its open-ended promise of apps and plenty of freedom – freedom of handset, freedom of carriers. It sounds like a developer’s paradise … which is in fact how Google markets it. But I predict that a year from now, developers and consumers alike are going to find the Android platform really disappointing.
I come from the Open Source world, and the lingo surrounding Android reminds me of nothing so much as the promise of Linux in its time: heavy on philosophy and egalitarianism, but quality control? Not so much.
You hate to make the point that heavy-handedness can ever be a good thing. But it’s not that hard to make the case that too much freedom can be a bad thing. Especially for developers.
Oh yes, Apple is controlling. But there’s a method to it. You know who wins? The consumer – and ultimately, the developer too. Apple’s an established consumer company; and it has an established developer platform that’s been refined over the years – along with a set of tools and clearly defined guidelines by which developers must abide if they want to participate.
Draconian? Not necessarily. Apple’s tools are very mature from a capabilities perspective, and this is a clear result of the platform’s having been refined over its lifetime. The amazing features and capabilities we see being delivered today wouldn’t exist without Apple’s top-down approach: developers are simply adding “smarter” software to an already established platform to improve it. Of course Apple’s rich history, and not only its platform, gives it tons of credibility – and developers are drawn to that as well.
There was a lot of grousing about the emphasis on hardware in the most recent iPhone 4 introduction. But as a developer, I loved it. Why? Because I can count on the quality. I don’t have to worry about the apps I write not working from one handset to another. I can’t say that about Android.
Which brings me back to the Open Source conundrum. In theory, freedom is a great thing. When I was first developing on Linux, I loved that kind of freedom. But you know the saying, “the cost of freedom?” I doubt it refers to Android vs. iPhone, but it’s still relevant: Android gives developers a lot of freedom, but there’s a huge price to pay in terms of quality, consistency – and also, remuneration.
Today, the Android platform is here, but it’s peppered with numerous devices and apps – and you know what they say about too many cooks in the kitchen …
Android also shows its youth in the tools offered to Android developers. Consider the numerous devices problem: one would expect a set of tools that would help developers navigate the wilderness of multiple Android devices with varying screen sizes, resolution and even CPU speed. The Android emulator expects that you, the developer, configure profiles for each device you want to support. And I do mean configure. Every aspect of the hardware must be defined; there are no ready-made profiles for the current devices on the market.
While Google markets the Android platform as a “developer’s paradise,” there are key factors that have already and will continue to affect quality of apps within the Android market. Yes, the Android market offers a wide range of choices for developers, but what about the end user? Unlike with Apple, Android developers don’t have to follow a strict set of guidelines. The downside is, this leads to loss of control (in the development process) and ultimately a loss of quality control as well.
Meanwhile, from the consumers’ perspective, the Android platform looks cool but confusing:
Which device should they purchase?
Which carriers support which apps?
Does the app properly function on the device? There’s a return rate as high as 15-25 percent. It’s true, Android comes on several different carriers – which is great. But in many cases, apps don’t work between carriers, between handsets – even between versions of the Android OS.
Upshot: you may get a great phone, but you have no idea whether the app you’re getting from the Android market will actually work on it.
Ultimately, Google’s strategy is to let the carriers push the phones to the consumer, and then let the consumer do the trial-and-error work of apps, versions and quality.
Take Verizon’s Visual Voicemail for the Droid. Visual Voicemail allows users to view call history on-demand (a feature that comes with the iPhone). However, on the Droid, Verizon will charge you a fee on top of the cost of the phone, its monthly service and apps purchased through the Android Market to use this feature. It might be handy, but it ends up feeling like just another chance to gouge the consumer rather than offer the best user experience.
Back to this idea of Linux and Google:
If Google doesn’t fix its consistency and quality soon, it will find its Android marketplace deteriorating and the brand as a whole will suffer from confusion: is it only the EVO models that have issues, or is it a Droid thing? Is that bug just on Samsung handsets, or was it a version problem? Inconsistent quality isn’t such a big deal when there are only 10-20 Android phones on the market. But next year, when there’s closer to 30 or 50? When developers have to cope with or account for 30-50 or even 100 different devices, with different screen sizes, resolutions and technical requirements? It could get really ugly. It’s already extremely challenging for an Android developer to claim that their app works on all Android devices the exact same way. Multiply that across 30, 50, 100 devices, and the developer marketplace could see some real shakeouts.
(Yes, there is an Android emulator that allows developers to run software simulations on a wide range of hardware. But it would take a developer an extremely long time and a lot of resources to test all current hardware. By the time results come in, new Android devices – with new technical requirements – will have been introduced to the expanding marketplace.)
It’s just not fun.
The challenge at hand is to deliver one platform that will support a wide range of devices all while being able to provide apps that behave the same on all devices offered. Developers want their work to look the best it can, and have the widest possible audience. Most developers really want their app to be downloaded and used. Make it easy for them.
So, Google and Android: learn the lessons of Linux – a little less freedom, a little more quality and consistency? That’s where you should be headed. And in the meantime, I’ll be over here, concentrating on building great iPhone and iPad apps.
Dan Burcaw is the Founder and CEO of Double Encore, a mobile application consultancy. In the early 1990s, Burcaw taught himself the ins and outs of the early Internet and the emerging technologies of the time, including the Linux operating system. This formed the basis for his first several businesses. In 1999, Burcaw co-founded Terra Soft Solutions, Inc. (acquired by Fixstars) a technology consultancy focused on Linux-based integrated technology solutions. As Chief Technology Officer, Burcaw architected solutions for Fortune 500 companies, the Department of Defense, and the Department of Energy. Of note, he designed and delivered a multi-million dollar technology solution to Lockheed Martin which was the basis for a high availability sonar image processing platform deployed on board the US Navy submarine fleet.
