John Blanco is a Mobile Apps Freelancer doing business as Rapture In Venice in Denver, CO. He's spent 7 years working with mobile technologies including Java ME, BlackBerry, Android, and most importantly the iOS family of products. His most notable work includes leading the development on Sports Authority's S.A. Fit and the Navy Federal Credit Union iPhone apps. Animal Alphabet HD, which he developed for Fish the Mouse Media, is currently the #6 Education App in the iPad store. He's available for project work through his website: John is a DZone MVB and is not an employee of DZone and has posted 37 posts at DZone. You can read more from them at their website. View Full User Profile

Comparing the iPhone and Android Development Environments

  • submit to reddit

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.

Published at DZone with permission of John Blanco, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Shai Almog replied on Fri, 2010/11/19 - 8:58am

Its a common mistake to use the Android emulator. Unlike the iPhone/J2ME, Android has an "emulator" which runs the actual OS on an actual hardware stack which is why its so slow (you can disable the screen lock in the settings for the OS).

The solution is rather simple: get a device.

Running/debugging on the actual device with Android is faster than launching a J2ME simulator! You see all the printouts and exceptions in DDMS etc. That's one thing Google did really well.

If you must use the emulator remember you don't need to close it. You can just keep it running and the applications will load into it dynamically.

Kah Tang replied on Fri, 2010/11/19 - 9:07am in response to: Shai Almog

It is indeed better to have an actual device to test your apps on. And that's maybe a big point that hasn't been compared in this article: costs. For Android, you can test your applications on your device for free. No extra charge of $99 per year to get extra development options. The emulators are nice if you're just starting, but to do real development, you definitely need a real device.

Thomas Mueller replied on Fri, 2010/11/19 - 10:24am

Android Emulator: On my system (Mac OS X 10.6) the emulator uses about 30% CPU even when idle. That may be one of the reasons why Eclipse is slow on your machine. By the way, you can pause the emulator using kill -STOP/-CONT <pid>.

Dejan Pazin replied on Fri, 2010/11/19 - 10:28am


There is also no reason to use Eclipse for Android development (if you dont want to, that  is).

The next version (10) of IntelliJ IDEA features Andorid plugin in the free community edition. You can already download the early access version.

I havent tried Eclipse for some time, but in my experience IDEA was always way ahead and much faster.

Igor Laera replied on Fri, 2010/11/19 - 10:29am in response to: Shai Almog


That's true. If you don't want to shell out $300 for an new android phone , I suggest
getting one of the cheap tablets (if missing phone/gps functionality isn't your concern).

They start at ~$100 - and you get used to the bigger screen/different target audience
for your application. I use a cheap 2.2 Froyo updated tablet and it's a blast how easy
it is to work with/for it. I never use the emulator.

One nice side effect: its really helpful to have a "second monitor "for javadocs/browsing
when on the road with the laptop :)


Josh Marotti replied on Fri, 2010/11/19 - 11:21am

Comparing languages and IDE is a matter of personal preference, but let me ask you something... did you do your iphone development on an apple?  Did you do android development on the apple as well?


Because I'd love to tell you how incredibly terrible iphone development is on linux (in fact, I'd say iphone development outside of an apple is simply not worth doing), yet android is lightning fast.

Your issues with eclipse is that eclipse thought it was best to lazy load functionality, so switching from a maven pom to an android manifest for the first time loads the editors for those types of files.  If you flip back to them after the first load, you'll find it's lightning fast.

Sura Sos replied on Fri, 2010/11/19 - 11:27am

did you actually compare the machine while doing comparison? I use xcode and eclipse on my mac, I see no difference in performance for small project. I guess it also depends on plugin you install in eclipse. For example, you might want to disable maven.

Jordan Zimmerman replied on Fri, 2010/11/19 - 2:03pm

I'm surprised you didn't mention Interface Builder. I haven't done Android dev so I don't know if it has something similar. Building UIs with IB is a dream come true.

