Given the current proliferation of mobile touchpoints, we are often tasked with helping clients create mobile roadmaps and strategies. Inevitably, we are asked if there is a way to build content or functionality once and deploy it on a variety of different mobile platforms. The answer, of course, is yes. There are several ways, and the benefits of doing so vary from a more streamlined development process to higher adoption rates to lower costs. However, when is the right time to use a cross-platform solution? What kind of requirements lend themselves to this simpler approach? When is the cross-platform approach simpler than developing for native applications?
Mobile App Development – Native vs. Cross-Platform
In this post, I’m going to examine some of the existing technologies for cross-platform development of mobile apps, with an emphasis on determining when they might be appropriate for an app or business and when they might not.
What are the available cross-platform tools (CPTs)?
There are many—at least 100+—of these CPTs in today’s market, though we only typically hear of a few. Those with the most useful include:
Adobe PhoneGap
Sencha Touch
Mono
Appcelerator Titanium
Unity
Corona
AppMobi
RunRev
MoSync
The most prominent of the bunch and the ones I’m most familiar with are:
PhoneGap
PhoneGap uses HTML5 inside of a WebView on your device. It essentially creates a mobile “web app” that sits inside a native application wrapper. The web code is packaged with a library that bridges web code to native functionality. PhoneGap is open source (free) and supports iOS, Android, BlackBerry (not yet 10), WebOS, Windows Phone 7, Symbian, and Bada.
PhoneGap developers report advantages—such as a low barrier to entry (HTML/JavaScript/CSS is the only skill needed to get started), a single code base for all platforms, and rapid testing and deployment. Reported disadvantages include poor performance—there’s only so much you can get out of a WebView on any platform—and lack of support for native UI elements and widgets. Reports indicate graphically-intensive applications are not a good fit for PhoneGap.
Appcelerator Titanium
Titanium is similar to PhoneGap (it’s free), but not exactly the same. The main difference lies in device support—it’s built to produce iOS, Android, and web apps only. It compiles the JavaScript code into a native binary—converting the JavaScript into native class and object files—whereas PhoneGap simply renders a WebView with the code being interpreted inside.
“So, a simple way to think about it is that your JS code is compiled almost one-to-one into the representative symbols in your native land. There’s still an interpreter running in interpreted mode, otherwise, things like dynamic code wouldn’t work. However, it’s much faster, much more compact and it’s about as close to pure native mapping as you can get,” states Jeff Haynie, CEO of Appcelerator.
Proponents of Titanium argue performance is not an issue because the app is compiled as a native app. They say using native UI elements—as opposed to PhoneGap, which creates its own—allows apps to more closely resemble the look and feel of a native app. This is probably as close as you can get to having a CPT app resemble an actual native app.
Unity
Unity focuses on gaming on other graphically-intensive applications. It currently supports Windows, Mac, Unity Web Player, iOS, Android, Nintendo, Wii, PlayStation 3, and Xbox 360, with upcoming support for Adobe Flash Player, Linux, Windows 8, Windows Phone 8, and Nintendo Wii U. It is essentially the industry standard for game development.
Unity provides a development environment with which graphics, physics, and sound can be programmed. According to its Wikipedia article, “Game scripting comes via Mono. Scripting is built on Mono, the open-source implementation of the .NET framework. Programmers can use UnityScript (a custom language with ECMAScript-inspired syntax), C#, or Boo (which has a Python-inspired syntax).”
The downside of Unity is that it tends to be expensive by comparison particularly when you add in the cost of plug-ins used to build on multiple platforms. However, Unity is as close as you will see to an industry-standard, so clearly someone feels the cost is worth it.
When Considering a Cross-Platform Tool
Here are a few things to take into account when considering whether to use a CPT:
Design
There are design differences among mobile platforms—iPhone: the tabs go on the bottom, Android: the tabs are on top, Windows 8: everything scrolls horizontally. Custom icons are made at different sizes, and there are multiple screen resolutions and aspect ratios to consider as well as multiple screen densities and image sizes to account for. What if an app’s requirements include the need to perfectly fit an iPad screen right up to the edges, support the iPhone—including the retina and non-retina graphics—and must also fit perfectly on a Samsung Galaxy smartphone and tablet of varying sizes and ratios? The designer for that app needs to be skilled in both iPhone and Android design, and the designs could conceivably be different enough to warrant two completely separate code streams.
Technical Limitations—Playing “Catch Up”
Each cross-platform solution can logically only ever support a subset of the functionality included in each native platform. When new features come out, developers must wait until the CPT developers have a chance to incorporate them into the API. Without the control of being able to incorporate new capabilities as soon as they’re introduced into each native platform, you run the risk of major lost opportunity (e.g., being first to use a new feature is far more compelling than becoming a “me too” app). In addition, there’s a decent chance certain required functionality will require the development of “plug-ins” for each platform, which can become an unanticipated, costly, and time-consuming part of the project. The only surefire way to ensure an app is built within the appropriate, and most efficient, technological parameters is to build it natively.
Risk
What if Apple stops accepting PhoneGap apps? What if an app’s requirements change, and now PhoneGap or Titanium won’t work? How hard will it be to “port” the CPT code into a native app? These are all questions you need to ask to assess the risk associated with using any CPT before embarking on any project.
Further, you might hire a team of developers to create an app using a CPT; halfway through the project timeline, you may realize there’s a significant piece of functionality that requires native code or plug-ins—which you thought, due to the marketing materials, was supported by the tool you’re using. Now, you need to hire an iOS or Android expert to keep the project moving forward. The time spent hiring, designing, and coding around the issue could turn out to be very costly.
These are very real considerations. At the same time, the advantages of cost savings and time to market when using CPTs can also be very real. That’s why these decisions should not be made lightly.
Scenarios to Consider
What are some real-world examples of times when it might be appropriate to use CPT’s and which ones might be appropriate?
Online Store
A retailer of online widgets wishes to create a mobile app. They want to have a presence on as many platforms as possible—including iOS, Android, Windows Phone, and BlackBerry. The app is not deemed to be graphically intensive, and the initial design wireframes require a conventional mobile app layout. The design is similar—though responsive—whether viewed on a phone or a tablet.
This is the sort of app for which I would consider a platform such as PhoneGap or Titanium. The decision between the two would likely be based on the question, “Just how much do you want to support devices other than iOS and Android?” If the answer is “we want to support other device types,” then PhoneGap wins. Otherwise, the improved performance and “native” compiling of Titanium would win out.
Social Networking App with Lots of Cool Features
A fresh new startup wants to create a social networking app that incorporates location-based functionality, camera usage, some cool graphical animations, and sound interactions. The app should also be optimized for tablets where appropriate.
For this app, a careful approach must be taken. Location-based functionality is available in most CPTs, yet each OS truly has different ways of handling location accuracy and performance. Camera usage is included as a service in each CPT, yet if you want to bring advanced functionality—such as augmented reality or even take advantage of built-in editing features—the cross-platform approach might yield even more work than building separate versions.
Video Game—Two Scenarios
A mobile gaming company wants to make a video game for multiple mobile platforms. In one scenario, the company is small and doesn’t have a big budget for tools and software. It might be okay to use an open-source, free framework—like cocos-2d or cocos-3d—to build the app on one platform and then port it to the other. I have personally ported a game created with cocos-2d for iPhone in only three days. Since the code is so similar, a straight port isn’t that hard. The downside, of course, is multiple code streams in multiple languages, which essentially makes for multiple products.
In a second scenario, the company is large enough to spend on equipment. In this case, I’d recommend they invest in Unity, which I mentioned earlier is the industry standard for game creation on multiple platforms and seems to be the perfect tool for the task.
Conclusions and Recommendations
In conclusion, when considering whether to use a CPT instead of native mobile development, some important deciding factors include:
Platform requirements—which platforms must the app support and which platforms are considered “nice to haves”
Technology requirements—which mobile device features must the app support and which are “nice to haves”
Performance requirements—are there aspects of the conceptual apps where performance, especially graphical or computational, a consideration
Design constraints—how desperate are the designs for different device types
If these parameters fall squarely within the capabilities of a particular CPT, then consider yourself one of the lucky ones and use that CPT. Otherwise, in my opinion, making the case for being risk-averse and using proven technologies with which each platform natively ships seems the least scary solution for those about to invest time and money in creating a mobile experience.
