Since its inception, Whereoscope has been an iPhone-only shop. The genesis of this iPhone-fetishism goes all the way back to the very first iPhone: in a way, it was the potential that device tantalizingly dangled before us that pushed Mick and myself to pick up our shovels and give this whole entrepreneur thing a go. I still believe that the iPhone is a truly paradigm shifting device; that by releasing it, Apple fundamentally and irrevocably changed the course of computing. But as the song goes, “the times they are a changin’.” Android has made considerable gains on iPhone in terms of functionality, polish and mind-share. The time had come for us to put aside our prejudices, and actually put together an app to see what would happen. What could possibly go wrong?!
“I hate this thing!”
We were lucky enough to score a couple of developer handsets from Google, through Y Combinator (we’re YC S2010 alumni). I took them home, unwrapped them, and started playing with one of them (a Motorola Droid). About ten minutes later I was on the phone (my iPhone — no way was I going to be gracing this thing with phone-calls) to Mick saying “I hate this thing!” I just didn’t get it. My iPhone had always seemed so intuitive, but on Android I had to shift my mental model: I had always assumed that the buttons on the bottom of it were optional extras, in much the same way that you can generally use the phone with just the touchscreen and not worry about the trackball thing. It definitely took some getting used to, and even now when I show Whereoscope on Android to iPhone users, I need to explain the basics of navigating an Android phone to them before they can use it.
The good news is that things definitely got better from there. Whilst I still think that Android’s initial user experience needs to be improved (it works well, but I really feel like they’re going to lose so many people in those first 30 seconds of use), I have to say that developing on Android after having worked on iPhone is a bit like waking up from a vivid nightmare — the kind where your dog, Fluffy, is being chased by killer robots who are having a bad hair day — and realising that actually, things are ok.
Garbage Collection
iPhone doesn’t have it. Seriously, Apple: What The? Various luminaries have waxed geeky on why garbage collection is so great, so I’ll keep this brief. Basically there’s two reasons it’s awesome: I really don’t have time to learn the rules of memory ownership and when to free, and all that stuff for yet another language. Secondly, I just can’t think of another language feature that accelerates development as much as garbage collection. Android has it, and for anything not pushing the envelope in terms of what the hardware can do (ie, almost everything), it works really well. I might have understood why Apple didn’t include it in the first couple of iPhones — it does come at a computational premium — but they really don’t have an excuse any more. It’s a big enough deal that I would advise the first-time mobile app developer to start on Android for this reason alone.
Documentation
Android has really great documentation. And I don’t mean superficial interface definitions and the like, I mean the really meaty stuff. Part of this is that the Android approach is fundamentally to expose everything to the developer, rather than try to hide important stuff on the (somewhat condescending) assumption that the platform developer knows better than you. I won’t go into details, but it is absolutely no exaggeration to say that we’ve spent weeks devising and performing increasingly peculiar experiments to figure out how to get iOS to do what we want. We’ve implemented hideous — and I really mean that — hideous hacks on iPhone to achieve what is trivial and well documented on Android.
I think this is what people mean when they say that “Android is open.” I don’t know if that’s a fair characterisation or not, but there’s something to it. I think it might be fairer to say that Android is very explicit in its communication with the developer. iOS swaps that control and communicativeness for presumptive simplicity. There’s reasons for both approaches, but to my mind what this means is that both platforms make the mundane easy, but Android makes the difficult possible, while iOS makes some difficult things easier, but does so to the exclusion of use-cases unimagined by Apple.
Crypto-Sadism
Somewhere inside Apple, there’s a guy who is receiving untold, nay, unspeakable pleasures by inflicting on the development community a kind of suffering that is as acute as it is pointless. That pain comes in the form of a series of hoops that one is forced to jump through in order to turn your phone into a development handset. There’s provisioning profiles, ad-hoc builds, certificates, and countless screens that I clicked through, not really caring what they did, because they brought me closer to being able to run my code on my phone. On Android, you check one option in preferences. That’s it.
Releasing
Having been battered and abused by the iPhone Appstore review process, it came as a bit of a shock to upload my binary to the Android Marketplace and have it appear only seconds later on my phone. In a way it was a bit anti-climactic. Despite the palpable sense of relief at my realisation that clicking “Publish” really is the last step, I’m actually not sure if this is a good thing or not. Broadly, I think that being able to rapidly get new versions to users is a good thing, but looking around the Android marketplace, my observation has been that the software is of lower quality, on average. I can’t back that up with hard numbers, but I think the argument can be made that Apple’s process, for all its warts, does encourage better software. I know we have spent time making sure things are “just right” on iPhone, where I think we might not on Android; it’s a lot easier to think “we’ll just push another version tomorrow.” I’ll be interested to see how this plays out.
IDEs, Simulators, The Usual Suspects
To develop on iPhone, you need a Mac. This sucked, as it meant that the first step on my journey to iPhone fame and fortune was to drop $2K on a computer that I didn’t really want (I still view it as a bit of a toy. However, you’ll have to pry my Thinkpad from my cold, dead hands). iOS development uses XCode, which some people love. I can tolerate XCode, but at the end of the day there’s something I can’t quite put my finger on that just rubs me the wrong way about it. It might just be that I haven’t had that epiphany that so many Mac owners seem to, where they just can’t imagine using anything but their Mac. Anyway, Android development is done in Eclipse (you can do it other ways, but Eclipse is the recommended path). I have to admit that I expected to hate Eclipse (Vim is my weapon of choice), but I’ve found it surprisingly good. The Java UI toolkits are still a bit weird, but overall it’s actually fairly pleasant to use, assuming you have enough RAM to use it (in fairness, my Mac has twice as much RAM as the Thinkpad I do Android dev on). And you don’t need a Mac to run Eclipse.
The emulators provided by both platforms are also kinda interesting. The iPhone developer platform ships with what they call a “Simulator” — it’s basically a build of the iOS runtime for 64-bit Mac OS on Intel. To run your code in the simulator, you actually have to build a separate binary, and the code all executes basically at the full speed of the host computer. We’ve actually been bitten by this before, because it’s really easy to believe that your code is crazy fast when your main interaction with it is on a quad-core Core i5 chip, instead of a single-core ARM chip. The Android dev kit takes a different approach: they actually use qemu to emulate the whole system — you make a disk image, and it boots up, and you’re actually running Android inside a virtual machine on your computer. You use the same binaries in the emulator as you do on the phone. Except that you don’t: because it’s a full emulated environment, running stuff in the emulator is crazy slow, so you end up running all your code on a phone all the time. Which I think is wise — you’ll know exactly how fast your code can be expected to run in production that way.
Conclusion
In an attempt to vindicate our decision to develop for Android, I wandered into an AT&T store the other day and had a chat with the sales assistant there. She said to me that they sell about 1 Android handset for every 3 iPhones. For her, Android was still a bit of a fringe platform. But you add to that all the carriers in the US that don’t have iPhone, and even anecdotally, that’s a lot of units. Despite quipping at the start of this article that we have somewhat of an iPhone fetish, the truth is that we go where the users are (as any entrepreneur worth their salt will). There comes a time when it would be ok for Android development to be 5 times harder than iPhone, but you’d still do it because without that, you’d fail. I don’t know if we’re at that point yet, but the equation for me was surprisingly tilted in favor of Android thanks to the simplicity of developing for it. Having gone through the process, I have a clearer understanding of Google’s strategy: I think they hope to win because their platform is so much more developer friendly. It’s a strategy that Google knows well, because that’s what the web is: it is dramatically simpler to prototype a web application than it is to hack something up in C++ (especially Visual-C++, which taught me that there is a reason they’re called “compilers” and not “compliers”). And y’know, it really could work. It’ll be interesting to see how this all ends up.
Whereoscope is available on the Android Marketplace (tap here if you’re reading this on your Android phone). It’s free for now, so get it while it’s hot!
Whereoscope is available on the Android Marketplace (tap here if you’re reading this on your Android phone).
If you use AppBrain you can download it from here.
You can also download Whereoscope from the iPhone App Store.
It’s free for now, so get it while it’s hot!
Posted by Mick 
James
Mick
Whereoscope Blog 