And Bod replied on Fri, 2010/11/19 - 2:58pm

Look, let s get something clear. Iphone apps are quite nice. They move fast, are sleek, it s a pleasure. Having said that devel for the iphone is garbage compared to android. Limited api s, no services, sucky multitasking, 2000+ usd usd for macbook + osx + iphone+ license to use sdk with iphone deloyment capability vs all free all open source android dev environ. Ios sdk is pos, crappy autocomplete crappy autocompile, unaccesible autogenerated code, rigid coding rules. Objective c has a complete garbage synthax(wich now apple is starting to improve with stuff such as dot operator, wow), memory management is crap, i could write a book about what a miserable objective c is. So spare us.

Andy Leung replied on Fri, 2010/11/19 - 4:00pm in response to: And Bod


However, one thing I vote iOS dev over Android is the hardware specs is one piece. For Apple you only have to test 3 models so far if you are going that far: 4, 3GS and 3G. But for Android, every hardware manufacturer may have different implementation or performance, therefore you will have to test all of them to ensure your quality.

I personally love Java and cannot agree more on your statement of Objective-C comments, I like Netbeans more than Eclipse but for IDE it's not really a big issue for me (although I agree with you for how crappy the auto-complete the Xcode is). The most important is Objective-C syntax is so counter-productive, that's the key!!!

Jordan Zimmerman replied on Fri, 2010/11/19 - 7:44pm

Objective-C syntax is so counter-productive
Ridiculous - there are something like 200,000 apps in the app store. I think people are producing just fine. There are some great things about Objective-C and a lot of really bad things. But, it's not an impediment.

Andy Leung replied on Fri, 2010/11/19 - 10:51pm

I get your idea but I believe most of the apps are coded in C or C++ except the native function calls. No offense but please explain why it is so difficult to simply allocate memory for an object in Objective-C? I am saying the syntax itself; not the features Objective-C provides, why all these symbols?

g ="world")

Thread t = new Thread();

id anObject = [[Rectangle alloc] init];

