
An iOS Developer Takes on Android - nfarina
http://nfarina.com/post/8239634061/ios-to-android
======
ThomPete
What a wonderful approach to development.

Skip the ideological critiquing and start shipping some awesome products..

I guess that is really what separates the great developer from the good
developer.

~~~
gmac
Agreed, the attitude is refreshing. Nice quote:

 _Java is a high level programming language. It’s unproductive to have an
opinion about it._

~~~
tomjen3
Depends -- with that attitude we would still have assembler.

~~~
to3m
That's a fair point, but if your goal is to create something that people will
pay for, targeting a popular platform with an infrastructure based around
Java, what will having an opinion about Java buy you? Very little. You can
like it, or you can not like it, but you'll have to use it anyway, so your
time would be better spent thinking about something other than how much you
like it or (as is probably more likely...) not.

~~~
Volpe
I don't think that's true.

\- Python \- Ruby \- Ruby on Rails \- Django \- Coffeescript \- Node.js

Were all results of people challenging the status quo of language/platform
capability. Developing new languages/frameworks/platforms is NOT unproductive,
and has proved very successful in the past.

While java may not be a good excuse to avoid android, it's certainly a good
excuse to improve upon the stack (as another commenter suggested, strapping
Scala to it would probably be a huge productivity win).

Alas the OP took a pragmatic approach and just built the product. That's fine,
but it isn't "better" than someone who (rightly) thinks java is junk and
attempts to improve it.

~~~
ThomPete
I think you and several others are missing the point here.

Most people who complain about a language don't do anything about it.

It was those I addressed, not those who do.

~~~
Volpe
While a fair point, I think expressing your dissatisfaction will let others
know there is a market for a better solution. And potentially drive more
innovation

... but that could be me post-hoc rationalising my whinging :D

------
flyosity
As an iOS developer, this is probably the best comparison between iOS and
Android development that I've read. I'm pretty scared of Eclipse and the slow-
as-hell emulator doesn't sound fun, but coding layouts that don't involve lots
of "how tall is this text for this given width?" calculations is a welcome
addition.

~~~
qeorge
I jumped into Android development about a month ago, and after a slow start
its really been fun. I hated Eclipse at first, but it gets a lot better with
time.

The emulator though - don't bother. The author is not exaggerating about
several minutes to load. Just buy an Android phone and debug on that, or
you'll spend more time cursing at the emulator than coding.

~~~
FaceKicker
I've found that booting the emulator does take a minute or two (I don't know
about "several", but that's besides the point), but you don't have to restart
every time you make a change or anything. It's just a once-per-session thing
unless you accidentally close it.

~~~
gary4gar
Still, you will have to wait for around 30s for each refresh; While the new
binary gets uploaded

~~~
FaceKicker
My experience has been that it takes much less time than that, probably
somewhere in the area of 5-15 seconds. I've only worked on tiny personal
projects though; maybe this varies with project size a lot.

~~~
yardie
To me it still doesn't matter. It could take one second to load a binary, the
emulator is completely unusable they way it currently is built. Android is
already into it's 3rd revision and they somehow have managed to completely
ignore this pink elephant.

If the best advice you can tell people is not to use it, use a real device
then why bother include it at all.

------
S_A_P
This article was damn near perfect. I much prefer this style to "the problem
with X" or "Why X will never succeed". This person isn't interested in
platform evangelism, he/she wants to ship. A very inspiring attitude to have.

------
podperson
Seems like a very balanced article to me. The comments about Eclipse made me
laugh (I just had to start using Eclipse for a different reason and hate it
with the heat of a thousand suns).

~~~
simmons
Using Eclipse gets better as you get more comfortable with its peculiarities.
I think the author did a good job of summing up the Eclipse experience--
there's a lot to hate, and a lot to like. After using Eclipse for several
years, it still has that "designed by committee" feel, but I do find myself
missing some of its features when I'm using other environments.

~~~
Cyranix
I've actually been using the PHP... perspective?... for Eclipse and have found
it to be pretty decent. (The author is right, some of the terminology is
amusingly abstract.) Configuring the program just-so and learning to accept
the slow boot-up are spot-on assessments.

