

IOS vs. Android from the Trenches - jmintz
http://devblog.bu.mp/ios-vs-android-from-the-trenches

======
vlucas
I use an Android every day, and my wife has an iPhone. The absolute biggest
thing that annoyed me about using the iPhone after being used to the Android
is the lack of a dedicated hardware back button. The problem you describe
about an app opening the browser and then trying to get back to the app on the
same screen you left it is so irritating in iOS - It's a huge glaring issue
that is seamless on Android.

~~~
ikono
This is a deeper philosophical issue. With Android you have to remember your
usage history to know what the back button is going to do. In iOS you're never
going to accidentally switch to a different app. Once you get used to one
philosophy the other will become annoying.

~~~
GeneralMaximus
Disclaimer: I'm a long-time Mac user and developer, but these days I mostly
write iOS apps. I'm that annoying guy who mutters Cocoa method names in his
dreams. I own a HTC Desire, but I've never written an Android application. Not
yet, anyway ;)

Android applications are structured like web pages, even when you look at them
from a developer's perspective. Besides other things, each app consists of a
number of _activities_. An activity is the UI you see on the screen, and
there's a separate activity for each piece of UI you see in an app. For
example, your Twitter app might consist of an activity for the timeline,
another one for sending a new tweet, another one for setting preferences, etc.
It helps to think of an activity as a web page and an app as a website
consisting of a number of web pages.

When you're in AppX and want to open a document/URL in AppY, you send AppY an
_intent_ , which is a fancy word for _message_. Android then replaces the
current activity from AppX with a new activity from AppY. But that's not all.
You can directly send an intent to an activity in AppY, or you can send an
intent to AppY and let it decide which activity to use for handling it. You
can even just _broadcast_ the intent and let Android decide what to do with
it.

So, in reality, you're not using "apps" at all. Instead, you're using a
hyperlinked collection of activities, each of which just happens to belong to
a collection of activities called an app. When you look at it this way, it's
just natural that Android has a home button and a back button. Both those
buttons work in natural, predictable ways. If I open an unread text message
from my home screen and then hit the back button, I'm back at the home screen.
If I open my inbox in the messaging app, navigate to the unread text message
and hit back, I'm back at my inbox. What could be more natural?