So how many unnecessary [[]]]][[]]] is there when you just create an Object? Plus how many &*&(*#%)@(*)($@ (not swearing :) ) are there to just declare a property, method or anything else, is there a reason for it? I thought these high level programming languages are supposed to be English-friendly where you could just read and under it? I guess it's just me :P

Andrew McVeigh replied on Sat, 2010/11/20 - 6:01am in response to: Andy Leung

I get your idea but I believe most of the apps are coded in C or C++ except the native function calls.

caveat: most of my opinions are based on using the old nextstep stuff (I used to have a turbo) rather than the mac/iphone. however, based on my experience, i'd be very surprised if most of the apps were c/c++. and certainly over time the developers will start using objective-c more and more, if the next experience is any guide.

yes, some of the objective-c syntax is awful, and takes time to get used to, but it is actually a very elegant, full and expressive OO language at its core. plus, it has fascinating elements like class categories (methods that can be added to a core class in user code) and a full meta-model like smalltalk.  in fact, in many ways the code used to remind me a bit of smalltalk. it's certainly more dynamic than java.

and as you point out, unlike in java, it's easy to drop down into a c/c++ style if you are comfortable with that, or to utilise an existing c/c++ library without any issues. much of the 2d phyics engines are written like this and you see a lot of those mentioned in the iphone app credits.

so, no, i think that objective-c is fine. i personally don't use it, but that's because i find apple's "walled garden" philosophy offensive. in terms of power, particularly for an embedded device, objective-c has many merits. plus, having the option of simple reference counting rather than global garbage collection is a very +ve thing generally in an embedded environment.


Alex(JAlexoid) ... replied on Sat, 2010/11/20 - 5:00pm in response to: Andy Leung

But for Android, every hardware manufacturer may have different implementation

That is where you are wrong. You test only on your minimal targeted platform and several different DPI's and possibly resolutions. If you want to be safe than you test targeted platform + all newer platforms.

Unless you plan to release something for Android 1.5 DPI will not be an issue(Well, if you're not a smart developer than everything and anything will be a problem...)

Testing DPI only is a problem where an application does some drawing, using surface, GL surface or overriding draw or setting component sizes in pixels...

I test resolutions only to check is at low resolutions my components are optimally placed for small screens, it never resulted in a crash due to some bug in the Android standard widgets

Andy Leung replied on Sat, 2010/11/20 - 6:51pm

Good point Alex, perhaps I am wrong. But if you do a quick search on google about "Android code different handset", you easily get some articles about the fact that different manufacturers put a layer on top of native Android OS so when you develop Android apps, unless you code at basic native level, your UI may present you something different, that's what I learned from these articles, what's your thought about it?

The following article doesn't seem too old so I guess it is talking about recent Android release:

Alex(JAlexoid) ... replied on Sat, 2010/11/20 - 9:05pm in response to: Andy Leung

They put a custom "skin"(if you wish to call that). And I don't even believe you can develop widgets specialised for HTC's Sence or Motoraloa's Blur. Those skins are basically closed source, but what's underneath is same as any other Android at that API level. Those manufacturers can't get their devices access Android Market without conforming to a specific level of API. I have yet to see where a handset manufacturer has modified the base API or even the default implementation beyond H/W drivers...

And fro that list of 5 fragmentation points, I have to agree, just he puts more items into fragmentation column than he should. And those points are in general, if you apply the same critique to iPhone you get the same 5 points. Just that Android's version and DPI/resolutions fragmentation is greater.

That said, version 1.5 is still a problem for people that have custom graphics components. That is why I didn't actually even test on 1.5. But the graphics part(the one I worked on, see below) works perfectly on all resolutions and all platforms starting with 1.6.

Sorry for the plug, the app is:

Charles (Ted) Wise replied on Sun, 2010/11/21 - 12:57pm in response to: Andy Leung

Given your example, this would also work for Objective-C:

id anObject = [Rectangle new];

Objective-C is a lower-level language then Java and much lower level then Ruby. They like to be able to allocate object ranges and then go back and initialize them. But you can also use the 'new' operator that lumps those actions together like a more traditional language. The biggest issue with 'new' is that most of the framework assumes a two-phase object creation and provides custom initializers that assume an object has been pre-allocated.

If you want an empty, default init, then 'new' will work just fine. If you want a custom init, e.g., 'initWithString:', then you'll have to take the two-phase approach.

I'm not defending Objective-C, I don't particularly like the language. Java is my bread-and-butter and I like it. But using Objective-C has allowed Apple (and third parties) to produce code that performs very well and isn't too hard on memory. And judging by the output from programmer's it hasn't been too much of a struggle.

Apple isn't quick to make changes and they're quite conservative in their architecture choices. It's pretty clear that within the next year they'll start supporting garbage collected memory in iOS (like in OS/X). Long-term, Apple is showing every sign of supporting Ruby (via MacRuby) as a first-class language on OS/X, and, probably eventually, on iOS. But that won't be happening very quickly.

Kevin Peck replied on Mon, 2010/11/22 - 10:14am

Having just started iPhone development coming from the PC side of things I have a slightly different take. I find Xcode to be lacking. I really want tabbed editing. It works great for me and is used by a ton of other IDEs that I really miss it in Xcode. I also don't like Interface Builder being separate from Xcode. If you make changes in IB, switch to XC and forgot to save the changes in IB then do a build you are not warned you have unsaved changes. I have been bitten by that too many times. Not super happy about the keyboard shortcuts used in Xcode either, I really want HOME and END to be start and end of line. Is there a way to set that up? I agree the Android emulator is slow and it is that way because you are emulated another OS and a device on a PC. At least on the Mac you are using same base OS and just doing device emulation. iPhone wins there but Android wins when it comes to running on the device as it is so much easier to just set device to debug mode and drop your code right on it. With the iPhone you have to do the whole agree with Apple legal and get a certificate. I will have a similar fate before I release my Android app but for ease of use and programmer experimentation Android wins. Objective C is a language written as a preprocessor on C. They used the [] and @ syntax as those symbols were available to preprocess not because it was a pretty syntax. It really started as a hack to avoid writing a new compiler. At least knowing that let me cut the language some slack. I find it hard to read thus making it harder to code. I prefer Java so I prefer coding for the Android when given a choice. I also miss working in just one file in Java. I used to code C/C++ and always opening two files (h and c or cpp) to do anything seems counter productive. Opening m and h files in Objective C feels the same but at least there is a hot key to move between the two quickly. I needed to use RegEx for my iPhone program. I had to go find code on the web to do that. I was shocked to find no native RegEx support in Objective C. How long has this language been around? Did I miss something here? I have been following Xcode 4.0 and it looks like they are well on the way to improving it greatly. There is no tabbed editing but IB will be integrated and they will support even more drag and drop interactions. The nice thing on the Java side is there are lots of IDEs to choose from: NetBeans, Eclipse, IntelliJ, etc. and they all add features to match the others. Right now Eclipse is the standard for Android but IntelliJ will release 10.x with Android support in the near future. For me Eclipse runs just fine but I have tweaked it for speed as I have used it for a number of years. I am using IntelliJ at work along with Xcode. I like IntelliJ better every day and use it for my Mac Java debugging. Xcode is taking time to get used to for sure, maybe 4.0 will make me like it but right now I find it very frustrating. Android uses a newer language (Java vs. Objective C). Java does not require manual memory cleanup although bad programs can still leak memory. It has more IDE choices on more platforms. I found the API / SDK easier to use but I came from a Java background. The emulator is much slower. Experimenting is much easier - everything is free, you can put your app on your phone with no legalese or cost. There are more versions of the OS and many more device versions. So far my special coding has been limited to checking screen size to make sure my UI fits. iPhone has a much better emulator and you worry about less device / OS differences. Objective C is a more old school programming language, it does not hold your hand as much. You use two separate programs IB and Xcode during development but they are soon to be integrated. There are less people programming with Objective C thus less sample code to find on the web. The debugger is more difficult to use especially when you want to view the contents of variables in a collection. You have to battle even to see the contents of strings at times. The debugger is another area they plan on improving in 4.0. I will continue to program on both, neither is a clear winner. I hope Apple takes on the challenge of Android and improves their tools and I hope that forces Android to do the same. Anything that can make my programming life easier I am all for.

Andy Leung replied on Mon, 2010/11/22 - 4:11pm

Kevin, thanks, you nailed it!!!

Michael O'Keeffe replied on Mon, 2010/11/22 - 11:49pm

I agree that the iPhone dev environment is nicely done. Install XCode, install the iphone dev kit, good documentation, and it just works.
Coming from a heavy Eclipse background, where just about anything done in eclipse usually requires going through a bunch of hoops downloading just the right version of eclipse, and just the right set of plugins, and then much tuning and tweaking, that is a welcome change. Perhaps that has something to do with the fact that Eclipse is the swiss-army knife, and the lazy load functionality mentioned above (which is actually a good feature, if you've ever had to use RAD or something that took 5 minutes to crank up), and basically the disadvantage of being so generic.
The Windows 7 environment looks promising, as Microsoft has always had a great IDE.
That said, I'll mention a quote from David H. Hansson, when he was talking about Rails way back: "And Rails does not need an IDE. That's easy to say when, there is no IDE for Rails." Interestingly, I believe DHH used XCode as an editor although, now people use textmate and other light-weight editors. So I'm all for Intelli-Sense and plug-ins and simulators, but perhaps the true test of a platform is when you can be just as productive without requiring that heavy-duty IDE to smooth out all the glitches in the platform.

Sam Su replied on Tue, 2014/08/26 - 9:29am in response to: Kah Tang

Then try a ulefone device  with android OS,it is works well with the Apps.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.