That said, I should take some time to look for another IDE that captures the
basic advantages of Eclipse. I'm mainly interested in having a panel with the
project's directory structure, intelligent navigation (e.g. Ctrl-click on a
function call to be taken to its definition in another class), and decent code
completion and syntax checking. I might even be willing to pay for it.

------
ZoFreX
A couple of points...

> Android has a system of layout containers (similar to HTML)

It would be more correct (I think) to say it's inspired by other Java layout
managers, Swing and SWT aren't a million worlds removed from Android (but I
can't really expect someone new to Java to know that!)

And the emulator. The Android emulator is not slow. I have a netbook, which is
an absolutely fantastic way of finding out which applications do far too much
but you never notice because your computer is very fast. Team Fortress 2 is
slow. Eclipse is slow. I tried booting the Android emulator and gave up
waiting _after an hour and a half_.

Overall, awesome article. Refreshing to see someone providing a useful
comparison between the two rather than arguing over one or the other, and as a
Java developer who knows a little about Android, I feel I just learnt a lot
about iOS. I'm actually amazed at how much they have in common, you wouldn't
think so from the arguments!

------
eevilspock
Eclipse is to IntelliJ as Android is to iPhone.

Anyone who's used both IntelliJ and Eclipse as IDEs for Java development knows
what I'm talking about. Eclipse, like Android, emphasizes "openness" and
customizability while IntelliJ, like the iPhone, emphasizes "It Just Works"
coherence and integrity.

If you like IntelliJ's approach, you might want to try AppCode, a development
environment for Objective C made by the makers of IntelliJ, JetBrains.
<http://www.jetbrains.com/objc/>

~~~
div
I've used IntelliJ for previous projects, but I am definitely going to give
Eclipse a spin for the next one.

The Visual Layout Editor seems like too much goodness to miss out on. Jump to
7:17 in this video for a demo: <http://www.youtube.com/watch?v=Oq05KqjXTvs>

------
znq
Totally agree with the other comments. This is the first honest and realistic
writeup about "Android vs iOS development" I've read.

I started with Android myself and started porting an Android app (which I
wrote) to iPhone and I had exactly the same problems iOS developers have when
starting with Android. So it's just a matter of what you're used, too. From my
experience some things can be done quicker on iOS, others on Android. However,
that doesn't necessarily mean better, because providing a framework for a
special case usually comes with the cost of restricted flexibility.

I also agree that Eclipse is a behemoth and quite overwhelming in the
beginning, but there is a great tool for any code base that is larger than
your typical pet project. Especially when having to read, understand and trace
down other people's code.

------
bignoggins
iOS developer here. Releasing first android version of my app this week. Even
though I didn't do the coding, I've taken a look at the code and done quite a
bit of testing. The part about animations is totally true. Animations are much
faster and smoother on my iPod 3rd Gen than the equivalent animation on a
Droid Incredible, which has much better hardware! We've tried to optimize as
much as possible, but we are realizing that there is just no way to match the
iOS version's speed and responsiveness.

------
wallflower
Good overview and I recommend this detailed dive into the deep end by a HNer:

[http://clayallsopp.posterous.com/building-an-android-app-
fro...](http://clayallsopp.posterous.com/building-an-android-app-from-scratch-
or-this)

------
hahainternet
The biggest complaint seems to be that Android is software rendered. As of 3.1
(i think, maybe 3.0) this is no longer an issue as a single line in the
manifest will cause Android to automatically accelerate your drawing if
possible.

I've yet to actually try it though :)

~~~
nutjob123
It works pretty well in all the cases i've used it. Its the only way that i
have been able to get the new animation class to work smoothly.

~~~
babebridou
It works pretty well... except for software input method (the other name for
the touch keyboard).

A simple example: make a webview that scrolls down and ends with a textfield a
couple screens below. Activate Hardware acceleration, scroll, touch the
textfield, boom, the textfield remains below the keyboard so you don't see
what you type. Deactivate hardware acceleration. Do the same test. Boom, the
screen pans up and the textfield is visible.

Once you've done this on a xoom, try it on an iconia or whatever other tablet
you have.

