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 takes. Let’s look at the “wins” list, first. All these app characteristics can be re-used with little to no change:
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).
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:
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
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 takes. Let’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
DJ_Ksar
on:
The Deathly Hallows of Mobile Security
