The pros and cons of common mobile platform development using HTML5.
Smartphones and tablets are here to stay and are becoming an increasingly important part of everyday life. They provide people with a fully functional device that can be used to run their lives. This, of course, leaves developers having to constantly ask which tools to use to create mobile applications that are fit for purpose and meet users’ demands.
Endorsement
The latest smartphones come equipped with intelligent and rich browsers that support HTML5.
Given that mobile applications are becoming the standard for interaction with many companies, much has been said lately about common platform development – ranging from the likes of PhoneGap (recently acquired by Adobe), to RhoMobile, AppCelerator, South Africa’s very own Ramp and many others. Some developers rave about them, some curse them, others are undecided.
Many of these frameworks are based on the richness of HTML5, a W3C specification that defines the fifth major revision of HTML. One of the major changes in HTML5 addresses Web applications, and other new features include specific functions for embedding graphics, audio, video and interactive documents.
Some developers are shaking their heads in disdain at the proposed change in development platforms to support HTML5, but one fact that cannot be disputed is that HTML5 is the foundation of the Web and many applications for the future. Those who refuse to accept this will be left behind. As an example, Microsoft Windows 8 has HTML5 embedded in the OS.
The latest smartphones come equipped with intelligent and rich browsers that support HTML5. This means the devices are capable and ready to use HTML5 in formats other than just the browser. While the standards surrounding HTML5 are still being debated, developers are already creating rich applications incorporating features like location services, offline storage, animation (through CSS3 or JavaScript), rich content, JSON feeds and more. In fact, the most common functions can be supported in HTML5 and used to control the basic features of a smartphone or tablet.
The upside is that powerful tools like PhoneGap can be used to provide a single platform to build one application and deploy it to many operating systems across a multitude of manufacturers. Add-ons like Sencha Touch can assist with the styling and differences between devices. The great thing about PhoneGap, as an example, is that it’s embedded into the development environment, allowing developers to access the native APIs if required, which means device-specific functionality remains available.
A common platform is most suitable when the mobile application is an add-on to an existing environment and not the primary, standalone application that drives the business. A good example of this is where a retailer or insurance company wishes to provide a rich client experience on a mobile device and use the basic functionality on its clients’ phones. Commands like “find a store near me” or “view my policy” are functions that don’t require high-performance processing and are quite comfortable running in a container application. This gives the business access to the generic features, while also enabling it to provide enough content and services to support clients. An added benefit is that a much smaller team is required to develop and support this.
But a common platform will not provide adequate performance for a highly graphic-intensive application or transaction-based system that uses some of the inbuilt hardware functions of the device. This means the developer may need to create many different versions of the same application on different operating systems. Potentially, they may have to hire a team made up of Objective C, Java and Microsoft developers, each maintaining a variety of versions and functions.
Common platform development has one major pro – “develop once, deploy to many”. Unfortunately, that comes at the cost of the “common denominator” of the devices. Using a common platform will provide accelerated development time, quick time to market, general rich functionality and lower cost of ownership, but a limited market segment where this can best be used.
At the end of the day, users of mobile applications will not know how the application was built. Their concern is whether it works, how smoothly it works, how processor- and memory-efficient it is, and whether it fits the look and feel of the device.
The term “fit for purpose” should be considered before any development is undertaken. But developers who don’t want to accept the popularity and relevance of common platform development will be at a distinct disadvantage when the client sees their quote and has to make a decision. Just think about how many applications are on phones right now that are using a common platform that users are not aware of.