Enjoy the fun of Honeycomb hardware acceleration.

------
Yhippa
What a great comparison. Admittedly I haven't researched this but I was
surprised to read that the UI components in iOS were based on OpenGL. That's
pretty cool! Hats off to Android for their layout manager. I like when I use
an app on Honeycomb that scales well as opposed to blowing up the pixels to
fill the screen.

------
chriseidhof
This is really good stuff. As an iOS developer, this is exactly what I hoped
to read someday soon. I'm impressed, great writeup and quite thorough.

------
rimantas
Question to Android devs with iOS experience: are there any tools available
which would be counterpart for Instruments? Instruments do not get mentioned
in these comparisons for some reason, I think these are great tools to debug
and improve performance.

~~~
wallflower
Traceview but you run out of stack frame capture space in about 30 seconds
(even if you write to SD)

Instruments has no competition from traceview.

[http://android-developers.blogspot.com/2010/10/traceview-
war...](http://android-developers.blogspot.com/2010/10/traceview-war-
story.html?m=1)

------
al_james
Interestingly (but inevitably) as a java developer who first learned Android
and then moved to iOS, the sticking points he mentions are exactly the same
ones I found, but the other way around.

I think Eclipse makes sense if you think like a java coder, Xcode not so much,
and Objective-C will fry your mind...

That said, Eclipse and the Android SDK is a pain to install even if you are a
java wizard.

~~~
rimantas
Why would ObjC fry anybodie's mind? I am that weird to like it (coming from
web dev background: PHP, Ruby, JavaSript)?

~~~
KirinDave
ObjC's main "frying" factor is that it uses a different (and to my mind,
superior) set of object-oriented patterns as primary abstractions. For
example, subclassing is _much_ less common in ObjC than in Java, preferring to
use the less complex delegation pattern as opposed to subclass-and-implement
patterns for behavior extensions.

Another problem some people have is that ObjC brings to the table all the pain
of C. You've got memory management and bounds checking and unsafe casts all
dumped into your lap. It can be pretty painful if you're not experienced in C,
C++, or ASM programming.

------
raminf
Nice overview. I have to disagree with the assessment of Eclipse though. Under
one app you can build and debug Java, Python, Ruby, HTML, Javascript, and Air
apps. Once you get used to the workflow, it's incredibly productive.

As for the emulator, unless you want to invest in a large set of devices, it's
the only way to test against different screen sizes and device profiles. Even
though it's nice to have a device for debugging, you'll need to make peace
with the emulator to make sure your app doesn't go all wonky on devices other
than your exact model.

------
juliano_q
Thanks for this article it just made me feel happy. I so tired of flame wars
regarding IOS x Android that I barely read Engadget anymore. Many people dont
understand why I have a Macbook, an Android phone and an iPod, looks like you
MUST took a side and be an evangelist.

------
pgr0ss
Fastdev makes the Android Emulator usable:
[http://developer.appcelerator.com/blog/2011/05/titanium-
mobi...](http://developer.appcelerator.com/blog/2011/05/titanium-mobile-intro-
series-fastdev-for-android.html)

After you suffer the initial emulator load, changes appear in the app by
simply bouncing the app. It's one big win for Titanium.

------
pwelch
"It takes the Android Emulator ~2 minutes to boot up on my perfectly-modern
machine. But what really hurts is the edit/debug cycle. Every time I change a
bit of Java and need to rerun the app, it takes about 30 seconds to redeploy
and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator.
It may not sound like much but remember you’ll be doing this hundreds of times
throughout your day."

I do not have any experience with iOS development but I can vouch for how hard
it is to use the Android Emulator. I just recently submitted an Android
application for a programming course and if it were not for having an Android
mobile device to replace the emulator I would not have completed the project
in time. The Emulator is slow and buggy and made it hard to test new code.

If you are interested in developing an Android application deffinately check
it out but take this guys advice and get a device to test it on. It will save
you a lot of time.

~~~
jamesbritt
_Every time I change a bit of Java and need to rerun the app, it takes about
30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds
on the iOS Simulator. It may not sound like much but remember you’ll be doing
this hundreds of times throughout your day."_

