Thursday, July 2, 2009

Android versus iPhone Development: A Comparison

A few months ago I ventured into the world of Mobile development and created an application (Hudson Helper) for both iPhone and Android. This article is about my experiences, comparing Android and iPhone development with a focus on tools, platform and the developer experience.

Before going much further I should note that my comparison is with considerable bias. I’ve spent the past 12+ years in Java development, having spent much of my career building developer tools. Since January of 2004 I’ve been building plug-ins for Eclipse, and before that plug-ins for NetBeans. This bias is somewhat tempered with several years of C and C++ development. With this background I find that I’m very critical of developer tools. Developer productivity is key — anything that takes away from the flow of a developer in the zone is a real problem.

Language, Programming Model and Platform

Language

The language of choice for iPhone development is Objective-C. Objective-C is a language based on C with extensions for object-oriented concepts, such as classes, inheritance, interfaces, messages, dynamic typing, etc. The Java language is used when developing for Android (though it doesn’t actually get compiled to bytecode).

Java is a no-brainer. I have to say that it’s nice not to have to learn a new language to target mobile. Existing skillsets don’t come easy — so reuse of expertise is worth a lot.

It took a little while to wrap my head around some of the language features available with Objective-C. I soon discovered that I really loved certain language features, such as message passing (instead of calling methods), categories and named arguments. I did find however that the syntax of Objective-C is cumbersome. I’m still not used to ‘+’ and ‘-’ for static and member methods, too many parentheses are required, and in general I just felt like I had to type way to much to express a simple concept. The IDE didn’t help much with this either (more on that later).

One thing that really became clear to me is that Objective-C, though it may have been visionary for its time, is really a language of the '80s. Certain issues such as split header and implementation files and violation of DRY are really time-wasters, and not small ones at that. I found myself constantly switching back and forth between files, which not only has a cost in navigation (which file to open?) but with every file opened your sense of context must be recreated (where’s the caret, what’s selected, where am I in the file, how is this file organized).

As far as DRY, must I really do 5 things to declare a property?? (declare in the class definition, again to declare getter/settter, initialize in the init method, @synthesize in the implementation, release in dealloc). Here’s what I mean:

If you ask me, everything in Server.m should go away. Another gotcha here is the positional relevance of @synthesize.

Java has a similar problem with properties, though not quite so bad — and the IDE helps you write your getter/setter.

Pointers in Objective-C, though powerful, are also another time-waster. This is where Java really shines with its garbage collection. I found that I was constantly considering whether allocated objects were freed appropriately. Code flow is poor since application logic is littered with memory management. I only have so many brain cycles available — why do I have to think about this other cruft that’s not really a core concern of the application domain? Of course this gets even worse when trying to figure out where things went wrong if you make a mistake. Zombies help, but still don’t make it obvious if you’ve accessed something that was deallocated. Other issues include deallocating something twice, autoreleasing something twice. I also found it non-intuitive when to retain return values from methods.

Another annoyance of Objective-C is the patterns that must be followed: implementing correct init and dealloc methods is non-trivial. @synthesized getters and setters for properties with retain should not be called in these methods. So many conventions and rules to remember!

Though I understand why there’s a separation of alloc and init, it’s still overly wordy to specify [[aloc Foo] initWithArg: arg]. Why not just [new Foo arg]? Or how about new Foo(arg) -- oh, wait, that’s just like Java!

Objective-C’s imports and forward-declarations (@class) are a pain. Though these issues exist with Java development, Eclipse’s JDT is so good that I’ve almost forgotten what it’s like to write an import. All you have to do is Ctrl+Space to auto-complete a class name or Ctrl+Shift+O to organize imports and voila!

Of course Java is not perfect either, however this fact is hidden from me due to the fact that I’ve been living in Java for a very long time. Sometimes I wish that Java were more Groovy-like, however I’m used to it and the tooling is so good.

Platform

On Android I found that I could readily use the Java runtime classes. Some, but not all, of the standard Java RT classes are available on Android. I didn’t find this a problem, since most of the standard Java IO, network and regex libraries are available. Android RT classes appear to be based on Harmony, which has been around long enough to be stable.

With iPhone on the other hand, finding the functionality that I needed was painful. Classes and methods are poorly organized. When to look for a static method versus a class with members was not clear to me. Also depending on the framework used, naming conventions and code organization would differ. I suppose this is the legacy of an older platform. Areas where functionality was lacking that I found painful were regular expressions, string handling and XML parsing. I ended up using the excellent Regex Kit Lite for regular expressions. For XML parsing I implemented a parser abstraction over libxml, only to discover later that I may have had an easier time with NSXMLParser which is a lot more like SAX.

On the iPhone when things didn’t work as expected I had to resort to Google and hope that others had encountered the same problem. This technique was hampered by Apple’s earlier NDA policy, which meant that iPhone content is pretty thin on the net. In some cases I would resort to guesswork and experimentation to find a solution.

Android has the benefit of being open source. Within minutes I had the full Android platform source code on my system, and had re-built the SDK from sources to ensure that the source I had matched the runtime classes in the emulator. So not only could I see how things were implemented in the Android platform and learn by example, I could step through the platform code in the emulator and discover why my code wasn’t producing the desired results.

In general I found the layout, organization, and naming conventions of Android platform classes was consistent and predictable. This made it much easier to learn.

Programming Model

The iPhone platform does a great job of encouraging an MVC design pattern. With this design pattern built in to the platform, building the UI was simple and I didn’t have to figure out how to organize the UI component design myself. It also means that when looking at sample code, it’s all organized in the same way.

Android also does a good job with design patterns, though their concepts varied significantly from the iPhone. With Android’s support for multiple processes and component reuse, the platform itself provides support for Intents and Activities (an Intent is just a variant of a command). The design results in a better user experience, however it does introduce some complexity for the developer: when starting one Activity from another, an Intent is used to communicate any parameters. These parameters cannot be passed by reference — only by value. Where on the iPhone it’s simple to have screens sharing the same data structures, on Android this requires some forethought. Apparently Android applications can manage the back button and have everything occur inside a single Activity, however this is not the norm.

