Peter_vdL

Porting from iOS to Android

by Peter_vdL Motorola on 01-04-2012 07:26 PM

No question about it; we’re at a fascinating place in the smartphone industry right now.  Consumers have overwhelmingly embraced smartphones as their connection technology of choice.  The coming big wave is mobilizing the enterprise (meaning “updating enterprise systems to support mobile device access”), which will be done through the consumerization of IT (meaning “supporting people who want to use their consumer smartphones in their working environment”.  Consumerization of IT also involves engaging with social networks, wikis, video, cloud services, etc).

An entire new market segment has opened up, as IT managers clamor for attention, help, and enterprise apps.  App developers are working overtime to meet the demand for apps in the workspace.  One quick way to address demand is to port your existing workplace apps from other platforms, to Android which is the new high volume platform among all smartphones.  This blog post examines what’s involved in moving a typical app from Apple iOS over to Android.

The more you can re-use, the less effort porting takesLet’s look at the “wins” list, first.  All these app characteristics can be re-used with little to no change:
  • the concept of the app, its design, and the flow between screens
  • maybe some SQLite database code, although you have to work hard to get to the raw SQLite deployed on the iPhone (it’s accessed through an abstraction layer)
  • some of the drawable resources (images and icons), but these will need to be reworked for new sizes and dpi.
  • media files (sounds, video, photos, html, etc)
  • any native C, C++ libraries (such as a game engine)
  • some of the OpenGL code, if the app uses any

Android supports many more screen sizes and densities than iOS, so you’ll need additional drawables.  Some of these you may be able to create yourself by using ninepatch drawables (stretchable bitmap images, frequently used as the background of buttons because they adjust gracefully to size changes).

  Fig. 1: The other kind of port,

sunset under the Bay Bridge at the Port of Oakland, California


What about the source code?
The previous section listed all the “wins”.   Now we come to the source code, which is less winning.  Most iOS apps are written in Objective-C, with the UI laid out in NIB files.  Android apps are written in Java, with the UI laid out in XML.  Objective-C and NIB files are not supported on Android, and there are no reports of satisfactory translators. So you cannot directly re-use your iOS source code.  Maybe it’s time to evaluate whether a rewrite in HTML5 can give your app a single code base for mobile platforms.

You can and should re-use the design and algorithms, the screen flow, and the code flow.  There’s an excellent blogpost by Nick Farina, describing his experiences porting from iOS to Android. He points out that layouts in Android are simpler than layouts in iOS (where you specify spacing in pixels, and every screen size and widget is an individual special case!)  Nick also demonstrates significant code similarities in some parts of the code.    And take a look at the experiences of Jim Buzbee, who ported and expanded a simple iOS app.

Porting to Android definitely involves a rewrite of the Apple app code.  The effort that it took to write the iOS app, is the upper bound on the effort it will take to get it ported to Android.  But you won’t have to re-incur the cost of design and screen flow - a potentially significant saving over the original app.  If the programmers who wrote the original code can do the port, expect a time-saving there, too.

The Bottom Line
Wikipedia says "Software is portable when the cost of porting it to a new platform is less than the cost of writing it from scratch. The lower the cost of porting software, relative to its implementation cost, the more portable it is said to be."

In general, it takes less effort to port an iPhone app to Android, than it did to write the app originally.  How much less depends on the app.  Expect to reuse the app concept, design, flow, assets, resources, and maybe SQLite code.  Port to the high volume smartphone (Android) because it’s cheaper than writing a new app.  For third party developers, it yields a second monetization stream from an app you already have.  For in-house IT staff, it extends mobile support to the largest and fastest growing smartphone platform.  Plus, you can add a line on your status report and your resume, saying you:
  • ported app enabling the consumerization of IT, and totally mobilized the Enterprise.


After you’ve added that line, be my guest and follow up with a comment about your own porting experiences.  Or let us know about the kinds of apps you’d like to see ported, or about porting services/tools that would help you.  The MOTODEV team would love to hear your thoughts on the topic.

Peter van der Linden
Android Technology Evangelist

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
reCAPTCHA challenge image
Type the characters you see in the picture above.Type the words you hear.
MOTODEV for Enterprise
Welcome...

Comment on our blog and tell us how we can help you build and distribute enterprise mobile applications on Motorola devices.

Subscribe to our RSS feed Subscribe via RSS

Follow Us

Our Blog & Comment Policy
Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Motorola. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Motorola or any other party.

Remember, when you comment, please stay on topic and avoid spam, profanity, and anything else that violates our user guidelines. All comments require approval by Motorola and can be rejected for any reason.

For customer support issues with your Motorola phone go to the Motorola customer support website.
Blogroll