Is there no practical way to reduce this by using unit tests? I understand if
you're doing UI tweaks but otherwise it seems far more efficient to do
targeted testing.

------
jbuzbee
Nice well-written article. I just did the same sort of article myself telling
about my experiences going from IOS to Android:

[http://www.smallcloudbuilder.com/apps/articles/410-crossing-...](http://www.smallcloudbuilder.com/apps/articles/410-crossing-
the-chasm-converting-an-iphone-app-to-android)

------
scottjad
> Apple has made it pretty easy to start writing iOS apps. Of course, Step One
> is “Buy a Mac.” Easy! Then just download the free Xcode Installer from the
> Mac App Store, and start writing code when it’s done.

> Android is a bit more involved. You can download the SDK easily, but to
> actually start writing code, you’ll want to setup Eclipse and install
> Google’s ADT Plugin.

Buying and setting up a new computer is "Easy!" but installing Eclipse is
"more involved"? Having to sign up for a $99 developer program is omitted. The
size difference, of a couple hundred mb for Eclipse vs 4gb for Xcode is
omitted.

~~~
nfarina
My sarcasm may have been too subtle there; I definitely think it's a bummer
that you have to own a Mac to develop for iOS.

------
alain94040
Best explanation of why rendering on the iPhone uses the GPU and Android
can't. A great article to read.

------
euroclydon
Didn't Apple just release Auto Layouts for Cocoa? Will Auto Layouts come to
iPhone?

<http://news.ycombinator.com/item?id=2788608>

------
marcomonteiro
I hate to be picky about this but in all the time I've been doing iOS
development and throughout everything I've ever read I have never seen
anything to suggest that iOS using OpenGL for all of it's drawing (simulating
a 2D interface in a 3D environment like the article suggests). Drawing is done
using the Quartz system and animation is handled by Core Animation (which
creates "an illusion of motion").

~~~
nfarina
The OpenGL-nature of iOS was explained to me at WWDC by the head of graphics
at Apple. But you can never be sure of anything!

~~~
marcomonteiro
Interesting.

------
reidmain
Why do you "have to kiss that silky smooth scrolling goodbye" if you setup
your UITableViewCells in Interface Builder?

I've used it for all of my apps and the scrolling is just as fast as any of
Apple's native apps. Interface Builder just packages up all that initial
layout code and then it is executed when the nib when it is unpackaged. After
that there is no difference.

~~~
clawoo
Actually there is a difference. If you create a table with a considerable
number of cells (say, over 20) that contain a couple of labels and maybe an
image when you swipe really fast the scrolling will hang, even if you are
using the dequeue mechanism.

The alternative is to paint the contents of the cell manually (that is without
using UILabels and the such) using CoreGraphics.

Check out the drawContentView: method here: [https://github.com/ferostar/fast-
scrolling/blob/master/Class...](https://github.com/ferostar/fast-
scrolling/blob/master/Classes/FirstLastExampleTableViewCell.m)

~~~
reidmain
If you had twenty different UITableViewCells in a nib that had twenty
different pictures then I admit the loading of these cells will cause the
scrolling to stutter if you do it in cellForRowAtIndexPath:.

However I just finished an application with a UITableViewCell, defined in a
nib, that had 3 labels and a image. The labels depend on the data that the row
was displaying and the image was the same in every row (it was a custom
disclosure image).

One of the table views that that used this cell had 100 rows and it loaded and
scrolled without a hitch.

Most of the slowdowns people experience with scrolling is if they have
transparent cells and/or they don't load lazy load images on a background
thread.

I agree that if you've tried all sorts of optimizations and you are still
experiencing slow scrolling then painting the contents manually will probably
be faster but it is IMO more work then 99% of people need to do and, like naz
said below, there can be accessibility issues.

When Loren Brichter wrote that 3 years ago it was a much bigger deal. The
iPhone 3G was extremely underpowered compared to most of the devices people
run iOS on today.

------
bad_user
If you're starting Android development, just save yourself the pain and just
use the IntelliJ IDEA community edition.

