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.
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.
How the hell do you get xcode (or other programs, but xcode is particularly bad) not to end up being a big piles of small windows you can't access effectively because they don't have a dock icon? The only way I found, was to long-click on the xcode dock icon which after a while splatters small versions of the windows everywhere, then scan these tiled windows until I find the right one and click on it. I have to do that atrociously long multi-step process every damn time I wan't to take a glance at another window! This, for example, makes the internal iOS documentation useless to me. At least I can use the web documentation to get the browser dock icon but when I don't have an internet connection I'm out of luck.
While I'm at it, is there any way, when using 'Spaces' to do a desktop change in one click? I'm mainly a Linux user and I'm used to having multiple desktops. OSX also has this functionality, and the 'Spaces' icon actually has four little square on it that represents the four desktops it's controlling. However when I click on one of the small squares, instead of going to the right desktop like it does in Gnome/Linux (and has been doing right since about 1995), it goes into an animation where the four desktop are displayed tiled full screen and I have to pick one. That is a two step process with an animation in between for something that should clearly be instantaneous. Is there an alternative to this. Both these things are driving me insane!
Like in the article, I bought a mac just to do iOS development and up to now my experience on osx felt like using a broken out of date gnome desktop with serious usability issues.
I had to learn Java specifically for this project. Python is my preferred hammer for most nails, but not an option on mobile. I've also been a professional C programmer before, wreaking havoc in the kernel. I've got opinions on Objective-C, but that's a subject that deserves a whole separate post.
And manual memory management is not a showstopper, but to say it's "not that complicated and does not add much overhead" is just wrong. It's conceptually simple, but the devil is in the details. I would bet that if you took a poll of all Cocoa programmers who have been working in the field since — well, pick any date you think qualifies as "out of the initial phase" — and ask them how many of their programs have done correct memory management without debugging, you will get an answer of 0.
Apple's documentation is great for most visual elements, but CLLocation* in particular has quite flawed documentation.
The documentation is all here and the API is about straight forward as it is going to get. http://developer.apple.com/library/ios/#documentation/CoreLo...
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.
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.
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.
P.S. If you think QEMU is slow, don't even think about Bochs.
You could well be right that they're not using it correctly -- that sounds entirely plausible. I guess my point was more that, whatever the cause, the net effect of it is that the Apple Simulator is unrealistically fast, and the Android Emulator is unrealistically slow. Neither really encourage great development if you rely on them.
If you are running guest code that matches your host architecture, QEMU can run the code natively. If you are running foreign code (e.g., ARM on an Intel host), it has to dynamically recompile the code, which will hurt performance.
kb
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.
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.
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.
every other IDE in the world uses tab, XCode uses Cmd-]
wtf?
Objective-C for me personally is probably the second language by elegance after Ruby.
From your example, it's apparent that Mac-only editors use cmd-[. This is a great idea as it promotes cross-platform compatibility and makes life so much easier for developers. /snark
Likewise, I have a problem with Visual Studio and Eclipse, and their debuggers: F6 is step-over in Eclipse, and F11 is step-over in Visual Studio.
By the way, try using the Visual Studio debugger in a virtual machine on OS X. Another example of an awesome key-binding in OS X (who uses F11 anyway? Let's assign it to something system-wide!)
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.
Even if XCode were consistent, suppose you are working with some frameworks (like OpenFeint) which, when compiled in your code, have a couple of warnings here and there. How do you tell your warnings from theirs?
More importantly, calling a method (or passing a message) with an incorrect signature should absolutely be a compile-time error.
I'm not trying to be facetious here, I really do run into these problems. I'm genuinely asking why Objective-C and XCode should be considered on equal footing as some other languages?
(P.S. I'm really fired about XCode and Obj-C because I work with it almost daily and these things bother me to no end, so hopefully you're not interpreting my passion for wanting to improve these tools as smugness or arrogance directed at you)
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-...
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.
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.
First of all, he offers no evidence that memory management in objective-c is resource or effort intensive. He can't, because it's not. This is not hard:
-(id)initWithSomeNumber:(NSNumber *)aNumber {
...
someField=[[SomeObject alloc] init];
someOtherField=[aNumber copy]; // or retain, your call.
...
}
-(void)dealloc {
[someField release];
[someOtherField release];
[super dealloc];
}
* If you use a convenience method, eg [NSString stringWithFormat:...] you don't own it, so don't release it.
* If you use alloc, copy or new, you own it, so release it.
* Implement dealloc to release fields you own.
* Never invoke dealloc directly.
I mean you can be as snarky as you want dude, I write Cocoa apps all day long (as well as web apps and mobile apps) and I can tell you and the original poster, are either idiots or lazy. I'm going to go with lazy.
For reference, I'm a five year Java dev who has now been doing iOS dev for two years, and had no problem switching from GC to manual memory management.
The point of my criticism is that memory management in objective-c doesn't take any extra time beyond overloading dealloc and writing a few more retains and releases for 90% of all cases. It's just plain lazy, imo. Your comparison to writing raw assembler is nonsense and ignorant.
I wrote most of the original justin.tv iPhone broadcaster app, and the above is very very true for me. Never again, hopefully.
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".
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.
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.
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.
Thanks for your comments, and the typo in that first sentence was pretty bad. Sorry about that. I've ceded the grammatical highground for the foreseeable future with that gaffe.