Three Common iPhone to Android Pitfalls and How to Avoid Them

Ever since Android devices have started to overtake the iPhone in terms of growth (and according to some reports, in terms of actual market share), I've been seeing a lot more companies take a serious look at both porting their existing apps to Android and developing new apps side-by-side for both platforms. I want to get straight to the point and demolish delusions you have that you can exactly port the UI for your current iPhone app screen for screen, rewrite in in Java, call it a day and expect rave reviews. Here's why.

 

Pitfall Statement 1

"I can reuse all my iPhone designer's mockups for Android!"

Sorry! One of the great things about Android and the iPhone is that they're both easy to learn platforms. That ease of use depends on internal consistency -- if you've used Android's Browser app, you've learned navigational skills you can use in the Google Voice app, and so on. But the platforms have settled on different (and still evolving!) UI paradigms in a few key respects.

A few quick examples: the iPhone has the shake-to-undo gesture, the swipe-to-delete gesture, the edit-list-mode, the bottom-tabs-with-internal-segmented-navigation, and the persistent-top-back-navigation-bar.

On the other hand, Android devices reliably have a physical back button and options-menu button, and apps rely on different Android-specific standardized UI concepts like quickaction popups and long-hold context menus, and have no real concept (at least in any built-in apps) of within-tabs subnavigation. In fact, top-level tab functionality has all but been replaced in new and upcoming Google applications like the official Twitter app and the Google I/O 2010 event app with Dashboard-pattern activities. You can read more about the evolving patterns Android is officially settling into in this post from the Android UI team at Google.

If your app relies on highly interactive lists, deep or complex navigational structure, search, and platform-specific gestures like shakes or multitouch swipes, you'll have to think hard about what to do. You may end up losing one-to-one equivalence between your iPhone controllers and Android activities in the process; that's OK. What's important is that Android users can pick up your app and understand intuitively how to interact with it based on what they've already learned as Android users. Trying to create perfectly identical interactions across iPhone and Android versions of your app is not only unimportant, it can actually impede users from being able to just pick up your app and go.

 

Pitfall Statement 2

"I can settle on a target of one specific device and test against that; other platforms/devices will probably just work without me thinking about it (or will just be unsupported because I can't be bothered)."

Here's the bad news: Android fragmentation is real.

Here's the great news: It's remarkably easy to make your app work wonderfully on different screen sizes and resolutions, OS versions and screen orientations. Here's the bad news again: you'll have to be thinking about this from the outset. Provide resources at multiple densities, size your layouts in DIP (device-independent pixels) and SP (scaled points), and don't assume your users have a physical keyboard, trackball, or giant 4.2" widescreen. It's easy to do; Google's guidelines are fairly comprehensive.

Good news again: Backwards-compatibility on Android is fantastic; most any app built for Android 1.5 will run without problems on Android 1.6, 2.1, and 2.2. Bad news: You'll have to be careful to target the minimum OS version you really want and avoid using API calls introduced in later versions, which means you may miss out on a few shiny new features that make things more convenient. But that's usually a small price to pay for being able to target older or lower-end devices.

And be sure to test against any carrier or manufacturer-specific custom UIs you may come across. The most common of these are HTC's SenseUI (used on the EVO 4G and Droid Incredible) and Motorola's Blur (used on the Droid X). The differences for most app developers are usually pretty minor, but it's worth testing against if you plan to support those devices.

 

Pitfall Statement 3

"There's no need to support landscape; portrait should be good enough for anyone."

With the exception of applications that have a specific reason to lock orientations (games, for example), Android users expect to be able to use most apps in both landscape and portrait orientation. This is especially true for screens with text inputs; the most popular Android device in the US (Motorola Droid) has a landscape-only slide-out keyboard. Here's an example of an older app I helped rewrite that forces users on the Droid to tilt their heads sideways while they type if they want to use the hardware keyboard:

 

Android-screenshot-landscape

Luckily, Android's flexible layout system enables easily defining proportions for screen elements in percentages (weights) and in wrapping content with a scrolling view where necessary. Take advantage of this and you'll make your app much less frustrating for users with very little work.

 

About Yoni Samlan

Yoni Samlan is the lead Android developer at SCVNGR and founded Active Frequency, a Web and mobile development consultancy.

X