If you pay much attention to the evolving trends in mobile development, you may have noticed a growing number of cross-platform frameworks becoming available lately. With tools like PhoneGap, Sencha Touch, Appcelerator Titanium, and Rhomobile (just to name a few), Sun Microsystems’ age-old banner of Write Once, Run Everywhere (WORE) has bled like a cheap red pen all over the mobile community, and I, for one, am not at all happy about it. Let me first say that there is one form of development that supersedes everything I’m about to say, which is game development. Developing games comes with its own set of development and user experience rules that cannot be otherwise applied to traditional app development, and so make it a bit of an exception.

When the choice is made to use a cross-platform framework to develop an application, it becomes clear that the development goal is not to make great software with a great experience, but instead of reduce development costs to the bare minimum. The choice is one that instantly limits what any version of the application can do in favor of only having to write the code one time. While some may argue the APIs they cannot use by not going native aren’t significant, the fact remains that they do exist and the core motive of the decision cannot be denied.

I have seen and been involved in many projects for clients over the years wishing to take a cross-platform app and split it into individual native apps in order to improve the user experience. I can honestly say I have never seen or heard of the reverse being true. In fact, I would challenge you to find an application beloved by the mobile user community that was created using such a framework. If you are able to find one, take note of just how difficult it was to seek out; adjectives like “compelling” and “award-winning” just don’t find themselves around applications made with cross-platform SDKs that often.

The fallacy of the WORE mentality in mobile is that it assumes user interfaces and experiences should be the same regardless of which platform you are running on. In mobile, this cannot be acceptable. Each mobile platform brings with it a unique set of expectations that its users have about how applications should work based on the types of navigation that the device uses. Developing an Android application using iOS navigation paradigms often results in very awkward user interactions, and the reverse is true as well.

I have seen many demos in the past from different framework providers showing how they made the buttons, tabs and lists use the native widgets from each platform so the app looks like it was designed natively! However, they all fail to realize that while the tabs were great for the iOS version, that really doesn’t make sense for Android, which would have been better served with a dashboard pattern; or that the list on an Android device isn’t supposed to have those little arrows on every item like iOS (are you starting to see a pattern for which UX the framework developers typically favor?). User experience paradigm is just as important, if not more so, than simply making the look and feel out of native widgets.

Don’t think that I’m not sympathetic, though, to people who don’t get excited at the thought of having to learn a new programming language in order to work with multiple platforms. I myself write code for several mobile platforms, and do so in the native language and SDK for each. I understand the time and cost investment that can take and that it isn’t for everyone. However, one does not need to jump onto one of these many passing cross-platform ships just to avoid this. There are a number of fantastic SDKs on the market now that allow developers to program applications in languages they are already familiar with, but still do so within the context of the respective SDK of each platform.

The Mono SDK is a great example of this; with MonoTouch for iOS, and more recently Mono for Android, developers can write native applications using the native SDKs for all three of the top mobile platforms using C# and .NET libraries. The word “cross-platform” does appear on the Mono site, but it does not refer to code that interacts with the core framework APIs of the platforms.

Another great example that was recently released is the RubyMotion SDK for iOS, which allows developers to use the Ruby programming languages to write native Cocoa Touch applications. I will say any day of the week that I believe going straight native is always a better alternative for both you and your clients or users, but I do believe these types of development tools to be a safe alternative that does not bring with it the same danger of harming the user experience of the final product.

For more on Android development, see “Breaking down Android.”

David is the lead engineer for mobile and embedded development at Xcellent Creations. Prior to that, he worked as an engineer developing embedded wireless monitoring and control systems for the industrial automation market. Today, his focus is on writing mobile applications that interface with custom hardware and accessories.