

Android vs iOS: A Developer's Perspective - jamesg
http://whereoscope.wordpress.com/2010/12/07/android-vs-ios-a-developers-perspective/

======
archgrove
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.

~~~
rgbrgb
Agreed. I had the exact opposite reaction when I started doing some Android
dev after coming from iPhone.

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.

~~~
BenoitEssiambre
I have a question. I asked this to a few mac users and haven't received a good
answer.

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.

~~~
metachor
To use XCode in a single window, switch it to the All-in-One layout in the
preferences:

[http://iphonedevelopment.blogspot.com/2009/03/xcode-
single-w...](http://iphonedevelopment.blogspot.com/2009/03/xcode-single-
window-mode.html)

Also, in any OS X application with multiple windows you can use Command-`
(i.e. Command + backtick key) to switch between windows of the active
application.

~~~
BenoitEssiambre
All-in-One is kinda nice. It seems it should be the default. It still doesn't
make the documentation window of any use though. I guess it has a little less
chance of being hidden under a pile of other windows now. Command+backtick
doesn't seem to do anything on my mac.

~~~
losvedir
Strange that Cmd-backtick doesn't work for you. Try this: Open up System
Preferences, select "Keyboard", change to the "Keyboard Shortcuts" tab, and
highlight "Keyboard & Text Input" on the left. Is the "Move focus to next
window in application" box checked? What's its shortcut?

Also, long-clicking on the dock icon just activates Expose for Application
Windows. I have it set-up to activate upon mousing to the top right corner and
really like it. You don't have to wait for the delay of clicking and holding
on the dock, though you'll still have to scan for the correct window.

------
Tichy
"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.

~~~
mickdj
Actually we started off with that - having the same interface for both Android
and iOS.

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
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.

~~~
Locke1689
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.

~~~
jamesg
QEMU is a truly awesome piece of code. Everything Fabrice Bellard does is
incredible.

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.

~~~
Locke1689
Agreed -- I just wanted to defend QEMU (and my own work, by extension) for a
moment.

Also, code can always be made to go slower so I'm not sure if "unrealistically
fast" is as bad a "unrealistically slow."

------
pkulak
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...

------
alex_c
I found that matches my experience fairly well.

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
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.

------
mirkules
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.

~~~
rimantas

      every other IDE in the world uses tab, XCode uses Cmd-]
      wtf?
    

Textmate uses ⌘[, skEdit uses ⌘[, CSSEdit uses ⌘[, Coda uses ⌘[, BBEdit uses
⌘[.

Objective-C for me personally is probably the second language by elegance
after Ruby.

~~~
mirkules
Sure, but as counter-examples, take Eclipse, Visual Studio, Netbeans,
Notepad++, Textpad, XMLSpy...

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!)

------
mxcl
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 was interviewed on this topic in fact:
[http://www.androidpolice.com/2010/11/14/developer-
interview-...](http://www.androidpolice.com/2010/11/14/developer-interview-
series-tweetdeck-for-androids-max-howell/)

------
jawngee
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?

The docs about it are fairly straight forward:

[http://developer.apple.com/library/mac/#documentation/Cocoa/...](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/TP40004447-SW1)

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
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.

~~~
jawngee
How is the most ignorant comment in this thread voted up?

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];
        }
    

How is that hard exactly? There are only 4 rules you need to follow for memory
management in Objective-C/Cocoa/CocoaTouch:

* 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.

~~~
varikin
Memory management is Obj-C has issues. The documentation is spotty at
explaining how to property handle it, or maybe it is an issue with the
organization of the documentation cause I can't always find what I need, but I
know it is there. When I started, I keep hearing the general rule of thumb,
"if you don't alloc/init it, you don't need to release it." Except no one
mentioned you have release properties. I never alloc/init them. Along with
that, difference between an ivar and property is poorly documented. The fact
that "aField = x" is different than "self.aField = x" and can mess up memory
management was lost on me.

My problem with the documentation, as I said before is mostly organization.
Along with that, some of these concepts are defined in ways that only make
sense if you already know the language and framework.

After a couple projects and code reviews, I think I understand it now. It is
not that we are lazy for not understanding or liking it; it is that it isn't
intuitive or simple like GC.

~~~
HectorRamos
If your property is defined as retain in your header, you are claiming
ownership for it and so it needs to be released in your dealloc method.

This is covered in the basic Memory Management doc
[http://developer.apple.com/library/mac/#documentation/Cocoa/...](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW11)

------
abstractbill
_I have to say that developing on Android after having worked on iPhone is a
bit like waking up from a vivid nightmare_

I wrote most of the original justin.tv iPhone broadcaster app, and the above
is very _very_ true for me. Never again, hopefully.

------
rquesada
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".

------
makeramen
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).

~~~
jinushaun
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.

------
BenoitEssiambre
I also did an app on both OSs and this article matches my experience exactly.

------
maxawaytoolong
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.

------
lawfulfalafel
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?

------
rmc
Sounds like Google are trying the "Developers Developers Developers" stragegy
from Microsoft.

------
binaryfinery
_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.

------
whatever_dude
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.

~~~
alanh
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.)

~~~
jamesg
The inception link was just a bit of fun :)

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.