Both Android and iPhone provide a way of declaring user preferences in XML. Both platforms provide a default UI for editing those preferences, which is great. Android’s XML format is extensible allowing custom UI components to be integrated, which makes user preferences a breeze. iPhone developers that wish to customize preferences will have to implement a UI from scratch, which is a lot more work.

Testing and Continuous Integration

I’m of the opinion that every development effort should include unit tests. Teams of size greater than one should also include Continuous Integration.

Android developers will be happy to know that they can write JUnit tests. I could even launch these from the Eclipse UI after some classpath fiddling. Though I didn’t try it, I assume that it’s trivial to run these from Ant and your favorite CI server such as Hudson.

I did see some iPhone unit test documentation with the iPhone SDK but didn’t take the time to explore it — so I can’t comment there.

Resources

Apple does an excellent job of providing lots of resources for developers. Important concepts are explained in videos, which makes grasping concepts easy — however I did find that videos progressed slowly and I was watching for what seemed like hours to find information that should have taken minutes. Luckily Apple also provides lots of sample applications and code to demonstrate API usage.

Android developers also have access to loads of resources. The guide and API reference are installed with the SDK, so everything is available when offline (which for me is important since I do a lot of my work in transit). I found the Android development resources better organized and spent less time looking and more time finding. In particular the ApiDemos sample app provides a great starting point. I also downloaded many open source Android projects for ideas on architecture and API usage. This is an area where Android has the advantage, with Apple’s previous NDA policy there isn’t much out there in terms of open source for iPhone.

Tooling

For me tooling was a real shocker. These are the categories of tooling that I’ll cover: IDE, UI builder, debugger, profiler. Almost everything else is related to provisioning, and in that area I didn’t notice much in the way of differences between Android and iPhone.

IDE

Android development leverages the excellent JDT tools, which are pretty much stock and standard with every Eclipse installation. I’ve used these tools now for many years and they’re excellent. Everything Java is indexed, the IDE has a rich model of the source code, and refactoring is so seamless that it has changed the way that I work.

Perhaps the best feature of JDT is its incremental compiler, which provides immediate feedback with errors and warnings as you type. This eliminates the code-compile-wait-for-feedback cycle that was so common in the '80s and '90s. Errors and warnings are updated in the Java editor as I type, giving me instant feedback. I didn’t realize just how valuable this feature is until I was coding Objective-C in XCode — when I became acutely aware at how waiting for compiler feedback can break the flow of programming.

Other key features that make Eclipse so amazing to work with are:

content assist

quick-fixes

organize imports

open type (CTRL+Shift+T)

refactorings

Integrated javadoc and content assist is quite possibly the best way to learn an unfamiliar API. In Ecipse not only are all classes and methods immediately available in the context in which you’re writing code, their documentation is presented alongside.

Content Assist with Integrated Javadoc

XCode is so shockingly bad that I almost don’t know where to start. Here’s a minimum list of things that I think need fixing in order for XCode to become a viable IDE:

Content assist that actually works. Content assist provided by XCode is often wrong, and almost always suggests a small subset of what’s actually available.

A decent window/editor management system. XCode and it’s associated tools (debugger) like to open lots of windows. Want to open a file? How about a new window for you! Very quickly I found myself in open-window-hell. The operating system’s window management is designed for managing multiple applications, not multiple editors within an IDE. It’s simply not capable of providing management of editors in an environment as sophisticated as an IDE.

A project tree view that sorts files alphabetically. Really!

Integrated API documentation. I found that I was constantly switching out of the IDE and searching for API documentation using Appkido. This may seem trivial, but it really breaks the flow.

One area of Eclipse that simply can’t be matched is Mylyn. Integrated task management and a focused interface introduce huge efficiencies into any project, small or large. If you haven’t yet tried out Mylyn, it’s definitely worth your time to take a look. A good place to start is Mylyn’s Getting Started page.

UI Builder

iPhone app developers are given a pretty good UI builder. It does a great job of showing the UI as it will actually appear. It’s flexible and can model some pretty sophisticated UIs, so I was impressed. I found that using it was a little tricky — I had to read the documentation two or three times before I could really figure out how to use it properly.

The Android UI builder I found pretty useless: it can’t display UIs how they’ll actually appear, and it’s UI is way too inefficient. I found that I coded all of the UIs directly in the XML source view of the UI builder. There the content assist and validation were pretty good, making it the easiest way for me to build a UI.

Debugger

Having used to the Java debugger in Eclipse I was shocked at the state of the debugger in XCode. With Eclipse I can see and modify variable values. Not so in XCode. Maybe this is simply the state of affairs when debugging native code, but it sure affects the usefulness of the debugger. XCode often seemed confused as to the type of an object and presented me with a pointer value and no detail. This is a sharp contrast to Eclipse, where I can drill down through an object graph with ease.

I found the XCode debugger UI extremely difficult to use. Clicking on the stack to show code in an editor caused new windows to open, eventually resulting in dozens of windows open. In addition I found that watch expressions rarely worked for me.

Profiler and Heap Analysis

An area where Apple development tools excel is in profiling and heap analysis. These tools seemed mature and easy to use. With no prior experience with these specific tools I was able to gain a better understanding of my app within minutes, find and fix several memory leaks and improve performance.

XCode Memory Leak Detection

Android developers must use Android’s traceview application, which I found worked well but required significantly more effort to configure and operate. I was surprised to find that the source code must be changed in order to get the trace files required for analysis.

I’m not sure if Android can provide heap dumps in hprof format. If it can then the awesome MAT tool could be used to analyze heap usage. According to this article Android can produce hprof heap data, though I haven’t tried it.

App Store

It goes without saying that the iPhone app store is excellent in that you can sell into many countries worldwide with a single setup. I was able to provide my Canadian bank account number, sign a few legal agreements and I was up and running.

Getting an app into the store however is frustrating to say the least. Apple must approve every app before it is accepted into the store. Mine got rejected multiple times. Each time it was rejected I was given almost no information about why. When I emailed them to clarify the problem, I received what looked like a canned response indicating that I should refer to previous correspondence. If it weren’t so frustrating I would have found it funny. I highly recommend reading Brian Stormont’s Avoiding iPhone App Rejection from Apple and Dan Grigsby’s Part 2 follow-up.

