Find Me


Why I Have No Interest in Developing for Android at This Time

I have been asked several times if we should port our iOS software to Android. Each time, my answer (which is “no”) revolves around a few things.

  1. Dealing with the device fragmentation is a pain
  2. Dealing with the OS fragmentation is even more of a pain
  3. Dealing with screen-size disparities is a pain
  4. Dealing with hardware keyboards is a pain
  5. Dealing with hardware buttons (back/home/etc), their inconsistent usage and sometimes-problematic placement is a pain
  6. Having to deal with carriers and their software release schedules is a pain
  7. Carrier-installed custom “skins” are a pain
  8. No set release schedule for OS updates due to carrier influence is a pain
  9. Dealing with carrier / OS issues is a hassle
  10. Ability for users to install applications outside of the Android App Market (sideloading, Amazon App Market)

There are probably a dozen more things that I can add to that list but it can serve as enough reason to avoid Android development for my company’s current smartphone platform needs.

No, I’m not saying Android is too difficult to develop for, but there has to be a compelling reason to scale the summit and make it worthwhile. Right now, that is not a hill we need to climb.

Adding Some Depth the the Argument

Look at the list above and think about the QA work involved in bringing a fully-functioning Android app to market. All of the items above add tons of manpower, money and time just for QA alone – that’s assuming you can deal with all of the development issues inherent in such a list. The functionality would have to be regression tested for all OS flavors of Android on all devices that support it, plus things like carrier “flavors” like TouchWiz and Touchsense add even more testing to the mix. In early discussions with HTC, their interface meddling couldn’t be avoided without drastic measures. In my view, this type of OS modification is as much of an attempt to create “lock in” as Apple’s.

I get pushback from Android fans that you get big advantages for things like screen scaling and hardware interactivity because they are are handled for you in the OS. They say that like its a good thing. Maybe for smaller scale apps, where its acceptable if things move and shift around depending on screen resolution, and height/width ratios, but for applications that need control of that stuff, it couldn’t be worse.

Let me give a theoretical example and some real world issues.

You’re writing an application for medical software to run on Android. It needs to be fast, stable, reliable, easy-to-use and the screens need to be easy to read. Ideally, you’d want it to run on all Android devices to reach as large an audience as possible.

But one big problem is the controls move around from device to device due to form factor and screen resolution. So a button to treat a patient on one phone is in the top right, but on a smaller phone, that control could bump down to the next line and show up on the left. Now workflow is changing for critical, life-saving functions due to something out of your control. That doesn’t sound good, right?

Well, as I’m often informed when mentioning this type of example, you can just lock down the controls on the screen using code; Android provides for that functionality. But now you run into the issue of controls being cut off or omitted altogether depending on screen size and form factor.

Add in TouchWiz or Touchsense and you get different screen borders, font weights, and other “benefits”. What about phones with hardware keyboards? That means you can’t have a software keyboard that is reactive or custom in any way, for any phone, because it would provide different functions for different form-factors. Also include user tweaks like user-installed, custom software keyboards and you have software that is not only cost and time prohibitive to develop and QA for, but a lawsuit waiting to happen.

As you can see, quite a bit of complexity arose when I mentioned one control changing position on the screen but multiply that complexity by every decision you make while designing the app. It is a constant battle of trade-offs, development time, QA time, phone support, OS version support, and carrier limitations.

The applications that I have a hand in helping design aren’t dealing with life-threatening issues, but they deal with custom research data and which can also affected by something as simple as a control shifting on the screen or forcing one user to scroll where another doesn’t. It is little surprise that I can’t view Android as a viable alternative to iOS.

Big Companies Have Trouble Supporting Android Too

Now look at some real examples, Netflix & Hulu. The development and QA support for these applications have been something I’ve been watching for a while now. How much do you want to deal with things like this, as a developer?

The service is being offered on HTC’s Evo 4G, ThunderBolt, MyTouch 4G, and G2. With those additions, Hulu Plus is now supported on 10 Android devices. The Nexus One, Nexus S, and Motorola Atrix were among the devices previously supported.

So as a developer, each one of those devices and their available OSes (determined by carrier choice) need to be tweaked and tested for. Forever. What about the new phones, being released every month? Are you going to support them too? For each phone that is on multiple carriers, each model (due to Touchsense/TouchWiz/etc) will need to be dealt with. Forever. And when some hardware models gets the latest update to the Android OS, another hardware model may not. Or maybe they will, someday. Who knows? Certainly not you.

Sounds like a good operating system to base your entire business model on, huh?

No thanks.