The Android plugin included doesn't have fancy UI stuff, like for designing
interfaces or visually editing the XML configuration files, but it does have
code-completion of XML tags and properties and it works better as a code
editor, being less painful.

~~~
zmalltalker
I've tried doing that, but whenever I'm actually doing work on Android app a
really large percentage of my time spent is done working on the UI. Not having
the ADT tools for the UI just doesn't make sense to me.

------
rheide
Wow. I never expected that much negativity for the Android side. I've dabbled
in both but haven't done Android since over a year ago. I was (and still am)
really looking forward to using Eclipse and reading Java. I just get very
tired of XCode.

------
mooneater
Clicking their site <http://www.meridianapps.com/> leads to "App Engine Error:
Over Quota. This Google App Engine application is temporarily over its serving
quota. Please try again later"

Ouch!

~~~
nfarina
Just increased the quota. Humbling.

------
dmix
This was great.

Im curious, where you experienced in Java before jumping into Android?

~~~
nfarina
I "learned" Java in college, but didn't use it after graduating in '02. I was
quite pleasantly surprised by all the (new to me) stuff like "anonymous inner
classes," and ultimately I've come to respect the staunch minimalism of the
language overall.

~~~
rsynnott
If you were finishing college in 02, the anonymous inner classes should have
been there; I'm pretty sure they showed up in Java 1.1 at the latest. AWT used
to be heavily dependent on them.

------
oflannabhra
Great write-up. I read the whole thing and bookmarked it as well for future
reference. Thanks for sharing.

Which resources (online or otherwise) did you find most helpful?

~~~
nfarina
I thought the Android docs were quite good for the most part, but I usually
just Google my questions and end up on StackOverflow. I'd love to give
StackOverflow a great big hug someday.

~~~
nextparadigms
Have you tried the forum at <http://www.anddev.org> ? They have a lot of code
snippets there for example.

------
mricardo
I installed the Android SDK easily. I do not understand all the fuss regarding
the SDK installation. The emulator is slow though, no question there.

------
rudy750
Slow Clap for you sir...

------
smcj
This is a great and honest article and has changed the way I think about Apple
users/developers.

Before that, I considered Apple users to be a group of gay douchebags, but
today I have learned that there is at least a sane person on the other
riverside.

(I have neither developed for any smartphone nor do I possess one, so no need
for "Stupid FANDROID!1!")

~~~
camtarn
Us gays also use Android, y'know ;)

~~~
smcj
Yes, sure. There is much less discrimination against "other" people on non-
Apple platforms and that's great!

------
xcode
Few Comments.

1\. The most important thing to think about and say is the market share,
fragmentation, monetization issues. Article doesn't pay enough attention to
this it, but it still drives why we do what we do. (save, the author was egged
on to make the app by their users).

A paragraph would be useful. Perhaps something like.

Fundamentally, Android is the platform you have to be on to defend the turf.
It generally wont make a lot of money, but you have to be there to protect &
project mind share. Additionally, it is the dominant mobile platform.

2\. Development Tools. You can use IntelliJ Idea. Its a Mature Development
Platform, and gives you many options. The article doesn't make any strong
arguments against eclipse. The installation/getting started was more involved,
but personally, it took me an hour or so, so I don't think it is a big deal.
It is useful to separate opinions from facts. Personally, I use emacs bindings
in all my editors, and Eclipse is pretty nice to me in general.

3\. UI Design Tools This section is written in a way that projects inaccurate
information. It implies that you have to use XML as opposed to using a
Interface Builder interface. This is not true - there is indeed a drag and
drop interface akin to IB in android. The author mentions it as a preview
tool. Indeed it is also a design tool.

~~~
MatthewPhillips
It wasn't an advocacy piece, it was a developer's experience in changing
environments, and giving some pointers on what to do differently in Android
than what one is used to in iOS. The point is not to convince you to develop
for Android. The point is to help someone make the switch quickly (such as
using Eclipse rather than some other method that hardly anyone uses which will
cause you to spend hours getting things set up and a lot of pain following a
how-to that is written with the assumption that you're using Eclipse because,
you know, almost everyone who developers for Android does).