Of course once I started selling Hudson Helper I realized that Apple won’t send me any money unless the payout is greater than $250. This is true not only of the first payout, but every payout. Google market on the other hand requires a minimum of $1 for each payout. Both the iPhone app store and Google market take about %30 of your app selling price. $0.99 applications have to have high volume, or they’re simply not worth your time.

The Google market by comparison to the Apple app store is terrible in that you can only sell into a handful of countries. You also can’t see or install apps that cost money on a developer phone. Actually you can, but not if the app has copy protection — which is almost every non-free app. On the other hand when you upload your app to the app store it’s available within minutes, so you don’t have to worry about an approval process.

To set up a merchant account with Google market, I had to provide a US address and bank account number, since Google doesn’t support Canada. For me this was a pain, but not too bad since I live within a few kilometers of the US border. I rode my bike down to the US and opened an account with Horizon bank. The bank required a passport and driver’s license, so no problem there. Why Google doesn’t support more countries I don’t know. At the very least Google market should accept alternate payment methods for countries that are not supported by Google checkout.

Summary

Android’s platform and developer tools are excellent. Leveraging Java and the Eclipse IDE are major winning factors for Android. Apple’s developer tools are shockingly bad by comparison. The Objective-C language and platform APIs are cumbersome and poorly organized. Overall when developing for the iPhone I felt like I was back in 1993. These factors combined in my estimation make application development about three times more expensive when developing for iPhone. The only area where Apple’s developer tools excelled was in profiling and heap analysis.

Apple’s app store from a user’s standpoint and from a worldwide coverage standpoint are excellent. In this area Google market for Android is weak.

Development for iPhone may improve as tools such as iphonical (MDD for iPhone) and objectiveclipse (Eclipse plug-in for Objective-C) emerge.

We may see a shake-up in the mobile market, with at least 18 new Android handsets being released this year. Until that happens, iPhone will remain a market leader and developers will have to put up with XCode and Objective-C.

For me, my love is with Android. Sure, the iPhone is great — but can you install a new Linux kernel?

95 comments:

The problem with the iPhone SDK is that it is new and was very rushed. Every release gets a bit better and XCode 2.0 to 3.0 was a huge difference.

For documentation, highlight a class type, right click and click on lookup in api reference. You can also open the documentation via the help menu. I still find myself looking at the documentation a lot due to extremely verbose and oddly named functions.

My biggest issue with the iPhone is the crappy code signing and submission system. Not to mention being rejected for whatever reason Apple wants makes it very hard to form a business around the platform.

Overall it's not a bad platform but they still have a ways to go to make it nice.

All your arguments favor Java because that iswhat you are familiar with. Just because you had to learn something new when trying out iPhone development doesn't mean it's bad. This article might as well have been written by a long time ObjC programmer and favored iPhone.

I've done work on both platforms, but I have a stronger background in Objective-C. I'm afraid your review seems a bit biased. Just take a look at this line: " Within minutes I had the full Android platform source code on my system, and had re-built the SDK from sources to ensure that the source I had matched the runtime classes in the emulator."

I don't ever want to re-build an SDK from source. You shouldn't have to!

Also, XCode has a very nice integrated documentation system (it has since the iPhone SDK came out). To access it, go to Help and select Developer Documentation. You can also option-click on any class name or function to jump to it in the documentation.

I understand that you're a huge fan of Eclipse, but I really love the lightweight feeling of XCode. It's mostly a personal preference, I think - but I love that the project browser is NOT organized alphabetically, (because I want to group all my view classes, all my model classes, etc... together), that it's search/replace isn't unnecessarily complicated, etc...

You should definitely check out Cmd-Alt-UpArrow too. It seems you know all the Eclipse shortcuts - and XCode has some pretty cool ones too!

This post closely echoes my experience (pros and cons) on both platforms. I have to admit I've tried several times to like Objective-C and just can't. It's not even Java experience that gets in my way as much as C and C++ experience ... in Objective-C I am very wrong-instincted. I think if I could commit to being a full-time Apple developer, this persistent feeling would change. But that's not really likely for me personally ... although all the computers and phones I've purchased in the last 2 years are Apple-made, most of my development work needs to be cross platform.

I do think Android is just easier to hop into for most general developers who are not Apple specialists. The barriers to creating and releasing (and hopefully monetizing) an app are also lower. This ease to market could amount to a powerful advantage eventually.

This seemed much more a comparison between obj-c and java (and the gripes of a java programmer coming to obj-c) than a comparison between the platforms. It seems that several of your concerns came down to the IDE and not the language its self (tho the IDE is a significant part of the process).

The whole post seemed quite biased against Objective-C / Xcode just because you aren't as familiar with them. One specific correction is that Objective-C does not have named arguments, arguments are interspersed within the method names. There's a good article about it here: http://www.mcubedsw.com/blog/index.php?/site/comments/the_named_argument/

It was an interesting review, but the bias towards your favored development environment was all too obvious... If you had tempered some of your criticism's of iPhone development with the acknowledgement that your limited experience with the IDE might be part of the problem I could have accepted this as more of a valid review. Some of your XCode observations are just plain wrong, you just didn't know how to use the IDE, declaring it bad and broken based on your limited experience did no service to you or the IDE.It sounds like Android has put together an environment that might be better than Apples, but bashing Apple given your limited experience undermines the real story you could have told. I've used xcode, eclipse and variety of other ide's. None have every really captured my attention, I regularly find myself back in the comfortable arms of emacs and make. But some of the features I've found in xcode and some I'm looking forward to in upcoming version make it a strong contender. I doubt if there's anything Eclipse can't be prgrammed to do, but bloated slow performance is a price that I rarely care to pay. In the future it would be more honest to temper your comments about using a new tool, or maybe you should just stick to singing the praises of java and eclipse which you are obviously very fond of.

I am appalled by the extreme and unjustified bias in your article. Clearly, you did not spend enough time even trying to get to know XCode.

