IOS vs. Android from the Trenches

http://devblog.bu.mp/ios-vs-android-from-the-trenches

by jmintz • 15 years ago

121 61 15 years ago

devblog.bu.mp

sosuke3• 15 years ago

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.

mbateman• 15 years ago

He did talk about it. He says that the declarative XML layouts make it easy to iterate the UI, but hard to make it pixel perfect, and is therefore akin to web design.

ikhare8• 15 years ago

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

endgame• 15 years ago

Nit:

> One example of a future looking architecture decision is how different applications can flow back and forth between each other.

I think you mean "...how data from different applications..." or something.

sosuke3• 15 years ago

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.

D-mo• 15 years ago

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.

ikhare8• 15 years ago

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.

Apocryphon• 15 years ago

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• 15 years ago

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• 15 years ago

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

estel• 15 years ago

There was an interesting talk at I/O that focused largely on the Eclipse WYSIWYG tools that I was watching earlier. Having mostly done my best to ignore them before now, the tools are looking in a much better shape than they once were.

http://www.google.com/events/io/2011/sessions/android-develo...

mahyarm• 15 years ago

Reminds me of webos in the earlier days.

sehugg4• 15 years ago

BB is sort of like programming in 1999. You've got an ancient JVM version, so you can't use very many 3rd party libraries. The default widgets are completely style-free so any chroming you want to add is a custom job. Even persistence becomes tricky as java.io.File isn't available.

On the pro side, APIs tend to be more straightforward compared to Android. One benefit is that you can write much of your code in a synchronous style without callbacks or risking the dreaded ANR (Activity Not Responding) exception. Just don't expect to reuse a lot of your code without major modification.

kgutteridge• 15 years ago

I've been developing for mobile for nearly ten years and trust me when I say unless you need to support a particular device avoid the legacy platforms, at least until you have a proven mass market app.

J2ME is Micro Edition for a reason, much of the seemingly simple on other platforms you will have to roll yourself and test everywhere.

BB dev is like swimming through treacle or as one of my colleagues put it "death by a thousand paper cuts without the relief of death at the end".

WebOS is a pleasure for web developers, but when you try and make custom UIs or deviate from the framework it can become a pain quickly

Symbian is thankfully a footnote now

recoiledsnake• 15 years ago

>WinPho is bad

What made you think WinPho is bad? Just curious.

seanx• 15 years ago

>> WinPho is bad

Win Phone is fantastic but incomplete. I.e. not all the api's are there but the bits that are there work well.

I haven't used the latest xcode, but when I was developing for iPhone (2-3 years ago), it was god awful.

I haven't done android dev yet but the feedback I get from friends doing it on Windows is that it is a major PITA getting set up. ..

timknauf• 15 years ago

Xcode has taken a big step forward with version 4. It still has some teething troubles (it seems to get sluggish after about six hours of being open, at least on my machine), but features like code completion actually work now. Most of the time, anyway. :)

vlucas• 15 years ago

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.

jsz0• 15 years ago

Since iOS4 if you double-tap the home button the left most icon in the application switcher is the last application you were in. Probably not as seamless but it prevents accidental back button presses which is something that has caused me problems on Android. If I buy another Android phone I will definitely try to find one with hardware buttons that are not located directly below the display.

smackfu2• 15 years ago

I sometimes wonder what percentage of iPhone users even know about double-click home to task switch.

sosuke3• 15 years ago

Even more fun in the iOS 4.3 devices you can do multi-touch gestures to get to the other apps, home screen or swipe between running apps. Video: http://www.youtube.com/watch?v=wvxSSGUtTYA

ikono3• 15 years ago

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.

enjo2• 15 years ago

On quibble: In Android the back button really seems to serve the purpose of "take me anywhere BUT here". I have no real cognitive sense (generally) of where I am in the stack. I simply hit the back button until I get back to something that looks familiar.

spot• 15 years ago

I use both and trust me, the back button is good. Your browser has it... even on iOS. Do you have a problem "remembering" where it will take you?

GeneralMaximus3• 15 years ago

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?

sehugg4• 15 years ago

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

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.

ikhare8• 15 years ago

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

mks4• 15 years ago

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.

sehugg4• 15 years ago

Yep, by "revamped" I meant Fragments. From Reto Meier's blog: http://blog.radioactiveyak.com/2011/02/strategies-for-honeyc...

Apparently the new Fragments API will be (is?) available on pre-Honeycomb devices as a static library, and I'm guessing there will be some compatibility with the 'legacy' Activity API in Honeycomb. Still I'm guessing there will be rough edges and unexpected incompatibilities, as there are between 1.x and 2.x versions.

ksolanki• 15 years ago

As someone who has developed exclusively on Android, this article seems like an interesting read, especially because it is written by someone who has programmed in iOS before moving to Android ("porting" iPhone app to Android). I wonder if the take would be different when I/someone move(s) to iOS from Android.

I agree that fragmentation is one big pain point of Android. It needs to be considered even between different device manufacturers, not just API changes, when it comes to things like the camera preview. UI responsiveness is another factor that is a disadvantage in Android, which has to be considered explicitly while developing.

ikhare8• 15 years ago

I didn't mention it in the article, but I did Android programming before I did iOS. I was doing Android programming before the iPhone SDK came out in 2008. When the iOS SDK came out, I moved to the platform that had real users and phones. Android didn't have actual phones until late 2008.

I don't remember much of my feelings of the platforms from those early days because I was in a frenzied coding mode trying to release the first few apps in the App Store. But I do remember being frustrated by the lack of something like a GridView in iOS.

mks4• 15 years ago

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?

ikhare8• 15 years ago

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.

mks4• 15 years ago

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.

dannyr2• 15 years ago

Iphone apps need to display Back, Search, and Menu buttons. With Android there is no need to display them in your app since there are dedicated physical buttons for them.

andybak• 15 years ago

Except the many Samsungs have no dedicated search button. :-(

dannyr2• 15 years ago

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

pacomerh• 15 years ago

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.

IOS vs. Android from the Trenches

Related Stories