8 ms·

IOS vs. Android from the Trenches

121 points by jmintz 15y ago

sosuke 15y 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 15y 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.
- ikhare 15y 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 15y 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.
    - ikhare 15y ago
      I actually really meant this from a UI perspective where the _screens_ from different applications can flow back and forth between each other. But data is an equally important point to bring up.
      - baconner 15y ago
        There's a negative aspect to the multi app ui history model as well though in that its easy to create confusing app launch and back button behaviors. Example: if I jump from my app to the browser then hit home then later relaunch the app and I'm confused because I start in the browser. Having the ui stack capability across apps is great but as a developer it requires some extra effort to avoid confusing incidents like this for users.
        antrix 15y ago
        > Example: if I jump from my app to the browser then hit home then later relaunch the app and I'm confused because I start in the browser. As an Android developer and a long time Android phone user, I have to say that this can _never_ happen. Do you have a real example?
        baconner 15y ago
        Hmm.. you are right I've imagined this behavior. I could've sworn I'd seen this happen a number of times but looking back now I'm not seeing it.
  - sosuke 15y 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.
    - mks 15y ago
      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.html http://developer.android.com/guide/practices/screens_support... 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 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.
    - GeneralMaximus 15y ago
      If you have an application that runs only on cell phones, you shouldn't be worrying about different screen sizes. Have you used layouts in Qt or any other UI toolkit? UIs on Android work in a similar way. Android will properly scale your UI to different screen sizes, just like a Qt window can be resized without crapping up its layout. About graphics: Google defines 4 screen densities: XHDPI, HDPI, MDPI and LDPI. You create separate graphics for each of them and import them into your project. Android will automatically pick the appropriate version of your artwork depending on the device your app is running on. No manual work required. E.g, <LinearLayout android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:background="@drawable/slate"> </LinearLayout> See that @drawable/slate in there? Android will try to find the appropriate version of "slate.jpg" (or "slate.png", or whatever) from one of these directories: res/drawable-hdpi, res/drawable-mdpi or res/drawable-ldpi. If it can't, it'll try to look for the file in res/drawable[1]. So you have 3 versions of the file residing in 3 separate directories. Don't worry about screen sizes. They don't vary too much anyway. Phones these days lie somewhere between the 3" to 5" spectrum. Not much of a difference for most apps, unless your UI is doing something very special. --- [1] This is the default project structure; you can probably change it.
D-mo 15y 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.
- ikhare 15y 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 15y 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 15y 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 15y 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 15y ago
vlucas 15y 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 15y 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.
  - smackfu 15y ago
    I sometimes wonder what percentage of iPhone users even know about double-click home to task switch.
    - enjo 15y ago
      I bet about the same percentage that know about the long-hold of the home button to bring up the task switcher in Android (not many). I was amazed that my wife, who has had an Android phone for a year, didn't know about that one...
      - kgtm 15y ago
        It isn't a task switcher though is it? It just lists the apps you used recently, not the ones that are open. AFAIK you need a separate app that is binded to the home button to get different behavior.
        runjake 15y ago
sehugg 15y 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-development-couple.html 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.
- ikhare 15y 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).
  - mks 15y 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.
    - ikhare 15y ago
      Interesting, I'll keep that in mind if/when I get to deeper Honeycomb development. As for the emulator, Android is notorious for it's terribly slow emulators. I've basically stopped using them and only use actual hardware to test on. The emulator is good for surfacing race conditions that only show up on super slow devices tough :-)
mks 15y 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?
- ikhare 15y 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.
  - mks 15y 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.
- dannyr 15y 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 15y ago
    Except the many Samsungs have no dedicated search button. :-(
dannyr 15y ago
Deeper integration with the Android OS allowed Bump to offer more functionalities than its iOS version. Same with the Dropbox app.
pacomerh 15y 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.

121 points by jmintz 15y 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 15y 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.
ikhare 15y 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 15y 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.
  - ikhare 15y ago
    I actually really meant this from a UI perspective where the _screens_ from different applications can flow back and forth between each other. But data is an equally important point to bring up.
    - baconner 15y ago
      There's a negative aspect to the multi app ui history model as well though in that its easy to create confusing app launch and back button behaviors. Example: if I jump from my app to the browser then hit home then later relaunch the app and I'm confused because I start in the browser. Having the ui stack capability across apps is great but as a developer it requires some extra effort to avoid confusing incidents like this for users.
      - antrix 15y ago
        > Example: if I jump from my app to the browser then hit home then later relaunch the app and I'm confused because I start in the browser. As an Android developer and a long time Android phone user, I have to say that this can _never_ happen. Do you have a real example?
        baconner 15y ago
        Hmm.. you are right I've imagined this behavior. I could've sworn I'd seen this happen a number of times but looking back now I'm not seeing it.
- sosuke 15y 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.
  - mks 15y ago
    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.html http://developer.android.com/guide/practices/screens_support... 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 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.
  - GeneralMaximus 15y ago
    If you have an application that runs only on cell phones, you shouldn't be worrying about different screen sizes. Have you used layouts in Qt or any other UI toolkit? UIs on Android work in a similar way. Android will properly scale your UI to different screen sizes, just like a Qt window can be resized without crapping up its layout. About graphics: Google defines 4 screen densities: XHDPI, HDPI, MDPI and LDPI. You create separate graphics for each of them and import them into your project. Android will automatically pick the appropriate version of your artwork depending on the device your app is running on. No manual work required. E.g, <LinearLayout android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:background="@drawable/slate"> </LinearLayout> See that @drawable/slate in there? Android will try to find the appropriate version of "slate.jpg" (or "slate.png", or whatever) from one of these directories: res/drawable-hdpi, res/drawable-mdpi or res/drawable-ldpi. If it can't, it'll try to look for the file in res/drawable[1]. So you have 3 versions of the file residing in 3 separate directories. Don't worry about screen sizes. They don't vary too much anyway. Phones these days lie somewhere between the 3" to 5" spectrum. Not much of a difference for most apps, unless your UI is doing something very special. --- [1] This is the default project structure; you can probably change it.

D-mo 15y 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.

ikhare 15y 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 15y 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 15y 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 15y 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 15y ago

vlucas 15y 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 15y 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.
- smackfu 15y ago
  I sometimes wonder what percentage of iPhone users even know about double-click home to task switch.
  - enjo 15y ago
    I bet about the same percentage that know about the long-hold of the home button to bring up the task switcher in Android (not many). I was amazed that my wife, who has had an Android phone for a year, didn't know about that one...
    - kgtm 15y ago
      It isn't a task switcher though is it? It just lists the apps you used recently, not the ones that are open. AFAIK you need a separate app that is binded to the home button to get different behavior.
      - runjake 15y ago

sehugg 15y 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-development-couple.html 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.

ikhare 15y 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).
- mks 15y 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.
  - ikhare 15y ago
    Interesting, I'll keep that in mind if/when I get to deeper Honeycomb development. As for the emulator, Android is notorious for it's terribly slow emulators. I've basically stopped using them and only use actual hardware to test on. The emulator is good for surfacing race conditions that only show up on super slow devices tough :-)

mks 15y 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?

ikhare 15y 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.
- mks 15y 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.
dannyr 15y 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 15y ago
  Except the many Samsungs have no dedicated search button. :-(

dannyr 15y ago

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

pacomerh 15y 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.