Frameworks For Cross-Platform Mobile Development
As a company that develops iOS, Android, and Windows Phone applications, we are often asked to develop an application for two or three platforms. When this happens, some suggest using one of the frameworks for cross-platform mobile development. They believe it’s better than redeveloping the same functionality for each mobile platform. But are they right? Let’s find out.
The idea of cross-platform mobile development is really great and easy to market:
- You needn’t know the details of each mobile platform, nor the differences between them
- You needn’t learn different programming languages like Objective-C, Java, C#, etc. Simply use HTML, CSS and / or JavaScript
- You needn’t learn platform-specific APIs nor frameworks
- You save a lot of time by not redeveloping the functionality for each platform
- You save a lot of time while maintaining a single code base, instead of several
With so many advantages, why then are there far more native apps compared to cross-platform ones? To answer that, let’s review how these frameworks really function.
First, we’ll have to choose several frameworks; not a simple task. According to Wikipedia, there are 20+ frameworks for cross-platform mobile development. For our purposes, we chose only the most popular: PhoneGap, Appcelerator Titanium, Marmalade (formerly Airplay SDK), MoSync, and Sencha.
Web Based Solutions
Mobile platforms let developers use a web browser control (let’s call it webview). PhoneGap and Sencha packages web applications into native applications that use this webview control to render HTML pages as UI. HTML / CSS / JavaScript allows you to do this on webview as if it were a normal web page. For example, Sencha Touch draws web elements by using CSS and JavaScript as if they were native UI elements. So you get a mobile version of the website.
PhoneGap also lets JavaScript SDK access native device capabilities like GPS, camera, Accelerometer, microphone, contacts, etc.
- Does not look and feel the same as native controls, even when using JavaScript / CSS frameworks that were built for this (Sencha Touch, jQuery Mobile, etc.)
- Native application performance is superior to webview performance
- Native apps provide more detailed access to device capabilities (GPS, camera, etc).
- PhoneGap supports iOS, Android, Blackberry, Windows Phone, Palm WebOS, Bada, Symbian, and mobile web
- Great choice if you have an existing mobile site, want to create a similar app, and use some native device capabilities
- Plug-in architecture allows you to add your own native code as a plug-in to extend access to native device capabilities
- A lot of free plug-ins
Appcelerator Titanium
Titanium lets developers create native applications by writing JavaScript and using Titanium’s APIs. The resultant apps perform as if they were written with native SDKs. To achieve this, the application source code (Javascript) is interpreted at runtime and mapped to a native code to generate native UI components. The application’s UI then becomes completely native.
Compared to PhoneGap, there is no webview since the native Titanium APIs take control of all the UI needs. The obvious benefit here is performance. Native application elements will perform faster than when using HTML, CSS, and JavaScript in a browser instance.
Titanium also provides a platform-independent API to access native UI components. This includes navigation bars, menus, dialog boxes and alerts, as well as native device functionality, including the geolocation, accelerometer, file system, sound, local database, etc.
- To use the familiar JavaScript syntax, developers will also have to learn Titanium API, which is quite different from familiar web frameworks, like jQuery
- Program loading takes longer than it does for those developed with native SDKs, since interpreting the source code on the device needs to be done before the application starts.
- Only supports iOS, Android, and mobile web. This is because implementing the Titanium API on a new native platform requires a lot from the Titanium team.
- Implementation of the Titanium API for the Android platform is not very good – which is why almost half of the apps in the Titanium showcase are for iOS only. Need proof? compare the NBC app (the pride of the Titanium team) for iOS and Android. The iOS app works well and has a 4-star rating from users. Android users do not like this app at all, since it does not work for most of them (please read their comments), and app’s rating is 2 stars.
- The difficulty of implementing the Titanium API also caused a lot of bugs and issues, even for iOS. Their JIRA is full of bugs and feature requests.
- A mobile application with a truly native user experience
- Titanium provides almost native UI-performance (by using the native UI-components), while having a simple and powerful API that gives access to almost any interface that iOS or Android has.
- Appcelerator Cloud Services (ACS) provides a wide array of automatically scaled network features and data objects for your app. Tasks like push notifications, user logins, photo uploads, check ins, and status updates are done through one simple interface
Marmalade (formerly Airplay SDK)
Marmalade is a cross-platform SDK for the development of smartphone, tablet and Smart TV apps. It supports two separate development approaches:
- HTML5 / CSS3 / JavaScript apps: This is very similar to the web-based solutions described at the beginning of this article, where the apps use a cross-platform webview control. It’s even possible to port existing PhoneGap apps into Marmalade, because it supports PhoneGap API (for JavaScript access to device functionality). It’s also possible to use popular HTML / CSS / JavaScript libraries (jQuery Mobile, Sencha, Sproutcore, ExtJS, and more). The main advantage here is that you can develop, test, and deploy to all platforms from a single desktop and IDE.
- Fully native apps (C++): To code, the developer uses standard C++, OpenGL ES, and cross-platform Marmalade APIs, which abstract the native device APIs. C++ code is compiled right down to the CPU – no Virtual Machines or transcoding. So your app gets the maximum possible performance, delivering the best possible user experience. Great support for the C/C++ standard libraries, meaning that existing C/C++ can be ported very easily. CC++ developers can create code from scratch (using C/C++) OR port existing C/C++ code. They can also use their favorite modules / libraries, including STL, libxml, jsoncpp, and sqlite. Game developers can use box2D, Bullet, Lua, Cocos2D-x, and many more.
Access to native functionality is either provided already, or can be added using the extensions. The Marmalade Extensions Development Kit (EDK) allows developers to design their own extension APIs, then implement them on whatever OS platforms they choose, using each platform’s native SDK.
Marmalade also provides several options for User Interface:
- Skinned UI: A custom yet consistent look-and-feel across all devices
- Native UI: Cross-platform APIs which create native UI controls on iOS and Android
- HTML5, CSS3, and JavaScript UI: Web UI, using a cross-platform web view control
- Not free
- Marmalade is more suited to games development. It’s not easy to develop an app with native UI. We couldn’t find a single non-game app in their App Catalog (there are 63 games as of this writing)
- Marmalade provides an OS abstraction layer and unified tooling, meaning you can develop, test, and deploy to all platforms from a single desktop hardware environment and IDE (either Visual C++ or XCode) for both web and C++ solutions. So you don’t need to recompile your code for different platforms, nor do you need to switch IDEs or development hardware
- Delivers great performance for games and apps (C++ approach)
- Great choice for porting existing C/C++ code because of C/C++ standard libraries
- Supported Platforms: iOS, Android, BlackBerry PlayBook OS (BlackBerry Java platform is not supported), Bada, LG Smart TV
MoSync
MoSync enables mobile developers to build and compile apps for up to eight different platforms, using C/C++ or HTML5/JavaScript, or a combination of both, to create apps of different types, including:
- HTML5/JS WebUI app with the user interface in HTML/CSS, which looks the same on all platforms
- HTML5/JS NativeUI app with a native user interface, written in HTML/JavaScript (called Wormhole NativeUI JavaScript API), which accesses device functionality from JavaScript using the Wormhole Library
- HTML5/JS/C++ app is like the HTML5/JS WebUI app, but extending with code written in C/C++
- C++ app with a native user interface by using the Widget C API (a C-based API which uses the device’s native widgets, allowing you to create apps that are identical to the ones you create with the platform’s own SDK)
Perhaps the most interesting function is the building hybrid apps using HTML5 / JavaScript / CSS for UI and C/C++ to access device functionality not available in HTML5. So you can write the application logic in JavaScript or in C/C++ and use HTML and CSS for the user interface of the application.
- While a lot of the MoSync SDK comes with several useful standard C and C++ code libraries, you may need to extend MoSync in the future – but it is very difficult to compile even a simple C library
- Wormhole performance is not very good
- MoSync is available under an open source (GPL v2) license, a free “indie” license, and two commercial professional licenses
- Supported Platforms: iOS, Android, Windows Phone 7, BlackBerry, Symbian S60, Windows Mobile, Java ME, Moblin
- Five possible UI solutions based on target devices (smartphones or usual phones), as well as look-and-feel (native or the same on all platforms)
Native SDKs
Developing Android and iOS requires getting the respective SDKs. On iOS, this means learning Objective-C and Cocoa Touch. Android programming is similar to Java, but with Android-specific APIs and frameworks.
On the one hand, developing native apps gives you the most power over the platform, while spending less time having to learn intermediate libraries and tools (which could have bugs). But on the other, you need more native experts and time to develop each platform.
Should you choose the latter, you should probably deliver on one platform first to capture requirements, and to incorporate feedback on only one platform. This removes the need for duplicated (or more) efforts in the early stages of development.
iOS can be used as a lead platform, since statistics show that:
- iOS users use their devices more, and
- Purchase more from the Apple app store.
Android can also be used as a lead platform because the time to market is shorter, with no review phase when releasing to Google Play. Further, you get a more open platform which lets you cut corners during development. However it may require more time due to a big fragmentation of Android devices on the market.
When choosing a lead platform, your decision should be based on the strategic perspectives of each, your own strengths and the type of app you want to deliver, as well as the experience of the accessible developers. Fortunately, there is an abundance of information on the pros and cons of each.
- Requires learning different languages for different platforms
- The code base developed for one platform cannot be easily adapted for another. Usually, developing the native apps on multiple platforms requires multiple code bases. So more effort is required than with a single code base
- Requires more time. You end up spending as much time on the development of a new platform as you did on the lead
- The response time of the native UI is better than any cross-platform framework which tries to achieve native UI performance
- Native SDKs provide many ways to improve the performance and experience when using your apps (like multi-threading, explicit memory control, etc.)
- The native applications allow the full use of the device’s capabilities, which might be missing in some third party APIs. In theory, any API or third-party SDK is accessible through the extensions system. In practice, however, what you need may not yet exist. Consider the developers who are struggling to get the Flurry analytics package integrated. This is common with many third-party SDKs, mere lines when working with Objective-C, but potentially more difficult when working with lets say Marmalade.
- Users expect the same interface produced by native SDKs to avoid confusion, and to get a consistent experience with no platform integration problems.
Summary
No single app is trouble-free. Each has unique requirements and use of different tools, depending on the job needed. We can't really say that mobile frameworks have no future, some would say that one of them may eventually become bigger and even more popular than standard SDKs. Although most of them seems pretty raw at the moment, we do think they can be used for development of simple apps.
Our company still leans towards native SDKs as a more secure and predictable way of development. We decided to give cross-platform frameworks more time to get mature and get rid of early stage issues and bugs. It would also be interesting to know how other IT companies solve a question of developing a mobile app for multiple platforms.
P.S. Mark Zuckerberg, Facebook’s founder said that the “biggest mistake we made as a company was betting too much on HTML5 as opposed to native.” You can read that article by Christina Warren here. In it, Zuckerberg admitted that using HTML5 led to inferior performance, and that it took ten to twelve months before realizing they should have built it to run natively on systems like Apple iOS and Android.
Links
http://developer.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap.htmlhttp://webinos.org/crossplatformtools/marmalade/
http://webinos.org/crossplatformtools/mosync/
http://stackoverflow.com/a/7579647
http://www.mosync.com/documentation/manualpages/creating-user-interfaces-mosync
http://www.straightforward.se/storyserver/html5-javascript-mobile-apps-road-ahead
https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920
+380505528764
Comments
Thanks for taking time reading this article and filling the void in comments. I am glad you found it useful. We'll try to continue sharing our experience in this field.
If you are going to develop a server side app - don't forget to think what to show to users without coverage.
I recommend the PropertyCross project to anyone looking for more information about cross platform mobile client libraries and frameworks. They have compared a bunch of them by making the same sample app with each.
http://propertycross.com/