(Also, IMO, the Android API and developer tools make Cocoa and Xcode look like
toys. It's like comparing DirectX with BGI.)

Talking of usability: in my experience, Android is far more usable than iOS.
It might not be pretty, but it manages to get nearly everything right UI-wise.
Less buttons on the phone != better usability. What if your laptop had only
the 26 letters and every other function was bound to a double-tap or press-
and-hold action? Double tap Q for F1, press and hold M for backspace?

~~~
yardie
As an iPhone, Android, and WebOS user hands down WebOS has the best navigation
implementation of all of them. Activities are in cards. Cards are stacked in
the order you use them. You can go from phone to contacts to webpage in the
same stack and you can pick any item in that stack, no backbutton needed. It
has a dedicated gestures area which is more powerful than 4 buttons and
definitely better than one.

~~~
cpeterso
I imagine Android could easily display Activity switching and Activity Stacks
as webOS-like cards. RIM engineers quietly admit they stole the PlayBook's app
switching GUI from webOS cards.

~~~
yardie
Google did hire away the designer, Matias Duarte, from HP/Palm. I wouldn't be
surprised to see more WebOS-like GUI actions in future versions of Android.

------
dannyr
Deeper integration with the Android OS allowed Bump to offer more
functionalities than its iOS version. Same with the Dropbox app.

------
Apocryphon
I love these compare-and-contrast articles about developing on different
smartphone platforms, but I'm interested to see how the second-tier ones go,
as well. I've heard that webOS is a delight to develop on, WinPho is bad, and
I'm not sure about Blackberry OS or the other lower-tier ones.

~~~
jjcm
I'm doing Winphone dev right now, so hopefully I can share some insight into
it. It's not necessarily bad, it's just restrictive. The APIs right now for
silverlight applications on the winphone (the primary development framework,
the other being XNA) are pretty sparse. If you want to do something outside of
the scope of what silverlight provides, then you're going to be flustered.
That said, the WYSWYG (expression blend) editor for animations and basic app
construction is the best out there in my experience. On android and iphone I
typically just wrote front end by hand. While the drag and drop functionality
in xcode was very nice, I felt restricted by it. Eclipse's WYSWYG editor feels
like an afterthought rather than a primary feature.

Now keep in mind, I'm a vim guy. I'm by no means a fan of WYSWYG editors, but
winphone's one is actually quite helpful. It makes sense though - silverlight
was Microsoft's solution to flash, so they built a program that followed the
same nonlinear editing model that Flash does. It wasn't a framework that they
built for a phone, it was a phone that used an existing framework - and that's
the reason for all of it's pros and cons.

~~~
LokiSnake
> On android and iphone I typically just wrote front end by hand. While the
> drag and drop functionality in xcode was very nice, I felt restricted by it.

Those two are actually very different actions in Cocoa development. From what
I remember, when you use drag and drop to create objects, those objects are
actually created and serialized when you save the interface file. Creating the
front end in code is a very different process in comparison. I have to agree
that creating iOS UIs using the Interface Builder portion does feel
restrictive at first, but it's actually an amazing tool for creating and using
standard UI elements.

------
pacomerh
I personally love how android handles the latest activity window by dragging
down the top area. Is there something similar on iOS4?. This and the back
button are really good features.

------
sehugg
Good feedback. Makes some good points; the pixel-perfect layout vs. flow
layout is a very significant difference. We've done a similar bullet-point
writeup: [http://voxilate.blogspot.com/2010/11/ios-and-android-odd-
dev...](http://voxilate.blogspot.com/2010/11/ios-and-android-odd-development-
couple.html)

One major pain point is dealing with fragmentation. Of course iOS is no
stranger to this, but it seems Apple does a better job preserving backwards
compatibility. On Android there are wholesale API changes between 1.x and 2.x,
and apparently Honeycomb revamps the entire Activity UI framework. Yuck.

~~~
ikhare
I haven't researched Honeycomb in detail, but current apps work just fine on
Honeycomb as long as you say in your manifest that you support large screens.
Bump for example, works just fine on the Xoom without any custom work
(obviously we haven't optimize for the tablet form factor yet though).

I don't think I agree with the entire UI framework being revamped. Can you
point me to something specific?

The Android framework engineers also try often to introduce features that get
back ported to older version. A good example of this is the concept of
Fragments that was introduce in Honeycomb but has been back ported all the way
to 1.5 (I believe).

~~~
mks
We have got into minor issues with Honeycomb - the new selection/copy/paste in
the text areas took our app by surprise. The other thing was TAB key events
that don't get fired from the Honeycomb keyboard even if tab is inserted to
the text correctly. However these are probably edge cases.

My biggest gripe is that Honeycomb emulator is dead slow, so testing anything
on it without a real device is really painful.

~~~
GeneralMaximus
This is because the Android emulator is a real emulator emulating an ARM
instruction set on your x86 box (it uses QEMU), whereas the iPhone Simulator
is a proper port of CocoaTouch to Mac OS X.

I think both of them suck. The Android emulator is slow and the iPhone
Simulator is inaccurate[1].

Here's an effort to port Android to x86: <http://www.android-x86.org>. I see a
a 100% x86 Android emulator running on VMWare in the near future. Tasty :)

\--

[1] For example, the iPhone Simulator lets you use NSFileManager to create
files and directories _inside_ your app bundle. This does not work on the
actual device. I ran into this during a demo :|

------
D-mo
Interesting to hear the differences between the two platforms re: design
constraints. Helps explain a lot about why it takes many other apps so long to
develop an android version. Looking forward to a better Android version of
Bump, since the last wasn't always reliable.

~~~
ikhare
I actually don't think it's faster or slower to develop on one platform vs.
another. The speed of releases you might see from companies probably has more
to do with their release cycles and resources they devote to it.

Also a lot of Android developers these days are much newer to the platform
than iOS. Thus there is a certain amount of learning involved which can slow
down development. As I said in the article, iterating on UI was much faster on
Android than iOS which can be a big win if that's where the complexity of the
app lies.

------
mks
I often hear about important UI changes when porting from iPhone to Android to
make the app look more native. Could you (OP or anyone else with the
experience) be more specific of what they are? Some examples?

~~~
ikhare
Sure. One of the things that we do in the iPhone app is to open each of our
media screens as modals, then when you bump we slide in the chat screen that
shows the data that was transferred.

Modals mean slightly different things in Android from iPhone, they truly are
something that pop up and should be immediately dismissed. So all of our media
screens had to be slide in from the right instead of modals so using the back
button makes more sense.

Another thing is autofilling out the user's contact information for them if we
can. Android gives us richer information about device and user identity (only
after we are given permission at download time of course). We can use this to
make the process of setting up your contact to Bump a breeze.

~~~
mks
Ok, thanks. It seems that apart the obvious stuff (Menu+Back buttons) it is
mostly tweaking the app to use the correct widgets/APIs for the task.

Based on various comments about porting I was affraid I am missing some grand
user experience pattern that exists on one of the platforms but not the other.

------
sosuke
I was excited when he started talking about the resolution differences but
then quickly bummed that he didn't even scratch the surface to talk about just
how the changes affected the development.

~~~
ikhare
I am the author of the article. What aspects do you think I missed that you'd
like to know more about? My first draft was much longer with a lot more
details but I was worried about a writing a book instead of an essay :-)

~~~
sosuke
I've been kicking around the idea of rewriting some of my apps for Android and
the resolution differences has always been a big worry of mine. As another
commenter pointed out you did allude to the Android UI being more like a
scalable interface you don't always have control over but sometimes we still
have to use pixel perfect designs, even on the web. For using the standard UI
elements it makes sense to fit in with a scalable design but I've thought at
length about games and how that would work across different resolutions
without being able to rely on using high and low res graphics. iOS gives me a
lot of crutches to just know what systems I have to support and the shear
variety of screens and systems gives me a lot of pause for the layout or
number of versions I'll have to package up.

Honestly I should be researching this myself, I just got excited when the
topic came up in your article and was sad to see that it didn't answer my
every question I've been mulling over for some months now. It was my
expectations what were unreasonable and not your articles content.

~~~
mks
Google has put quite an effort into documenting how to take care of multiple
screen sizes - check
[http://developer.android.com/guide/practices/screens_support...](http://developer.android.com/guide/practices/screens_support.html)

I am not sure how it helps to game developers but it is pretty concise guide
for general app development.

We have gone through the screen size adjustments and minor incompatibilites
across versions when porting to Galaxy Tab (I have summarized the experience
in the blog: <http://touchqode.com/blog/008_developing_for_galaxy_tab.htm> )
and then when Honeycomb came out.

But more often than not it is our hackiness or vendor fancy tweaks that cause
problems rather than the android itself.

