By Andrey Butov
When a new client approaches me with a project where the application needs to run on iOS and Android, the inevitable question comes up regarding whether it’s better to implement the application in native code, or to use a platform-abstraction wrapper such as PhoneGap or Appcelerator Titanium.
A discussion follows, and while the decision always takes into account what is best for the client and for the project, to date, every one of my clients has chosen to go with a native-code implementation for the project.
Indeed, for my own work at Antair, we tend to favor a native implementation for each new product, even though we know, from the start, that the product will be ported to several platforms.
[I] — If you’re going to go with an abstraction layer, you will still need to deal with platform-specific idiosyncrasies. In practice, there’s just no way around this for all but the most trivial of applications. But instead of dealing with one platform at a time, you will be balancing multiple platform details at once. This administrivia will eat up a lot of the time you had expected to save by not having to port a native application to other platforms down the road.
[III] — I am experienced in porting existing iOS applications to Android, while retaining the flow and design of the original. It usually takes significantly less time to port an iOS application to Android than people assume, and certainly less time than it took to implement the original.
[IV] — There are inherent limitations to these abstraction layers. For example, if an application needs to interact with the phone system on the device, or with some other device-specific component, it remains to be seen to what extent this feature is available through the abstraction layer that you are using. From what I understand, Titanium compiles down to native code, so it may allow for more of this type of work, but I’m not sure about PhoneGap.
[V] — Last I heard, there were stability issues with some of these abstraction layers with regard to Android. It’s natural that, even with abstraction code, some platforms are favored over others. I can’t confirm this, as I’ve never been convinced enough by either framework to use them in my own products.
[VI] — Finally, and most important, is the issue of dependency. Dependencies are evil. By going with an abstraction framework, and having them change something fundamental, because they changed their underlying business strategy, means that when your client comes to you later on and requests a feature update, or a bug fix, you are risking telling them that they need a complete rewrite of the application, because the original implementation technology is no longer viable.