People approach me saying "Here’s app on iTunes. How much would it cost for an for an Android version?"
The answer is "It depends". For example, one thing to think about is whether you wish to retain the iOS look and feel or have an Android-esque UI. This matters a lot because keeping the iOS look and feel will require significant extra work and the app will feel odd to end users.
Another factor is which devices you wish to support. Which versions of Android exactly? [Google’s Platform Versions web page shows the versions of devices that have accessed the Android Market over a 14 day period.] Do you want to support Android tablets as well? Should the tablet version’s screens differ in any way?
This article addresses the above issues such that you can approach mobile developers with a better understanding of what’s needed. You need to decide on who is going to re-design the app and if this isn’t going to be the developer, ideally do this before approaching the developer.
The Android Market
Firstly, why develop for Android? These numbers from January 2012 show worldwide Android share over double that of iOS:
This has resulted in investors insisting on Android versions of iOS apps and owners/founders discovering that they are missing out on a large slice of the market. However, it’s a different market. Most apps are free rather than paid. Very few Android paid apps are viable. You need to think instead of freemium strategies and in-app purchasing which might affect the design of your app.
The Android Market itself is open to all. There’s no review mechanism which means your app can do things that might not have been possible under Apple’s terms and conditions. Again, this might affect how you choose to design you Android app. App updates are almost instantaneous which means fewer frustrated end users when there’s a problem with your app. Apps can also be distributed outside the Android Market as simply as putting them on your web site or distributing via email. However, if you do this you might like to include additional update detection and download into your app.
Design for Android
I receive far too many job specs that have wireframes that look like iPhone screens. The problem is that many design tools just have iOS templates by default and people think they can use them to design Android apps. These designs conflict with the look and feel of the device and actually take significantly extra effort to implement. For example, making an Android button or a list look like it does on iOS takes extra effort. The main problem areas are round buttons rather than square, tabs at the bottom rather than top, lists with right pointing arrows, incorrect icons for common functions and back navigation via a top back button.
The first step is not to use iOS design tools. When I am responsible for the design I tend to just use drawing tools. I use Photoshop and an old version of Paint Shop Pro but you can use your favourite drawing tool. However, I have worked with clients who have used Visio (now owned by Microsoft), Balamiq next (Android controls here), OmniGraffle (on Mac and Android template here) and even scans of hand drawings using a metal stencil.
If you want to get a quick overview on Android UI idioms I recommend looking at the android patterns web site. Google also have a great page where they describe how to design for Pure Android as opposed to copying iOS.
Consider Device Variety
As of Android 3.0, Google changed the way apps can be architected internally to allow for both Smartphone and Tablet layouts. At the same time, they introduced a software Action Bar at the top of the screen instead of using a software or hardware menu key at the bottom of the screen. As of Android 4.0, all new apps both Smartphone and Tablet should use the new Action bar. Your ported iOS should also use the new Action Bar. Google provide a compatibility library that allows these UI elements to run on much older Android devices back as far as Android 1.6. This allows one app to support all versions of Android while maintaining a consistent look and feel.
When re-designing you app you should think about how data and graphics will be displayed on much larger and smaller screens (than iOS). You also need to think about vertical and horizontal aspect ratios.
It’s not possible to take Objective-C and re-compile it for Android. Android apps use mainly Java although c can also be used (called) from Java. If your iOS app uses vanilla c (i.e. normal plain c code) then it’s possible to re-use that code on Android. This is useful for porting complex libraries or providing increased performance (e.g. image processing). However, Android has significantly less libraries available for the c code to use and often dependent c libraries also have to ported.
A common mistake I see in UI designs is to embed sharing too deeply into the app. Specifications sometimes include UIs that gather information to be sent to facebook, Twitter or wherever. There’s no need for this on Android. Instead, consider using ACTION_SEND Intents which basically hand off links or text to other (installed) apps such as Twitter and Facebook. The OS handles the interface. It’s so flexible that all you do is offer up, for example, some text and the OS will present all the apps that can handle the text. This means users will be able to automatically share to other apps such as email or Evernote (if they have it installed). The bonus for developers is that there’s no need to write code against the various server-side sharing APIs.
The antithesis of sharing is being able to consume data sent via ACTION_SEND Intents. If your app can handle a common format, for example, music, images or text then it might make sense to provide an interface so that other apps can send you information.
Java is slower that compiled Objective-C. You should think about what parts of your app are time sensitive. This might lead to changes in capability or design, for example use of native c code, or alternative special techniques to prevent Java garbage collection.
Java has a relatively small heap size (working memory size to the layman) compared to iOS. This means, for example, it’s not possible to open images full size. This might impact on your app and you might have to do things differently or move the code to c where there’s no such restriction.
Some iOS apps are crippled due to the fact they can only run music, voip or GPS in the background. Android can do significantly more in the background than iOS. For example, it can fetch from your server while the app isn’t running. Your existing iOS app might do some convoluted things to get around the lack of real background processing which need not be replicated for your Android app.
Android Java apps are very easy to decompile to get back to the original source code. You should insist your developer obfuscates the code so that reverse generated code is less readable. It’s important that you don’t put any sensitive things directly in you code (e.g. username, passwords) as they will easily be discovered. This might affect the design of your Android app.