I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nonsense is, well, nonsense. iOS really does need a side loading mechanism. That you need a Mac to develop on is, I suppose, a negative - you can get going with Android on almost anything.
However, I can't say I've ever had any problem with Apple's documentation: It's clear, well written, generally entirely correct. I must confess, I've never spent "weeks devising and performing increasingly peculiar experiments to figure out how to get iOS to do what [I] want", any more than on any platform. If he's complaining that iOS has private APIs then, well, I'm quite sure Android does as well - private just means "not guaranteed to exist in the same form on an upcoming release". If he's claiming that Android's "openness" allows him to see deep inside the OS to make design decisions, rather than relying on the documentation, then I'd suggest that's a mad development strategy (unless one likes rewriting when new OS releases come out).
The point about the simulator seems to be that Android's is so bad, you have to use the phone. I can't really see that as a plus, as one could do exactly the same thing on iPhone, except that iOS has a working simulation environment for when you want it.
The remaining points, about the initial user experience and development environment are entirely subjective, so one can't really comment either way. His point that developing for Android seems to be "easier" than iPhone runs contrary to my experiences, but what one man finds easy, another might find hard.
Garbage collection on OS X appeared in Leopard with Objective-C 2.0—later than iPhone, but before iPhone SDK.
Older models are still around and even iPad has less memory than iPhone 4 so it is not unreasonable to treat it as resource too precious to be left ar the mercy of GC.
On the other hand, manual management is not that complicated and does not add much overhead in programming except the initial phase of getting used to it.
There are some things that are in the private apis that make dealing with certain problems a 100 times easier. Sometimes you just want the gui to force a rotation to a certain orientation at some point of the app. Other public api's such as rotate top bar are more crufty, and don't work 100% of the time, or require fragile workaround where you do all the rotation manually yourself because the public apis are fragile, while the one-line simple private api would of done the trick.
"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."
I just can't let this stand. I have an iPod Touch and an Android, and I struggle a lot with the iPod Touch. Even making the MP3 player (iTunes?) do what I want is a challenge, and that is a native Apple app. I also had a lot of problems with iPad apps when I tried the iPad of a friend. The lack of a back button is a problem if the browser pushes you into some other app (YouTube or Maps), for example.
I could go on and claim that Android usability is so much better than iPhone (which I personally feel it is). But lets just assume that this guy is used to the iPhone and hence can cope with it better than with Android.
Also, if his users struggle with his app on Android, it is probably his fault. What is stopping him from giving it the same interface as the iPhone version? iPhone has one button, Android has 4. So it should be possible to use the same interface on Android, assigning one button to behave like the iPhone button.
Btw, you don't actually have to use Eclipse for Android development. You can do everything with the command line, and hence integrate the development environment (simulator, build script) into any editing environment you want. I am not sure if the same is possible for XCode, but I don't think it is. If XCode does Java, you could probably even use XCode for Android development.
The shoddy state of the simulator really irks me on Android - it's really necessary that it works well, because there are so many different models of phone.
The Android version of my app apparently has a crash-on-startup bug on a single type of Android phone (Droid X), shows up as windowed in others, and works just great on the Nexus/Droid I've tried it on. I can't test on all that physical hardware, though, and the emulator is slow enough that it's nearly useless - various background services on the virtual machine complain about timing out when starting it up.
The fragmentation of that market doesn't seem worth dealing with for the amount of activity on the marketplace.
I actually have a pretty massive patch for QEMU sitting in a computer somewhere (with a pretty massive bug) so I know QEMU pretty well. QEMU is actually very fast if used correctly. Android is not using QEMU correctly. I'm not really sure what they're doing wrong but if I can virtualize a VMM which then virtualizes another OS and the interaction is essentially real-time, basic ARM and Java should not be out of the performance target.
P.S. If you think QEMU is slow, don't even think about Bochs.
The lack of a decent simulator also affects web apps. I downloaded the SDK and installed it in hopes of using it to test mobile versions of sites. It's rather difficult to test when it can take ten minutes to fully load and render a page!
I can second this one thousand times. I developed the blip.tv Android app. It runs well on the Samsung Galaxy S phones, but crashes on startup on _all_ other Android devices. No clue why.
Do you have a debugger attached? I've found that Android's emulator is a bit slow, but not unreasonable; but then attaching Eclipse's debugger slows it down by two extra orders of magnitude, which makes it unusable,
I think it's easier to do simple things on iOS and easier to do complex things on Android. I built a simple iOS app a while ago and was amazed at how easy it was. I didn't customize a thing and kept it all looking exactly how the built in libraries made it look. It was just a matter of throwing some things into interface builder and wiring them up. Then I wanted to do the same thing in Android and was immediately baffled by this crazy HTML-like language that would never work quite right and was horribly verbose.
Now, however, my company is developing an iOS app, and we're following screens given to us by a designer. I think I wouldn't mind that layout language now...
I haven't found Apple's documentation to be significantly worse than Android. Parts of the documentation are sparse at best (the Cocoa layer is great, lower-level stuff less so), but overall both systems have good documentation.
Fully agree about Apple's certificates - it feels like I have to spend an hour or two every few weeks trying to figure out some provisioning profile problem. By now I think I've gone through almost every possible thing that could go wrong with them, so it's a lot faster to fix, but it was incredibly frustrating at first. Apple automated some of that through XCode a few releases back, but that stopped working after a few months and I haven't been able to get it to work again - back to doing everything by hand.
Also fully agree about the Android emulator.
All in all, the two platforms are very close in terms of difficulty - they each have different downsides. I'm a lot more familiar with the iPhone, so Android development goes a bit slower, but I suspect with similar amounts of experience there shouldn't be a significant difference in development time.
An interesting perspective. It really seems like from the programmer's point of view, Android has found a nice sweet spot in productivity - a nice, comfortable, garbage collected but CPU-slow programming environment to do all of your 'OnClick' programming, and then the NDK and C/C++ for when CPU time matters.
iOS puts you in the C/C++/ObjC world for just about everything, unless you want to slog through Javascript. It's been rumoured that Apple is working on a version of MacRuby for iOS - this can't come fast enough.
The feeling you get with XCode is that it slows you down. I'm a java developer by day, iPhone dev by night. Eclipse/Java are _light years_ ahead of XCode/Objective-C. My gripes with XCode include everything from the build process, the awkward debugger, Interface Builder, and all the way down to little minutiae like key bindings that just don't make sense (try selecting a block to indent it, every other IDE in the world uses tab, XCode uses Cmd-] wtf?).
Not to mention Objective-C, which, as you allude to with garbage collection, is a far more inferior language than java. There's things like passing undefined messages to objects which only generate warning at compile time, and sometimes those warnings don't appear in XCode -- so when your code doesn't work, you're left scratching your head. And why isn't the + operator overloaded for string concatenation?
Finally, Objective-C is a very awkward language to use at the keyboard. Object notation [] in particular slows me down a lot - somehow (at least for me) it's easier to type () than it is to type [].
Thanks for the article, now off to download the android SDK!
P.S. I'm not saying Java is a very elegant language - far from it - but, in my opinion, it's more elegant than Obj-C.
But Objective-C is a really nice OO language. It seems you do not get its dynamic nature. Yes, its different, but by no means inferior. And yes, tooling is much better for static languages like Java.
This is pretty much the opposite of my opinions. Android documentation is awful. Mostly it isn't there at all. Many times I found that it was in fact wrong. iOS documentation is really good. Garbage collection on mobile devices means you get UI stutter because GC kicks in when you don't want it which means your app feels less slick. Xcode 4 is pretty good, but yeah Xcode 3… However Eclipse is slow, clunky and buggy.
Also I have found myself doing weeks worth of hacks on Android AND iOS. Both are large frameworks, and ultimately they don't have abstractions for everything you may want to do.
The article reads like the guy hasn't really got his feet wet with Android development yet. He's yet to be bitten by not handling the activity lifecycle correctly for instance. The real edge cases of that didn't start materialising until we had 20,000 beta testers.
I'm stumped why memory management is so hard for developers, to the point I have to raise an eyebrow every time I read it. Are you seriously that lazy?
Instruments makes it exceedingly simple to track down leaks.
While the iPhone 4 could probably handle a GC in most cases, the iPad less capable.
XCode is a personal preference.
I dunno, the time I've spent with Android, and A/B'ing respective apps, Android has almost always "felt" slower. I get that's totally subjective, but that's been my impression. For example, Angry Birds on the Galaxy Tab versus Angry Birds on the iPad are no where near the same experiences. The Galaxy Tab is jerky and slow, while the iPad is smooth.
I still don't get why memory management is so hard for you though.
And don't get me started on those lazy kids and their assemblers. I mean, how hard is it to remember a few dozen opcode hex values?
Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface.
For example, Angry Birds on the Galaxy Tab versus Angry Birds on the iPad are no where near the same experiences. The Galaxy Tab is jerky and slow, while the iPad is smooth.
The Android code for Angry Birds is primarily in native code, so garbage collection is unlikely to be the cause of your observations. And it's perfectly smooth on my Nexus One.
Angry Birds on the Galaxy Tab runs smooth as hell. It runs better than my Angry Birds at my ipod touch..have you actually tried it on the Galaxy Tab recently?
One point that the article doesn't mention is the iPhone Simulator, is a simulator: it simulates the iPhone environment.
Simulators have both good and not so good points.
On the one hand they are pretty fast, since they use "host" code and "host" APIs.
On the other hand, since they use "host" API, you can't rely 100% on them.
For example, the iPhone Simulator simulates the iOS OpenGL ES API using Mac OpenGL API. While developing cocos2d for iPhone I found many differences between the Simulator and the Device.
But in spite of that, I still suggest developing mostly everything on the Simulator, and every now and then to try the app on the device both to test the performance and "reality".
I totally agree with his arguments. Learning Android development has been a breeze with the great documentation and ease of deployment developers. You just have to put up with all the other non-technical aspects of things (fragmentation, uglier UI, etc).
I can't be the only one that hates Android's documentation. It's nothing more than a list of methods and properties. Thanks for nothing, Google, I can use Eclipse's code completion for that. The Android docs have never helped me once. I've always had to rely on web searches when seeking help.
The iOS docs, on the other hand, is rich and full of example code, example usage and programming guides. There's a lot of hand holding, which is great. Android's SDK is definitely simpler and makes more sense than the iOS SDK "out of the box", but I feel like Apple provides enough documentation on important classes like UITableView and UINavigationController.
However, iOS is strongly MVC, so I can understand how a newbie can feel a little lost with all the ViewControllers and various project templates. (Which one do I use? How do I use Navigation Controllers without starting a Navigation Controller project template? Etc...) A "Hello world" example in iOS creates a lot more files than an Android one.
The provisioning in iOS is truly awful. However, in the XCode4 beta this has been greatly improved. You just click on a couple buttons within XCode itself, and everything gets automagically set up.
I've heard that it still causes problems if you're trying to clear out old profiles, but Apple seems to have been trying to provide a good fix to the worst part of iOS development.
I don't think this author can be all that fair. If he had trouble wrapping his head around manual memory management, how far could he have gone in iPhone development?
I have to say that developing on Android after having worked on iPhone is a bit like waking up from a vivid nightmare
Can I plug MonoTouch here then? I just ported a native app to MT. It is approx two seconds slower to load - which I do think is a big deal - but the productivity benefits ( = new features) vastly outweighs that drawback.
Stopped reading after the blatant display of apostrophe usage misunderstanding and unnecessary insertion of recent popular culture reference in the article. That is to say, after the first 3 words.
I was tempted to, as well. But it’s at least a marginally interesting piece, summarizing ups and downs of developing for both platforms. (And I think he used the word “inception” literally.)
[+] [-] archgrove|15 years ago|reply
However, I can't say I've ever had any problem with Apple's documentation: It's clear, well written, generally entirely correct. I must confess, I've never spent "weeks devising and performing increasingly peculiar experiments to figure out how to get iOS to do what [I] want", any more than on any platform. If he's complaining that iOS has private APIs then, well, I'm quite sure Android does as well - private just means "not guaranteed to exist in the same form on an upcoming release". If he's claiming that Android's "openness" allows him to see deep inside the OS to make design decisions, rather than relying on the documentation, then I'd suggest that's a mad development strategy (unless one likes rewriting when new OS releases come out).
The point about the simulator seems to be that Android's is so bad, you have to use the phone. I can't really see that as a plus, as one could do exactly the same thing on iPhone, except that iOS has a working simulation environment for when you want it.
The remaining points, about the initial user experience and development environment are entirely subjective, so one can't really comment either way. His point that developing for Android seems to be "easier" than iPhone runs contrary to my experiences, but what one man finds easy, another might find hard.
[+] [-] rgbrgb|15 years ago|reply
I find Xcode to be at least 80,000 times better than Eclipse (memory usage, UI, interface builder, speed, general bugginess).
I also REALLY like Apple's docs and the ease of integrating C code (no NDK!) when you need to do something like real-time audio.
My only really big complaint is the certificate signing process which can be a real pain.
I mean, I can totally see why Android might feel better or more familiar to a Java programmer though.
[+] [-] rimantas|15 years ago|reply
[+] [-] mickdj|15 years ago|reply
Apple's documentation is great for most visual elements, but CLLocation* in particular has quite flawed documentation.
[+] [-] elai|15 years ago|reply
[+] [-] Tichy|15 years ago|reply
I just can't let this stand. I have an iPod Touch and an Android, and I struggle a lot with the iPod Touch. Even making the MP3 player (iTunes?) do what I want is a challenge, and that is a native Apple app. I also had a lot of problems with iPad apps when I tried the iPad of a friend. The lack of a back button is a problem if the browser pushes you into some other app (YouTube or Maps), for example.
I could go on and claim that Android usability is so much better than iPhone (which I personally feel it is). But lets just assume that this guy is used to the iPhone and hence can cope with it better than with Android.
Also, if his users struggle with his app on Android, it is probably his fault. What is stopping him from giving it the same interface as the iPhone version? iPhone has one button, Android has 4. So it should be possible to use the same interface on Android, assigning one button to behave like the iPhone button.
Btw, you don't actually have to use Eclipse for Android development. You can do everything with the command line, and hence integrate the development environment (simulator, build script) into any editing environment you want. I am not sure if the same is possible for XCode, but I don't think it is. If XCode does Java, you could probably even use XCode for Android development.
[+] [-] mickdj|15 years ago|reply
But Android users don't expect Android apps to behave like iPhone apps - so the affordances don't carry over.
They kept tapping the context menu, or holding down list items: actions which are normal on Android but nonexistent on iOS.
[+] [-] ericd|15 years ago|reply
The Android version of my app apparently has a crash-on-startup bug on a single type of Android phone (Droid X), shows up as windowed in others, and works just great on the Nexus/Droid I've tried it on. I can't test on all that physical hardware, though, and the emulator is slow enough that it's nearly useless - various background services on the virtual machine complain about timing out when starting it up.
The fragmentation of that market doesn't seem worth dealing with for the amount of activity on the marketplace.
[+] [-] Locke1689|15 years ago|reply
P.S. If you think QEMU is slow, don't even think about Bochs.
[+] [-] rbritton|15 years ago|reply
[+] [-] kellysutton|15 years ago|reply
[+] [-] jimrandomh|15 years ago|reply
[+] [-] pkulak|15 years ago|reply
Now, however, my company is developing an iOS app, and we're following screens given to us by a designer. I think I wouldn't mind that layout language now...
[+] [-] alex_c|15 years ago|reply
I haven't found Apple's documentation to be significantly worse than Android. Parts of the documentation are sparse at best (the Cocoa layer is great, lower-level stuff less so), but overall both systems have good documentation.
Fully agree about Apple's certificates - it feels like I have to spend an hour or two every few weeks trying to figure out some provisioning profile problem. By now I think I've gone through almost every possible thing that could go wrong with them, so it's a lot faster to fix, but it was incredibly frustrating at first. Apple automated some of that through XCode a few releases back, but that stopped working after a few months and I haven't been able to get it to work again - back to doing everything by hand.
Also fully agree about the Android emulator.
All in all, the two platforms are very close in terms of difficulty - they each have different downsides. I'm a lot more familiar with the iPhone, so Android development goes a bit slower, but I suspect with similar amounts of experience there shouldn't be a significant difference in development time.
[+] [-] CountSessine|15 years ago|reply
iOS puts you in the C/C++/ObjC world for just about everything, unless you want to slog through Javascript. It's been rumoured that Apple is working on a version of MacRuby for iOS - this can't come fast enough.
[+] [-] mirkules|15 years ago|reply
Not to mention Objective-C, which, as you allude to with garbage collection, is a far more inferior language than java. There's things like passing undefined messages to objects which only generate warning at compile time, and sometimes those warnings don't appear in XCode -- so when your code doesn't work, you're left scratching your head. And why isn't the + operator overloaded for string concatenation?
Finally, Objective-C is a very awkward language to use at the keyboard. Object notation [] in particular slows me down a lot - somehow (at least for me) it's easier to type () than it is to type [].
Thanks for the article, now off to download the android SDK!
P.S. I'm not saying Java is a very elegant language - far from it - but, in my opinion, it's more elegant than Obj-C.
[+] [-] rimantas|15 years ago|reply
Objective-C for me personally is probably the second language by elegance after Ruby.
[+] [-] biafra|15 years ago|reply
But Objective-C is a really nice OO language. It seems you do not get its dynamic nature. Yes, its different, but by no means inferior. And yes, tooling is much better for static languages like Java.
[+] [-] mxcl|15 years ago|reply
Also I have found myself doing weeks worth of hacks on Android AND iOS. Both are large frameworks, and ultimately they don't have abstractions for everything you may want to do.
The article reads like the guy hasn't really got his feet wet with Android development yet. He's yet to be bitten by not handling the activity lifecycle correctly for instance. The real edge cases of that didn't start materialising until we had 20,000 beta testers.
I was interviewed on this topic in fact: http://www.androidpolice.com/2010/11/14/developer-interview-...
[+] [-] jawngee|15 years ago|reply
The docs about it are fairly straight forward:
http://developer.apple.com/library/mac/#documentation/Cocoa/...
Instruments makes it exceedingly simple to track down leaks.
While the iPhone 4 could probably handle a GC in most cases, the iPad less capable.
XCode is a personal preference.
I dunno, the time I've spent with Android, and A/B'ing respective apps, Android has almost always "felt" slower. I get that's totally subjective, but that's been my impression. For example, Angry Birds on the Galaxy Tab versus Angry Birds on the iPad are no where near the same experiences. The Galaxy Tab is jerky and slow, while the iPad is smooth.
I still don't get why memory management is so hard for you though.
[+] [-] orangecat|15 years ago|reply
Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface.
For example, Angry Birds on the Galaxy Tab versus Angry Birds on the iPad are no where near the same experiences. The Galaxy Tab is jerky and slow, while the iPad is smooth.
The Android code for Angry Birds is primarily in native code, so garbage collection is unlikely to be the cause of your observations. And it's perfectly smooth on my Nexus One.
[+] [-] tomh-|15 years ago|reply
[+] [-] abstractbill|15 years ago|reply
I wrote most of the original justin.tv iPhone broadcaster app, and the above is very very true for me. Never again, hopefully.
[+] [-] rquesada|15 years ago|reply
Simulators have both good and not so good points. On the one hand they are pretty fast, since they use "host" code and "host" APIs. On the other hand, since they use "host" API, you can't rely 100% on them.
For example, the iPhone Simulator simulates the iOS OpenGL ES API using Mac OpenGL API. While developing cocos2d for iPhone I found many differences between the Simulator and the Device. But in spite of that, I still suggest developing mostly everything on the Simulator, and every now and then to try the app on the device both to test the performance and "reality".
[+] [-] makeramen|15 years ago|reply
[+] [-] jinushaun|15 years ago|reply
The iOS docs, on the other hand, is rich and full of example code, example usage and programming guides. There's a lot of hand holding, which is great. Android's SDK is definitely simpler and makes more sense than the iOS SDK "out of the box", but I feel like Apple provides enough documentation on important classes like UITableView and UINavigationController.
However, iOS is strongly MVC, so I can understand how a newbie can feel a little lost with all the ViewControllers and various project templates. (Which one do I use? How do I use Navigation Controllers without starting a Navigation Controller project template? Etc...) A "Hello world" example in iOS creates a lot more files than an Android one.
[+] [-] BenoitEssiambre|15 years ago|reply
[+] [-] maxawaytoolong|15 years ago|reply
I've heard that it still causes problems if you're trying to clear out old profiles, but Apple seems to have been trying to provide a good fix to the worst part of iOS development.
[+] [-] lawfulfalafel|15 years ago|reply
[+] [-] rmc|15 years ago|reply
[+] [-] binaryfinery|15 years ago|reply
Can I plug MonoTouch here then? I just ported a native app to MT. It is approx two seconds slower to load - which I do think is a big deal - but the productivity benefits ( = new features) vastly outweighs that drawback.
[+] [-] whatever_dude|15 years ago|reply
[+] [-] alanh|15 years ago|reply