Ship on iOS or Android First?

When I talk about making apps for Android, the question I invariably get, occasionally with shock or disdain, is “Why not make apps for the iPhone/iPad/my precious device?”

To be fair, I tend to bias against what’s popular.

But not in an obnoxious way. I not that guy who insists on not having a television and makes sure to tell everyone each chance he gets. And, I’m not a counter-culture activist consumer. I run GNU/Linux, but I do so on a Dell laptop. While I don’t shop at Walmart, I do shop at Target. I make games for GNU/Linux, but I also port them to Windows because it is easy to do.

I just get suspicious when there is a rush to own a piece of something, such as the iPad, or the original iPhone before it, or the iPod before. Camping out to be the first to own a piece of consumer electronics that will be patched and/or obsolete within months is not for me. The same goes for new game consoles or games. I can wait.

I am very clearly not an early adopter, nor am I all that interested in owning an Apple product. I was fairly happy with my Linux-based computing at home, and the idea of buying something I couldn’t tweak or configure bothered me. Of course, the idea that it “just worked” and didn’t need configuration appeals to a lot more people, so Apple has been very successful.

Eventually, I got a a smartphone. It was an Android device, an HTC Evo Shift II. It had a slide-out keyboard, which meant I could text and type easily without needing to learn some gesture-based input. It was bulkier, but I never had to worry about buying an external case for it. I liked it, although eventually I started running out of memory for the thing, and that’s when I learned about how fragmented the Android market was. Also, I ran into the problems with the U.S. market in that my phone is tied to the carrier and not just a device that I can plug the carrier’s SIM card into. That means updates to this phone’s OS were never going to happen unless I jumped through a bunch of hoops.

I now have a Samsung Galaxy S4, but I kept the Shift because when it is connected to my wireless, it’s still a relevant computing device. Plus, I could use it to test any apps I make for Android.

So now I have two Android devices. No, wait, I have a third: the Google Nexus 7 tablet that my wife got me for Christmas last year, my first tablet if you don’t count the EXOPC Slate I got after GDC 2011. That’s three different Android-based devices that I can use myself as well as use as test devices for apps I create.

Android today has a much larger marketshare (so much for biasing against what is popular), but it is common knowledge that iOS apps average more revenue for developers than Android apps. The thinking is that people who are willing to spend the Apple premium are also willing to pay for apps, and the numbers getting reported tend to indicate it is true.

Apparently if someone switches from iOS to Android, it is news. For major app releases, it is very common for the iOS version to be released before the Android version, if a port comes at all. I wonder how Microsoft feels being the Linux of mobile in this regard. If the app gets updated, it is possible that the Android version will lag behind, or have an unnatural UI, or will be otherwise inferior. Now the trend seems to be changing so that Android-first is becoming more common, but not everyone is happy.

The Fallacy of Android First documents one developer’s experience with trying to go Android first. Emu is a messaging app, and apparently Dave Feldman found that Android’s fragmentation was still an issue and the development tools were not as robust or stable as Apple’s. The larger potential audience doesn’t always translate into more users of your app, especially once you take into account backwards compatibility.

Feldman says:

Running a startup is all about learning. This has been a huge lesson for us, one I wish we’d learned faster…but perhaps our experience will help others to make a more informed decision. Android’s flexibility, and its greater strength in certain markets, still make it a far better platform for certain types of product. But it’s a difficult road, and best to travel with your eyes open.

He links to Steve Cheney’s post Why Android First is a Myth from last October which similarly describes a more complex development experience for startups developing on Android, especially those who rely on venture capital.

All that said, what’s it look like for games?

iOS is still dominant in terms of revenue earnings for developers, and if you are selling apps instead of doing a free-to-play model, Apple has demonstrated that they have paying customers. Plus, there’s very little variation and customization, which means you don’t have to do nearly as much work to ensure your game will work on an iOS-based device, and when you do, you have a significant chunk of the market.

Google announced cross-platform Google Play Game Services so that developers can create apps for both Android and iOS more easily. In fact, Google is using services to provide new capabilities without a need to fragment the userbase more than necessary. So, it is getting better there. And with a F2P model, more potential users means you don’t have to worry about how stingy your players are.

But is it really that hard to release simultaneously? If you use a library like libSDL or an engine like Unity, you can have a single code-base that ports more or less seamlessly.

In any case, for my next game, I’m currently wondering if not having an iOS device and a way to develop for it is going to hurt me. I’m looking into my target market to find out if my convenience of using devices I already own to develop the app will coincidentally line up with their own needs, but more and more I’m thinking that I will need to invest in some Apple hardware if I am going to be relevant to my customers.

Do you release for iOS first, Android first, or simultaneously? What has your experience been?

3 Comments

My new rule: iOS first, and then if (and only if) the game is successful, port to Android.

I ported my framework (a 2d game framework written in C++ on top of OpenGL and OpenAL) from iOS to Android after my last game, so it isn’t a huge amount of work, but I’m still only going to do it if I see a reason. It’s here, if you want to see, but I haven’t updated the build script for Android in awhile: https://github.com/ThirdPartyNinjas/NinjaParty

So most of the work is already done, and yet I still don’t want to do it. Android sucks that much from a dev perspective, IMO.

SDL is really good, but I found some very odd CPU usage, and nobody on the forums wanted to help figure it out, so I stuck with my own framework since it was already working.

The fragmentation is rough, but you can ignore it if you pick a few popular device formats and ignore everything else. Mostly it’s the dev tools.

The simulator seems nearly useless, and debugging on the hardware is finicky. Using Eclipse made me respect Xcode, and as a hardcore Visual Studio fanboy, that’s really saying something. In the end, I couldn’t get the Eclipse build scripts to package my assets correctly, so I used their Ant build system instead, which left me debugging with gdb. (Or more accurately with printf debugging, because gdb is foreign to me.)

As someone who is far more comfortable in Unix/Linux than me, you might have a better experience.