Bean Blog

Many of our clients assume (rightfully so) that it’s easy to port an app from iPhone to Android. Sure, they’re all touchscreen smartphones, but in fact, the process presents a bevy of challenges.

Although there are similar challenges in developing for both platforms, such as memory management, they work in fundamentally different ways.

Beaner Andrew Metcalf has some great advice and caveats to share. Ready to geek out and talk some code? Let’s go!

The biggest hurdle in porting is the programming language. iOS mainly uses the Cocoa library, written in Objective C, while Android’s SDK uses Java. These languages are dissimilar enough that porting from one to the other involves completely rewriting all of the code. Often, tasks are accomplished using a completely different method on the two platforms.

Of course, there are certain benefits to both platforms. One common complaint about Objective C is that it requires the developer to manage their memory manually, whereas Java’s garbage collector takes care of memory management as long as you write code without memory leaks.

We use many graphical objects in our apps for iPhone, such as UIImageView, to control our graphics and animations with a convenient level of abstraction. On the Android, however, the View object doesn’t provide an easy way to specify the object’s absolute position — an absolute positioning layout exists, but it is deprecated due to Android’s focus on developing for multiple screen sizes.

While we originally wrote our own layout manager meant to achieve the same functionality, we ultimately opted to use the low level drawing API to directly draw our images to the screen. This allowed for precise control of positioning and animation, but required a great deal more code.

In particular, Animations required us to manage at least two objects, and typically a few additional fields. The synchronization required to scale and move an object simultaneously, for example, can be quite challenging. In the end, however, we managed to make it work with acceptable performance.

From the start, multitasking has been an integral part of the Android platform, and it shows in the API. Android phones prefer that developers split their apps up into multiple Activities. An activity generally has a specific function, and ideally a single basic View. A view is the basic graphics container in Android — every activity has one main view.

Having multiple activities allows Android to stop and restart any activity not currently visible to the user in the event that some other background process needs more memory. Due to the limited hardware in smartphones, Android will stop non-visible actives quite frequently, so all of your activities need to be able to handle being stopped and restarted.

In the game app we’re currently porting to Android, we originally wanted to develop the whole application in a single activity, allowing us to avoid the complications associated with the activity lifecycle. We planned to simply switch the view of the main activity depending on what portion of the game the user is playing. However, this approach didn’t play nicely with Android, so we instead divided up the application into different core activities based on the natural breaks in the game experience.

Screen size and resolution are also an important consideration when porting an app. Unlike iPhone, Android OS is designed to run on a large variety of devices sporting many different screen sizes. As of this writing, over 40 devices run Android’s OS. Although there are a few more popular sizes (320×480 was common on older phones, and many newer ones support 480×800), there is no defined screen resolution for Android devices. In fact, there isn’t even a defined screen aspect ratio – the Droid series of phones sports a resolution of 480×854, straying from the common 3:2 ratio.

To make these screen sizes a little easier for developers to deal with, Android can automatically scale your application to fill the screen. It won’t distort it, though, so you will still have some black space on the edges of the Droid’s screen. We worked around this issue by polling the system for the screen resolution — if it doesn’t match a 3:2 ratio, we can at least center our application on the screen. 

Since we have the same game on iPhone and iPad, we originally considered using our iPad assets since they have a higher resolution. We conducted testing using iPhone assets and determined that even on a high resolution screen, they looked fine. This was a great result, since we were able to keep overall size down by using the smaller iPhone assets.

Ultimately, the final app we ported on the Android is a completely different application from our iPhone/iPad version. 

Although the user experience is virtually the same, the difference in the code is extreme. Unfortunately, this means that any future changes to one version of the app will have to be done differently in the other version.

Ideally there would be a cross platform solution, but Apple has made it clear that they do not support the idea. So it looks like there’s no end in sight for this development challenge.

Photo courtesy of suvodeb