There are some wrapper applications such as Cordova that provide the ability to package your solution as a mobile App for different platforms, and standardize the way you reach a limited number of native device features such as the GPS and camera.
HTML 5 has begun to provide access to data storage facilities which can even enable basic offline functionality in an app.
We have been using these technologies for mobile app prototyping for several years now, but have always found stress points when delivering production quality applications.
The first stress point is in unexpected variance in rendering behaviour of the different mobile browsers. Even between different versions of the Webkit mobile browser used in many mobile devices; this version of Android would do this and that version of Android would do that.
The third stress point is in accessing native device features. Mobile users tend to be quite attached to their devices, and are sensitive to applications that do not behave the way their native apps behave. This means developing apps that hook into device specific features such as the Blackberry thumb wheel, the Android context menu, or the Apple gestures.
Work and research progresses along each of these areas, but our customers want stable cross platform applications today.
Taking a different approach, each platform’s development ecosystem is also evolving, each in their own divergent direction. Individually, these development environments provide emphasis on each platform’s unique features, allowing natural and comfortable access to building applications that match those platform users’ expectations. Code your iOS apps in XCode, your Blackberry apps in the Blackberry SDK, and your Android apps using the Android SDK. This means happier more satisfied users, and higher app store ratings.
Since each platform provides their own development environment and programming language in an attempt to simplify the construction of applications, it seems there is little choice but to hire a team per platform to build your app. Ultimately this seems to multiply your costs by the number of platforms you wish to support, or leave certain types of users out in the cold.
However, if you dig enough, every platform has a foundation and programming environment in common. C++ and the posix core has enabled key technology reuse across platforms, much stemming from the open source communities. SQLite is a perfect example of such a technology, used as a foundation on many platforms, and used by developers across all.
So, in rethinking the problem of cross platform mobile development, we can take long proven technologies, a well understood programming language, and assemble business logic, data persistence, and server communication in a single place and re-use that across any popular mobile, embedded or desktop platform (they all have native development kits that support C++).
This breaks up development into a business level service API provided by a single common C++ project, and much thinner, lighter and less expensive platform-specific projects.
There are many benefits to this approach beyond just reducing your per-platform costs. There is also the benefit of having your business level logic implemented and tested all in one place. You no longer have to chase platform specific business logic violations across all of your implementations.