Android & iPhone App Design: Is it twice the work?

Related posts:

Less than one year ago, most of my clients were requesting iPhone app design.  Today they are still asking for iPhone app design but many also say, “Do you do Android, too?”  Most of them plan to start with one platform, see how things go, and then decide whether to invest in the second platform.  This roll-out strategy is often tied into engineering costs.  Since few developers possess the coding skills required for each platform—Objective C for iPhone and Java for Android—it’s often necessary to hire two development teams. But what about design?

Would I, too, have to do twice the work when designing for the iPhone and Android?  And what will happen if the Windows, Palm, and Blackberry app stores take off?  Would I have to do five times the work?  This dilemma reminded of the “browser wars” back in 1996, when Netscape and Microsoft used to hire evangelists to teach design and coding for their respective browsers.  Eventually these proprietary standards were replaced with industry-wide standards but it didn’t happen overnight.

Many say the same will be true of the different smartphone platforms, that they’ll eventually be replaced with something like HTML 5.  This could happen at some point, but we’re not there yet.  HTML 5 works well for “web apps” and “hybrid apps.”  “Web apps” look very much like native apps but they can’t access device data and hardware such as the user’s contacts, the photo library, voice recording, and device movement. In contrast, “hybrid apps,” which provide access to web content through a web viewing area, can access the device hardware and include native user interface elements.  Companies like PhoneGap provide tools to simplify cross-platform development for hybrid apps.  Using these tools, developers can create apps that are nearly identical across platforms.  This may be effective for certain apps, e.g., games, but productivity apps, e.g., email, may want to customize the UI for each platform.

So we’re back to the dilemma: do designers have to do twice the work to create native apps for the iPhone and Android?  Based on my recent analysis, I came to this conclusion: the app definition and concept phases would be very similar regardless of platform, but the app refinement and production phases would require adaptions to create full-fledged native apps for each platform.  The remainder of this article discusses these differences based on these four phases: Definition, Exploration, Refinement, Production.


In the definition phase user research can help you acquire a deep understanding of your users’ needs and how these needs are currently being met.  With this research foundation, you may uncover opportunities for new apps and develop innovative solutions that improve upon existing apps.   Your user research methods in the Definition phase—diary studies, user interviews, shadowing— will be similar regardless of platform.  To learn more about these methods, consider reading Jan Chipchase’s Methods Blog.

In the Definition phase, you’ll also want to read each device’s technical specifications and UI guidelines (e.g., iPhone Human Interface Guidelines, Android’s User Interface Guidelines, Android UI Tips) Knowing what’s possible will help when you get into concept development. App designers should also learn about multi-touch gestures which are well-documented in the following Touch Gesture Reference Guide. The iPhone and Android have significant overlap but there are a few exceptions.


Armed with your upfront research, you’ll want to start brainstorming and sketching app ideas.  Try to be as platform agnostic as possible since it will allow you to freely explore a variety of concepts without getting bogged down by platform differences.  This can be challenging if you have more experience with one platform since you’ll naturally gravitate to what’s familiar.  For example, given my knowledge of the iPhone, I instinctively include Back buttons in my sketches, but Android doesn’t use Back buttons.  On Android, users must tap the Arrow button on the device to go back.  As an alternative, a platform agnostic sketch could include arrows to illustrate navigation between screens.  Similarly, storyboards can work well if they highlight the user and context and place less emphasis on screen designs.

Once you start prototyping and testing your app concepts, it will become increasingly difficult to remain platform agnostic, though this may depend on the app.  For example, gaming apps tend to be self-contained so your prototypes may be very similar across platforms.  But apps like Facebook and Yelp have different navigation styles for the iPhone and Android.  If you test prototypes with users, they may be confused if the apps don’t follow platform conventions.  Notable differences between iPhone and Android navigation are summarized below.

iPhone and Android navigation differences

To illustrate these navigation differences, let’s compare Facebook’s iPhone and Android apps (see images below).  Notice how the iPhone app has one button that goes Home/Back whereas the Android app uses the Facebook logo to go Home and the Arrow button on the device to go back.  Tasks are also treated differently.  On the iPhone primary tasks (status update and commenting) are accessed directly on the page; secondary tasks (load new posts) are accessed by “pulling down” the screen.  On Android, status updates are treated the same way as the iPhone, however, other tasks are accessed through the Menu or by tapping and holding table rows.


