Porting iPhone Apps to Android

May 15th, 2010

Our first Android project is now live. ShoutOUT (from Promptu) is a free speech recognition app that lets you compose text messages in natural speech instead of typing. You can learn more about ShoutOUT on the product site.

We worked with Promptu to port the existing iPhone ShoutOUT App to Android.

Getting Started

We’ve designed and developed for the iPhone, but Android was new to us. To familiarize ourselves with the platform, we experimented with a handful of Android apps on an HTC Magic phone. Specifically, we were interested in mobile apps that were originally designed for the iPhone, and were then ported to Android. We researched how designers and developers handled the transition, and identified best practices for development.

Findings

Although the iPhone and Android phones are both touch-based, there are several differences that impacted our design translation:

Menu Bar

iPhone productivity apps generally have a dedicated menu bar for navigation, but Android leverages the ‘Menu’ button to display contextual navigation. Both methods work, but we removed the iPhone-style menu to make the app behave more like other Android apps.

Physical Buttons

Since Android phones have dedicated ‘Home,’ ‘Menu’ and ‘Back’ buttons. Physical buttons have their pros and cons, but we used the ‘Menu’ button to move items that were in the iPhone menu bar into the contextual menu overlays. This enabled us to gain a bit of real estate that was originally reserved for the Menu Bar. Since the Menu button’s features varied based on the screen, we mapped out all of the potential scenarios. It was difficult to keep the behavior consistent, and while we were concerned that some menu items could potentially be lost, we assumed Android users would be familiar with this pattern since it’s a core part of the native apps (such as Mail, Contacts...etc.)

The other physical button that needed attention was the back button. Initially, it’s behavior seemed fairly defined, but there were a number of instances where we had to workout the best response. This was especially important if the user was in a modal-input view, we didn’t want to users to loose any input by a mistaken push.

Physical Scroll

The Android handset invites multi-modal input. The physical trackball allows users to precisely scroll up and down lists, and it also allows selection via a physical click. Our design needed to take these methods of scrolling and selection into consideration, since they don’t exist on the iPhone.

Fragmentation

Designing specifications for iPhone and iPod Touch is pretty simple (for now). Every application will work the same way across each model since they support the same features. The Android platform is more complicated. The handset makers support different hardware and features, and subsequently the carriers can customize Android and add proprietary UI elements (to distinguish their phones from the competition). The fragmentation issues added complexity to the design task, as we worked out which base set of features we could rely on across all the targeted handsets.

Design

The visual design translation was much more straightforward. We were able to migrate the main UI elements from the iPhone app directly to Android. We did modify the button styles to make them look and feel like Android elements, and we also created specific icons to support the contextual buttons (although many icons were freely available from the Android library).

Screenshots

Taking screenshots with Android was a huge pain. This may have changed with newer handsets, but the only way we could get images from the phone to our desktops was really complicated. We did appreciate some great directions over at Download Squad (via Christina Warren @ Download Squad).

Takeaways

The Android OS is a highly viable platform, and it has already proved a commercial hit in the mobile space. From a designer’s point of view, it’s fairly easy to ‘think’ in Android, and many successful iPhone applications can and will be ported to Android.