As other commenters have already mentioned, XCode supports one-window mode, built-in assistants, and other things you complained about. Two things that no one else has mentioned, however, which show your lack of interest in trying to do a fair comparison by really trying to immerse yourself into the iPhone development model are:

a) you complain about the lack of online resources, but Apple has an extensive developer site, and there is an entire community of people, many working for Apple as engineers, which discuss Cocoa and iPhone development in the cocoa-dev mailing list.

b) your complaints about property definitions show that you do not understand what Obj-C properties are.

@property (nonatomic,retain) NSString *name;*is* the property declaration, so you only declare a property once, not 5 times.

Properties need not be backed by ivars and, in fact, they are completely distinct concepts.

@synthesize name;is a shortcut that tells the compiler to implement the accessor methods for you, but you can implement them yourself, if you want, so you don't have to use the synthesize directive.

Finally, releasing memory in the dealloc method has NOTHING to do with properties per se, so that should have had no part in your complaint regarding properties.

As I said, your (mis)understanding of properties is the reason for your complaints. Had you attempted to understand the concepts involved, rather than proceed based on guesswork, your experience would have been different.

In any case, allow me to offer a constructive suggestion: next time you set yourself into the path of comparing two technologies, make sure first that you have a balanced understanding of both.

Clearly, in this case, you knew a lot about Android development and nearly nothing about iPhone development. You should have acknowledged that fact upfront, rather than bash the platform you knew little or nothing about.

The iPhone platform isn't perfect and Apple's development tools aren't perfect, but your conclusions that "Apple’s developer tools are shockingly bad by comparison" and "the Objective-C language and platform APIs are cumbersome and poorly organized" are totally unjustified, based on your complete lack of experience with them.

I really have to disagree with the last comment. I've been using Objective-C before I was using Java - in fact, my first box was a NeXT box and I went on to learn Java when it first came out. The point of the article - that the XCode tools are really quite poor - is a perfectly reasonable observation, and one I've done myself too.

Apple's frameworks and operating system philosophy is great; their tools (particularly interface builder) were ahead of their time, and they provided a GUI environment in the times of curses-based text viewers.

However XCode really hasn't changed that much, and that's still the problem regardless of familiarity with the tool or with the language. Yes, there are some short key codes but there's no Mylyn and no Git support, and Apple wouldn't add either. There's a whole lot that is missing, but until you've used both, you don't get that view of the comparative views. So coming from an "I've used XCode and it's great because it's the only thing I've used" is just as bad as the reverse position.

@Anonymous thanks for your comment. I feel compelled to respond to some of your statements:

> Clearly, you did not spend enough time even trying to get to know XCode.

Actually I spent a few months using it.

> As other commenters have already mentioned, XCode supports one-window mode,> built-in assistants, and other things you complained about.

In one-window mode editor windows still open. The assistants (in particular content assist) didn't work well for me. Granted that with dynamic typing it's sometimes impossible to provide all available options -- however in many cases it simply failed to provide obvious suggestions, and often made incorrect suggestions.

> you complain about the lack of online resources

Actually I said "Apple does an excellent job of providing lots of resources for developers."

> your complaints about property definitions show that you do not understand> what Obj-C properties are.

Terminology aside, I still have to create 5 snippets of code to make a property work.

> Clearly, in this case, you knew a lot about Android development and nearly nothing about iPhone development.

Actually I was new to both Android development and iPhone development. This article was written after spending a few months with each.

there's a new iPhone SDK out called Corona that's based on Lua, its way eaiser than dealing with Objective-C. If you know C or actionscript etc, its super easy to pick up. www.anscamobile.com They've got an early adopter program which is free right now if you want to check it out.

Thanks for the nice comparison. I recently went through a similar comparison experience, having developed Java on Eclipse for several years, then six months ago switching to developing for Mac on Xcode. I think you're right on with your comments.

Eclipse can be overwhelming when you first use it. It takes a while to learn which features are important and which to ignore. Eclipse is a memory pig, and can be really slow on older systems. Nonetheless I think it is the best IDE available for Java development (and Python, PHP, etc. -- C/C++ not so much).

