Comparing the iPhone and Android Development Environments
I’ve spent the last few weeks working on an Android project at work and, I have to say, I am having a familiar feeling of shock at how bad the Android development environment is.
Here are some comparisons.
Objective-C vs. Android
First and foremost, using Java is much better than Objective-C. While I consider Java to be a verbose language, it looks like Python next to the antiquated C offshoot. Private methods, inner classes, anonymous classes, generics, better function syntax, and a much wider plethora of 3rd-party code are just a small smattering of the advantages of Java.
It’s no contest.
XCode vs. Eclipse
I used to love Eclipse. I could do my PHP, Ruby, Java, and Flex coding in one place. I could master one IDE and get benefits for whatever work I do. It’s been over a year since I had to use Eclipse in a daily basis (for Flex 3 programming), and coming back has been…
…a horrible experience…
I don’t know how it happened. Eclipse is bloated, slow, and the simple act of changing editor contexts (XML vs. Java vs. Android Manifest, etc.) is mind-numbing. It takes seconds. And before you offer, I’ve upped Eclipse’s memory and turned off auto-compile. Maybe my laptop is too old to handle it (about 3 years old), but it’s making for a *miserable* experience doing Android work.
Contrast this with XCode, XCode is a delight to work with. It’s sleek, lightning-fast, and I never see any slowdown when typing in code. I took XCode for granted for sure.
XCode in a landslide.
iPhone Simulator vs. Android Emulator
I’ve done both Java ME and BlackBerry mobile work, and I always liked the java ME emulator. It did what it had to do. So, when I met the iPhone Simulator, I was disappointed to see how little you can do with it. No GPS? No accelerometer? How hard could it be to add those emulations?
However, the Simulator does something better than I’ve ever seen. For one thing, it’s super accurate. I hardly ever see a problem in a device that I don’t see in simulation. It runs fast, I can shut it down whenever, I can reset it easily, I can change languages, and so on.
Android’s Emulator, on the other hand, is the worst emulator I’ve ever seen. It’s worse than BlackBerry’s — which is saying something. In both cases, they take a couple minutes to load up. With Android’s, you can keep it running and future runs start quicker, so that’s better. However, it feels flaky to me. Sometimes I run an app and it just doesn’t run anymore on the emulator and I have to restart the thing. The screen locking feature is awful…I don’t see why I have to unlock the screen on an emulator. At least give me an option to turn that off.
It’s also horribly slow. I once times an activity as taking 8 seconds to display. This may be related to my Eclipse issues as well, but it must be noted because I have *none* of these problems with iPhone development. Every Android developer I run into says they don’t even use the emulator anymore, opting to run the app on the device directly. It’s that bad. But, for god knows what reason, when you run on the device you get this obnoxious dialog asking what device to use.
iPhone Documentation vs. Android Documentation
Both documentation systems are about equal in power. Each has their strong suite. I tend to favor XCode’s search, but Android has some better explanations for some things and shows inherited fields and such. It’s really a wash, though.
Call it a draw.
The Android platform does a lot of things you simply can’t do with iPhone. You have more control and the power of Java allows you to write stricter code that accomplishes these tasks with better software methodologies.
However, working with each one day in and day out, I take the iPhone environment over Android — hands down. The sheer speed of XCode and your development cycle runs rings around Android’s more frustrating environment. That can still change in the future as tools are more maleable than platforms, but that’s the reality right now.
Would love to hear of your experiences.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)