Once you get into your app refinements, it will become increasingly difficult to incorporate abstract design elements.  Even if you have an app that’s self-contained, such as a game, you may have a sign up process, settings, or other features that require you to follow platform conventions.    In some cases, you may be able to embed HTML within your native app but these controls may be less ideal than their native counterparts.  For example, Android and iPhone have created widgets to make it easier to choose dates in the mobile context.  Native apps can easily incorporate such widgets but embedded HTML pages can not.  Below is a partial list of common UI controls for the iPhone and Android.  For a complete list of iPhone UI controls, please see the Application Controls section in the iPhone HIG.  Unfortunately, the Android UI Guidelines do not include UI controls.  You may need to dig into the Android Developer Docs.


When you reach the production phase of your app design process, you’ll want to make sure your images are the correct resolution for each platform.  Unfortunately, not only are there differences between platforms but there are differences within platforms.  For the iPhone 4, the new Retina Display is at 640 x 960 whereas the earlier phones were at 320 x 480.  And with Android, the latest Droid X is at 480 x 854 which they call HDPI, but older phones are lower resolution and called MDPI.  Both operating systems will auto-scale high resolution images down, though some developers I spoke with don’t trust the quality.

To minimize the work involved with multiple platforms and resolutions, make sure all of your custom assets are absolutely necessary.  Aside from your company logo and/or symbol you may not have to create many assets.  Both platforms provide icons for common app tasks (take a look at the iPhone icons and Android icons) and there are a number of services that sell icons at a reasonable cost.  If neither of these options meet your needs, consider hiring a skilled illustrator for the work.


iPhone and Android are the current market leaders in the smartphone space but things are likely to evolve in the years to come.  We may see Windows, Blackberry, Palm or another competitor edge into first or second place.  Whatever happens, more and more designers are going to be confronted with the question: Will I have to do twice the work?  Five times the work?  Part of me would like to see standards evolve, mostly from a user experience standpoint but also from a business perspective.   Standards will make it easier for companies to provide smartphone apps on multiple devices.  As it stands now, they need to prioritize devices because of the costs involved.  At the same time standards could slow down the rapid pace of smartphone innovation, which would negatively impact everyone. And of course HTML 5 holds great promise but it’s too soon to tell if it will eventually replace the native app platforms. For now, I hope this articles helps you in your endeavors and perhaps you’ll only need to do less than 1.5 times the work.


Thanks to Omar Younis,  Marty Picco, Jonathan Stark, Michael Mayo, and Emmanuel Carraud for sharing their insights on this topic.

Further Reading


Suzanne Ginsburg

Suzanne Ginsburg is a user experience consultant based in San Francisco, California, and the author of Designing the iPhone User Experience. She works with many different kinds of organizations, from established technology companies to small iPhone start-ups. Suzanne also maintains a UX blog, iPhone UX Reviews, where she reviews iPhone and iPad apps and provides advice on app design. If you’d like to stay in touch with Suzanne, follow her on Twitter @suzanneginsburg.