When using Xcode you can really cut down on the number of windows by using the "All-in-One" layout (I can't imagine how anyone manages otherwise). Interface Builder is really great. The Xcode debugger is bad, but I believe that's because it's just a front-end to GDB.

XCode works just fine in a single window. Single-click on files in the group tree or file listing to have them appear in the same window in All-in-one mode. If you double-click it will open a separate window.

Regarding new windows opening when you open a new source file, there are preferences to prevent that. I can't say exactly what they are because my work box is Linux, but it's in there. A good friend of mine who does lots of iPhone apps (i've only done a couple) only ever has one window open in XCode.

Otherwise, I'm not getting all nitpicky about your writeup, since I feel about Eclipse the same way you feel about XCode. (and I do about half of my Objective-C development in Vim anyway)...

Objective C sucks and XCode sucks even more. Absolutely horrible. I wish Apple changes its mind and does what developers love instead... Embrace .NET, or Java... Python, even. Something. Not JUST Objective C. Oh, and bury XCode for good while you're at it.

I think what's almost more interesting now is reading the comments. Especially both Anonymous comments referring to how the respective "other" technology "sucks".

I think it speaks to how it can clearly take some time to get to know a new technology before you really understand its subtlety and true power.

When I hear of "embracing .NET" I shudder. I have programmed in .NET and feel cocoa is a much more powerful framework. Now that opinion I would suggest is possibly down to the fact that I am much more familiar with cocoa and its more advanced classes.

It will also be interesting to see both communities and tools develop over the next couple of years. The one thing we can be sure of is mobile development has definitely "gone mainstream".

I'm porting a mid-size project from iPhone to Android. My background is in Java. In my opinion, Java beats Objective-C hands-down (especially because of garbage collection) and Eclipse is way ahead of Xcode in terms of productivity. However:- Apple's Cocoa Touch API is much more mature and well thought out compared Android's API. In places, Android seems amateurish, and I find myself fighting with layouts, animation, and XML files.- Android has no JIT or native floating point support which makes it slow as hell. The fact that the Android NDK exists makes me think it will be a long time before we see a JIT on Android.- The project I'm working on, with 200+ images, takes 20-30 seconds from hitting the build button to running it in the emulator. The same project on iPhone takes 1-2 seconds. The 15-30 second delay kills productivity. (I don't see the delay on small Android projects with few images - just large ones).

I love Java, but Android just isn't good enough. I'd rather develop for iPhone.

Wow, great read mate and I must say that this hit home becuase I'm actually starting to create a game in J2ME starting this Monday! (I will be posting a dev log on my blog), I chose J2ME over Android becuase I just like the syntax and I never tried iPhone dev because I dont own a Mac.

Sorry if this sounds harsh, but this is by far THE most ridiculous comparison I've seen in years. For background, I've used Visual Studio and .NET for years, heck I've even spoken at conferences about .NET tools and languages. But I choose to change. The same way I choose to read 6 tech books every year, the same way I choose to learn a new programming language every year, I choose to learn ObjC and I choose to accept new things. It's part of an open mindset. Otherwise, stay where you are, there's no shame, but please grow up. And most importantly, don't try to justify the clumsiness of your favorite environment (or probably the only one you really know) by stating comparisons that do not apply.

Java is Java, ObjC is ObjC. Java is statically typed. ObjC is not. Hence, Java is a no-go for me. You can do things in a dynamic language that you can't do in a static one. You need less code. And even better, in ObjC you can choose how much dynamicity you want. You can be as static or as dynamic as you need.

Xcode is lightweight, it does not stand on the way. Eclipse is clumsy, takes ages to launch, and the whole Java stack is daunting and ridiculously huge, and most of this is *because* of the static nature of the language. Java is a liability. Not an asset.

Memory management is *not* that hard. Now the Clang static analyzer has been included in Xcode too, so most of the leaks will be spotted during the analysis. And with a bit of discipline, you learn to spot most of them in no time. Garbage collection is a nice help, but the lack of it makes the iPhone snappy, fast and lightweight. Tradeoff accepted.

If you find that software engineering is hard, well, welcome to the real world. You can always stay in your garbage collected wonderland with syntax sugar and strong types if you feel like it. In the meantime, will you excuse me, I have a couple of iPhone apps to finish.

Thanks for the comparison that has made my mind up about what phone i am going to buy i was between the iphone 3gs and the android platform but after reading your excellent review from a programmers side of things , i am with you android has my love too after seeing the htc hero but hopefully they will be better phone soon but this is a great starting point for now and keep up the good work , lets get more apps into the android market to beat apple down it will take a while but we have time that is true.

Interesting read, but severely hampered by some very obvious beginner's misunderstandings about ObjC.

- Methods that start with a + are not static, they're class methods. Ones with a - are instance methods- ObjC does not have named arguments.- In the section where you show how often you declare a property, the first time within the @interface section is not actually declaring the property, but an instance variable.

All of these examples kind of show that you don't completely understand what's going on.

Again, interesting read, but you should do a bit more research on ObjC and the iPhone frameworks before you can really make a solid comparison between them and anything else.

"- The project I'm working on, with 200+ images, takes 20-30 seconds from hitting the build button to running it in the emulator. The same project on iPhone takes 1-2 seconds. " I wonder how iPhone achieve this phenomenon speed given that iphone is still using emulator during development just like Android. Perhaps something Android team can take note of and make use of technique used by iphone to achieve such impressive feat. It could not be that just by using Objective C, it will result in such big improvement for deployment to emulator.

I prefer VS but have programmed using Eclipse, XCode and a half dozen other IDEs great and small.

I consider myself a hardcore C++ developer but I also use Java and since 2005 Objective-C regularly and take pleasure in developing in other languages every chance I get.

Everyone here with any experience at all will have a similar story substituting there personal experiences.

IMHO, we are here arguing because, hate it or love it, Apple has provided a great platform, a great set of development tools/libraries, and a great market place. Great enough to bring players from other platforms to develop for and scrutinize.

I remember having/reading the same types of arguments around C++ , Java and its earlier IDEs, Qt, .NET, SOA, Web 2.0 and other technologies/computer languages. Thank god for variation. We would other wise have nothing interesting to talk about.

Interesting comments. But as you say yourself it does show your bias from working so long with java.

A lot of your negative comments (e.g. about how to use the IDE, lots of open Windows etc) just show inexperience with working with Mac software in general and xCode in particular.

While Objective-C is often quite verbose, I find that for larger applications Java requires you to do a lot more typing. In java you end up having to subclass and define interfaces all the time, where in Objective-C you just send a message.

The dynamic nature of Objective-C can save you a lot of code. Implementing something like delegating in Java is going to require a lot more code than in Objective-C.

I agree the .m and .h file separation and #import is old fashion compared to Java. But I still think a lot of the flexibility from the dynamic nature of Objective-C makes up for a lot of short comings in other areas where Java has an edge. And let us not forget the ability to seamlessly integrate C and C++ code

@Adam Smith I agree that more experience with XCode would have helped a lot. Especially wrt opening new windows: By using different key/mouse combinations and All-In-One layout new windows are opened much less often. When it comes to window management, XCode with the default settings makes it too easy to have a bad experience.

@Richard re: cost of phones and development: I'm sure if you already have a plan, then an iPhone costs more, but for me I had to sign up for a plan to do either. After signing up for a plan I still had to buy the Android developer phone -- so the price comparison works out for me.

Programming-wise, I prefer Java; however, I wish I could switch to full time Mac developer job.Too-low-entry caused too much outsourcing in corporate IT where java (precisely j2ee) is mostly favored.The same thing will happen to Android development too. Market will be flooded with both developers and crappy apps. It is an industry obsessed of digging a hole and burying itself.

Thanks very much for this - unlike other readers I fully accept your caveats about your experience in Java and relative lack in Objective c.

I've been a web developer for years, but mostly in scripted languages as opposed to OO. My experience with iPhone development is somewhat similar to yours - too 'wordy' to be easily picked up quickly.

I've ditched the iPhone stuff for the moment and am going to concentrate on the Google Android element, Eclipse sounds like a great tool.

If this lets me grasp the fundamentals and lets me get a few tools into the marketplace, then I might go back to iPhone in future with a greater degree of confidence.

Plus the fact that the problems getting apps approved and deployed (and getting any visbility once you have done) means that I'll stick to Google and Android, given that I see them surging forward in the next few years just by the number of handsets that are due to be launched.

By the way, I've dropped ObjectivEClipse 0.2, which has Mylyn support. Clearly, it's still very early days and not able to come anywhere near to replacing Xcode yet, but it does show the kind of innovation that can happen to provide a different kind of IDE experience.

I respectfully disagree with many of your conclusions, but I don't think you've exhibited any biases that you haven't also acknowledged. In any case, I now work full time on iPhone projects and the most complimentary thing I can think of to say about Xcode is that it's *ahem* unintuitive rather than unproductive.

From my experience, installing the SDK, the Eclipse tools, and setting up the emulator, took way more effort than getting everything installed for iPhone development. It takes 3X longer to install and set everything up for Android than the iPhone, because you don't have to do anything but download and install for the iPhone.

@ Sean ChapelIt couldn't have been that rushed, as they used it to create all the software that came on the iPhone to begin with, including quite a bit of the OS.

i read this article before starting iphone development about a year ago - i just stumbled across it again, and re-read it. I have to say, most of this article says more about how difficult and weird iphone development is, but little about how efficient and enjoyable it can be once you are proficient at it.

I just started android dev, and I'm back to being confused, frustrated, and wishing I could go back to iPhone dev (despite being a 12 year java dev).

So, it really is what you're used to - i'd love to see a follow up article from someone who's spent a good chunk of time with both environments and understand why XCode/Cocoa/Obj-C are the way they are and the oddities of android dev (for e.g. nowhere is it mentioned that the android emulator takes anywhere from 30s to 2m to install and run a simple app).

In my estimation, iphone, with its cocoa history is by far the more mature platform and SDK.

I am really surprised with this article as someone who has much experience in java and almost none on Objective C dare to compare those two languages and platforms.I have a lot of experience in developing applications on C++, Objective C.What I was struggling about this article is to pick from tit how much experience the writer has on developing with xCode and Apple dev tools and as well probably no experience (at least not serious one) with Objective C and mobile development. Firs if you are talking about two platforms which you use to develop mobile application you must know some things about mobile and embedded development first. You are glorifying garbage collection on mobile device? First Garbage Collection takes too much time for processing and do not forget that you are developing for device 100 time slower then your slowest desktop (CPU520Mhz with 256MB of RAM). Mobile device does not have so many resources so having garbage collection is not an option. By the way if you use Objective C for MAC and Cocoa dev then you can use garbage collection as it is available on the framework but it is not available on iPhone SDK for a reason.Knowing the memory allocation and language internals (compiler as well) will not give you headache for memory management. If you learn reference counting internals and just simple Get, Copy and Alloc rules you'll be absolutely fine with when the function returns the ownership and when not (and thats it only for the API of the SDK it self as with your own classes you can do what you like). But as you used to use garbage collection your perception of the memory allocation is completely different so do not compare this two things at all.Why I got impression that you do not have serious experience of Objective C is that you are complaining why you have alloc and init in combination. If you read docs you will find that there is constructionNSObject* obj = [[NSObject alloc] init];andNSObject* obj = [NSObject new];

These two constructions are the same my friend.

You said it is language of 80's. So I would really like to here a bit of explanations here WHY. What Java brings to the market which is so modern that Objective C does not. If you speak about protocol in development it self I must tell you that Objective C has totally different approach to development so you cannot compare it with Java. Especially as it is dynamic language (Java is static like C++) and you can do so many powerful things in the runtime like (adding new methods to the class in runtime, posing classes if you know what does it mean and a lot of other useful thing which you cannot do with Java or not in so elegant way like in Obj C).

From your example I can see that you do not have much experience in using getters and setters properly as you are not using it properly like an advance developer. Let me show you what I am talking about:

Server.h should be

@interface Server : Updatable {@private // as you want to hide the real storage from user of this classNSString* _name; <-- declare the property }

-(void) dealloc { //[name release]; <-- THIS IS WRONG AS YOU SUPPOSE TO USE SETTER FOR THIS self.name = nil; // Much safer}

what will happen if you did in a code [name release]; without NULL-ing it. In your dealloc it will bomb as you will try to use the pointer which is corrupted. With mine construction self.name = nil you are always safe.

THis is a simple basic use and from this I can see that you do not know the basics of memory management as I can expect it if you are used to use garbage collection for a years and do not bother whats going on under a hood.

In mobile dev everything is about a speed. So doing things properly will bring a boost to the application.

Use this link (http://cocoawithlove.com/2008/12/instance-variable-to-synthesized.html) to automate the getters/setters in xCode from IDE.

You mention so many things about Objective C which are not true as you saying Objective C is an old platform. So how old Java is then?Docs is really good if you know how to use it from xCode. Class organisation is really simple and you can find in docs inheritance tree. But if you know the iPhone SDK (like you do java) you will not be bothered with the question of which method to use and from which class. Now you do as you do not have enough experience with it and you are probably at the beginning of the learning curve so it is expected.

Comparing Eclipse and xCode. Do you want to tell me that docs are not integrated in xCode (if you do like you did in your post then you are wrong). Use alt + mouse click on any message and it brings the assistant or you can enable Quick help and it will show you the help in the docs for messages as you type.Second you cannot compare Java with Objective C as java is not compiling in binary code like Objective C does so compile process for Objective C and C like languages are slightly different then java as they do not need VM. So do not compare that.There is a refactoring in xCode but obviously you do not know how to use it.If you do not like many windows why didn'typiu set All-in-One in xCode so you can with one mouse click set your look of IDe for dev or debug without opening new window. What about splitting window on two and see one file on left / top and another on right / bottom. What about small icons on the right part of the window where you can use many options available for your current file and class you are working on. You need a serious lecture for xCode. Not able to change values in debigger in xCode is not true. YOU CAN DO IT MATE. If you have a pointer and want to se a detail just place your cursor on top of the variable name and after a sec it will offer you a small window where you can use disclosure button to open for details. The sam in debugger variable pane.

I am tired of typing so I must give you a suggestion. Before you do a serious dev on a new platform and try to write a comparision like this be sure you have learned an things or two about it.

@syberglitch Thanks for your comments and suggestions. A few of points you make are worthy of some attention:

Regarding garbage collection: though you may be right in that garbage collection adds to processing overhead, the extent to which this is true depends entirely on the implementation. Ruling it out due to platform limitations is just plain wrong. Garbage collection is used successfully in mobile devices, as demonstrated by the Android platform. My point is that memory management code obscures application logic.

I agree that Objective-C is powerful and has some great language features. What I take issue with is the cumbersome syntax and weak IDE support.

Regarding dealloc and releasing instance variables, you may be interested to see this quote from Apple's book The Objective-C 2.0 Programming Language:Typically in a dealloc method you should release object instance variables directly (rather than invoking a set accessor and passing nil as the parameter)

You missed the point about documentation integration in the IDE. With thousands of apis it's impossible to know it all, no matter how experienced you are.

You're right about the all-in-one mode. It's too bad it's not the default setting.

I'm not sure if you noticed: I did say many good things about the Apple/iPhone side as well!

As I am aware of Android platform is that when garbage collection kicks in all the UI stuff are frozen until its finished so using garbage collection you must be really carefull about how many objects you are allocating at the time.Second in ObjC you have one really useful thing as Auto Release Pools. You can make and instance of your class as autoreleased which will be released on next Run loop event (which can be UI event). So there you are something similar (not like GC but useful). The only think you have to be careful about the lifetime of the object. But simple if you want to take an ownership just do retain on it and you will be responsible of destroying it. So memory management is simple.The GC is not on iPhone simple just as it should not be on any embedded device not because of device limitation.I do not think that memory management obscure application logic. The whole thing is about it. Playing with memory management can bring you many powerful things. So many designs in app development relays on it (especially on embedded devices where you suppose to save as much memory as you can so how to do it if your not handling it). I do agree with you that in many occasions you can shoot your self in the foot if you are not careful but you can do that with GC as well. The thing is that what its says in docs for dealloc is not what I suggested you. As depends on how did you declare your property.If its retain then null-ing it is the same as releasing it but it is safer as after it release it it just null-s it (which developers forgot in most cases). Nulling the pointer in destructor is not needed but is a good programming practice. To give you an example of retain setter

@property (monatomic, retain) id setterForVar;

when its compiled is converted to this

- (void)setterForVar:(id)value{ // If value is null nothing happens [value retain]; // this is the same as you would do it manually [setterForVar release]; // here if value is null we simple null the pointer setterForvar = value;}

I saw so many bugs because someone forgot to null the pointer. So my advice is if you have property for your var use it and do not release it in the class code so often as it is bug prone. Use setter as it is safer.Another thing with GC is that it can happen in many occasions that you have object which is not needed by anyone and it is still there in memory occupying valuable space just because GC did not kicked in yet. Then my question to you is multithreading and GC? Think about that as well. I agree with you as GC wipe away all your problems with the memory but it brings a lot of overhead as you mentioned as well and certainly uses more resources then without it. Why you are afraid of memory management. I herd this from many java developers. There is a big possibility for every one not using GC to do a bad things but we should not be afraid of development as if someone afraid of driving the car it does not drives it as there is a possibility to crash.Application logic is not about memory management. Application logic is about your class relationship and data passing one to each other. About who is responsible of what. When you do an UML design for you app you are not using memory management at all and probably you are not think about it. If you compare two platforms then you suppose to have completely different approach as a developer. By the way do not let the tool to choose your app for development do it opposite. Design app and then choose a tool.

About docs. I did not missed the point as thousands of apis at=re there for Android as well and Java as well. So what is a difference. If you are know what you are looking for then it is fast. For me (and I have many, many years of experience on mac with ObjC, Coco and iPhone) and I did not spend more then 5 min to find what I am looking for. If you want to do something and you do not know what to search for then you must know which part of the api you are using (is it graphics, audio, video, UI control or what) then narrow your search with the category.

Do not get me wrong as I did not want to criticise so much the only think is that I found many things in your blog which were not true.

By the way I have more then 17 years of experience in C, C++, Assembler, more then 5 years in ObjC (I really do not know how many years) and about 10 years in embedded development of which is 5 years in mobile industry. Currently I am developing apps for iPhone, Symbian and Android for the last 4 years mainly.

It is interesting to see the difference experience in tools sets makes. In my case, I come from 10+ years of C/C++/Objective C heavy in the embedded when doing C/C++. Java will never fly in the industry I tend to work in and so really do not know it well.

So when going to do some iPhone development, I found the IDE simple, clean and completely worked with me.

At the same time, when I went to do some simple Android work (just for fun), I found the Eclipse based IDE felt like something from the '90's. The Java class organization random and the Java string handling poorly thought out and frustrating to find the functionality I needed. Accessing docs was a RPITA. Working with Eclipse felt like getting a root canal every day. But then, I do not have years of experience working with Java or Eclipse. However, after 3 weeks of use, I can guarantee you that Eclipse will never be my developer tool set of choice. OK, on a project for the past 2 years,Eclipse was the "default" IDE. I gave it a month and then said by-by; so I was not totally new to Eclipse.

Likewise, there were many problems with your understanding of Objective-C IMO (Just as I am not that familiar with Java and I am sure the string classes are fine) for example, int init methods you can:

There are no issues with calling the accessor methods in either the init or the dealloc routines. This all depends, of course, on your design of KVO and such. Likewise, if you have notifications setup in accessors, you need be able to handle nil objects passed to their observers. Personally, I always design this way so using accessors in init and dealloc work to my advantage. I find that overuse of accessors causes substantially less issues than underuse so I use them almost exclusively.

I would have been more concern about the tools you will have to use when you are developing for the iPhone.Android opens you the door for more developing options that you can't even begin to touch with the iPhone Dev Kit.

I've been a developer for 14 years, and currently work as a technical architect and get the opportunity to work with many different platforms and APIs.

Compared to Objective C, Java definitely sets a lower bar for entry. As I cut my teeth on C++ and Pascal, I wouldn't say that is a result of a bias towards Java, just an objective look at what it took to get up and running (productive) with it.

That said, I would not say that the reason Objective C isn't as developer friendly as Java is because of some deficiency. Java does a lot more work for the developer, which generally results in code that performs less consistently, particularly in graphically intensive applications.

As someone who spends a great deal of time in application architecture, I agree with the merits of GC in returning the focus of development to application logic as opposed to logistics, and has non-trivial returns in terms of productivity. But, the reality is that it is also often a license for poorly written applications, as the platform will scramble to fix all of a developer's "mistakes". Apple places this burden on the developer, which is actually the right call for a mobile platform (not necessarily my opinion for desktop or web, though...)

The bottom line is that Apple had created the largest mobile app consumer market on the planet before anyone even knew what an "app" was, so was never any need to coax developers into picking it up. They can keep the bar high which in turn results in an overall higher quality assortment of apps to choose from. Android is playing the role of the underdog, and their philosophy seems to be that in order to quickly produce a large selection of apps, the developer experience needs to be enticing. As another poster commented, this will probably mean that a stink will develop around the Android apps as a result. I've managed teams of outsourced Java developers, and have seen the abandon of best practices, reasonable documentation, and conventions of any sort that are at least enabled by an intelligent IDE, managed code, and high-level languages. Apple seems to go to greater lengths to protect the end user from the middling developer (it kind of aligns with their hardware philosophy).

I do agree with some of the gripes about XCode, though. You can say that it boils down to which platform you have more experience with, but when you look throughout recent history at the most popular IDEs - Visual Studio, Eclipse, CodeGear, etc - while they all have personality differences, XCode out of the box stands out as the complete oddball, and it's not unreasonable for a developer to be turned off by it.

Hi, interesting post. Im a freshman for computer science and really want to start developing some mobile applications. I am a broke college student with a Motorola Droid, so I am going with Android development. Now, I have absolutely no knowledge of any programming languages. I've just coded a few web sites. Does anyone recommend where i should start? I figured a nice, simple application i could develop would be a program that shows the user an overlay of the bus routes on campus and when they click on a bus stop it shows the time the bus is scheduled to come. Any guidance would be greatly appreciated.

Curious thing .... how Smalltalk has directly influenced the flow of certain things.Objective C drew a lot of inspiration and ideas from Smalltalk. On the other hand, Eclipse started it's life as a Smalltalk IDE. To the folks who think GC is bad and memory management is cool because it is fast, what are you smoking? Why don't you go program in assembly language? Your programs will be REALLY fast then, no machine cycles need be wasted. Or perhaps in machine language - 1s and 0s - not a single cycle need be wasted. The problem may be that you live in your own little backwards world and that's all you know. Sort of like primitive people fighting against advancement of technology.As for the argument that mobile devices are not ready for GC, that's what ignorant people said in 80s about computers. The solution is to modify GC architectures for mobile phones

We've been long-time iPhone developers and have had it with Apple. Their approval process and lack of communication with developers has just gotten to be too much. The reject apps over the silliest things. We have five apps in the Top 100 on their charts, and can't wait to drop Apple like a brick and develop in a more open environment.

Thank you for your review, it was fun to read your point of view on this matter. I.don.'.t.really.like.Java() but, for me, programming in Objective-C is even more frustrating (and this is said by someone who still likes to write pieces of code in asm when it's appropiated), and i totally agree that eclipse is much better then XCode (even if it's true that it's a memory Pig with a capital P as someone said).

Let's just hope that the rumors about apple adopting ruby as its next mainstream language is true (even if it's, IMHO, unlikely since the lack of control over it would be unbearable for apple)

Just stumble upon this post from last year. I think many of the opinion against memory management and favor GC is not accurate.

I have worked with C/C++ embedded system for 10 years and most of the work I've done are on systems with executable size of <1MB and data size in the KB. I'm one of those stone age assembly / C / C++ low level driver / firmware guys that didn't "keep up with the advanced technologies".

One of the biggest problem I've seen in mobile and battery powered system is that people write apps without consider the consequences of their works' foot print. You can have GB of RAM and if your app isn't developed correctly, waste all of it.

I agree, that it is tedious having to worry about how much memory I'm consuming and repeating a bunch of set/get/init code for every module, but as a developer, it is my job to keep track of what and how much resource, at least in terms of ball park figure, without exceeding the GC's performance limit.

You think GC is all wonderful and will solve the world's problem? Wait till you realized all of your extra resources provided by GC is consumed by a lazy app developer that can't keep track of how much resource he/she consumed.

By the way, why messages instead of subclasses? I think it is because you can handle multiple cores better with messages and in the low level switches between tasks easier than having to check across each base/derive class to see when is a good time to switch between tasks. I'm no Java developer, but I think it would be easier for the lower level (OS / task scheduler / power management / etc) to know the timing.

This is a phone, and it runs on battery, so it is important to be a bit stingy and know the resource (memory, processing cycle, latency) at each point in time of the app's execution.

Great article! I have recently finished developing a BlackBerry App in Eclipse and am now learning to develop for iPhone so I can port it to there. You have hit all the complaints I have with XCode/ObjectiveC.

I'm looking forward to developing an Android version of my app so I can move back to using Eclipse!

Thanks for the reviews. It was nice to get another perspective. However, I'm fairly biased in the opposite direction. If you haven't used Xcode lately, you're missing out. Im only 17 and I've used Xcode for a couple years now and love it. I'm just now starting to dabble in android, and eclipse is just a whole different animal. I feel like some of xcode's current features allow me to work with all the speed in the world, and I'll find in time how easy android proves to be. But with objective c and c being my first languages I really find them just as easy as you find java, they make sense to me. So I guess after all your work with java it makes sense that android is your thing. But if you haven't tried story boarding in Xcode, you really should!!!