32 comments on this article

  1. Elisa Bond on

    Great article …thnx

  2. Pingback: App-Design-Prozess für iPhone & Android: Doppelte Arbeit? | Studio B12 Blog

  3. Steve on

    Great article – I wonder if Adobe AIR may be able to address some of the cross-platform issues? Adobe is starting to gear up for what it terms ‘multi-screen projects’, but it seems like a tall order to cater for every device/resolution within a single project.

  4. Pingback: Mobile UIs: is AIR + Multiscreen the solution? « YAY!MEDIA – Flash Platform Development Blog

  5. jacob on

    are the underlined items supposed to be linked?

  6. Suzanne – this is piece is a great exploration of the issues but today ther exist myriad services (including ours on which, depending on the complexity of your requirements, which have worked through the most salient issues (such as navigation). I’d suggest you also check out,, and mobileroadie.

    We also cover the HTML5/Webapp front, and we’re working on BB infrastructure. I suspect most other services that help cultural institutions go mobile are doing the same.


  7. sheridap on

    From a design pattern perspective, you article makes perfect sense.

    Platform independent mobile is here imho. With platforms such as Sproutcore (the essence of Apple’s MobileMe SaaS app) allowing for 80% or so of the gestural touch experience to approximate on the web, the question becomes, how soon before the mobile browser will become the OS?

    There is also a LOT of work that has to happen under the water line at enterprise clients to add the content and data services needed to take the current performance issue off the table (what else is new).

    Thanks for sharing your thoughts!

  8. Leesam on

    Brilliant article but why hedge your bets surely using and Application Platform such as uniPaaS for your development is a viable option, this would allow you to write your code once and deploy across any mobile from Windows to Android to Blackberry

  9. Great article Suzanne! It reflect what we are experimenting at MAgicSolver, porting our iPhone apps to Android

  10. Thanks Suzanne,
    It is a good analysis of what we are experimenting at MagicSolver, porting our iPhone apps to Android.

  11. Jason on

    I do a lot of web-based app development (front-end & design) and I find that if you have a good understanding on how things are rendered on mobile devices (and you know WebKit CSS rules) you can often create an experience that translates well on both the iPhone and any Android device.

    I also know that this blog layout breaks in Chrome. Way pro.

  12. Tal Givoly on

    Suzanne, this is excellent info and analysis for anybody planning app development address mobile smartohone platforms. In particular if they are iPhone and Amdroid. It would be great to hear your take when adding two other important target platforms: Blackberry and the iPad. Both if the, but mostly Blackberry, have a lot of differences in user interface conventions. What can are the equivalents there?
    Obviously you show there is a lot of shared effort between the platforms. As one of the commenters has noted, the more backend server side functionality an application has, the more reuse there is.
    Another point to consider is the notification mechanisms and distribution mechanisms of the applications. Would be great to have a view on these as well.
    Thx for the terrific piece!

  13. Pingback: Bookmarks for August 29th through September 10th | Demian's Tech Blog

  14. Guillaume Balaine on

    Suzanne, great article that I came across when looking exactly about being efficient in implementing an app for multiple OSs (Android and iOS for now). You address the problem well.
    I think that in the future, people will have to start acting like real engineers and not just programmers. Meaning that rather than just trying to put everything in web applications, businesses should try to find the most efficient abstract design formats that minimize costs when programmers implement changes onto whatever application you’re going to.
    For now, UML design could be the key, but you would not be able to translate it efficiently into code (at least not the abstract part).
    You also mentioned unexpected growth of a platform making it worth to deploy the app on it, and by minimizing the cost of design and implementation like this you will maximize the profits.

  15. Pingback: Flickr Map Screenshots: Hayes Valley Farm | MagneticFreedom Live

  16. Pingback: Cisco overcomes supply problem in security | MagneticFreedom Live

  17. Great article! I think you’ve touched on some important points that others seem to be ignoring. I’ve heard a lot of talk about gestures as the key to a common interface. But as you mentioned, it’s just as much (if not more) about interplay of the interface elements, placement of these elements, and how they effect view transitions. What I’d like to hear more (and you’ve covered this with a great deal of detail in your book) is more discussion around the view transitions and navigation across screens.

  18. Ja'Kobe W. on

    Ummmm i honestly think that Androids are wayyyyyy better than some iPhone 4. Because let’s see iPhone vs. Evo. Da Evo will win automatic <3!

  19. Pingback: Designing for Devices | cazh1

  20. Paul on

    Good article. One other thing to consider is that iPhone apps can quite reasonably only support portrait mode, whereas on Android you must support portrait and landscape.

    I see this screen orientation issue as very challenging for designers, and may increase the amount of work you need to do for Android apps. What is your experience?

    Kind regards

  21. Pingback: John From Berkeley » links for 2010-11-30

  22. Pingback: Mobile Apps made easy

 | Skylark | Blog

  23. Pingback: 当人们在学习工作论文的时候,我都在干嘛 « Wandering

  24. interesting read – we are finding that more and more of our clients are now wanting apps as part of their marketing mix

  25. Thomas on

    This is greeat article! The development of cross-platform apps is the topic of many discussions I currently have with customers. I share your opinion about the pros and cons.

  26. Pingback: App Design « tamsinlegge

  27. Apps and mobile design are the utilities of the future. These are imperative aspects of any online business wanting to succeed with connecting with their customers

  28. mahmoud on

    fdjnvuio jiffj

  29. atomiku on

    There is a thing called PhoneGap that will let you build apps in HTML5 and JS that will work on iPhone, Blackberry and Android with no extra effort. It also allows you to access native features such as camera, contacts, network, notifications, etc… Definitely worth a try!

  30. Ksiussa on

    Thank you, interesting stuff! I like to build apps my own, but I haven’t enough programming knowledge and I decided to use an online app builder. At first it was quite difficult to find low cost and effective web service for this aim. At last I’ve found one called Here, anyone with zero knowledge of programming can be successful app maker. Also, there you can also there you can find many ideas.

  31. Kelly Jones on

    Awesome post. Here ‘s a great tool that lets you build apps without coding. Just point and click to build your web or mobile app

  32. Amit Kumar on

    It is a too good article.We have similar kind of requirement where we need to make our existing iPhone app andriod compliant. The article has cleared most of my UI design related doubts.