Hybrid Mobile Applications, Part 1

A mobile developer’s job is not an easy one. Ensuring their killer application is available to as many people on the planet as possible may mean developing four, five or possibly more versions of the application to enable it to run on the full variety of mobile platforms. Android and iOS dominate the market, but don’t forget about Windows Phone, BlackBerry 10 and Tizen. In some sectors and geographies, platforms with a smaller global market share have a disproportionately larger significance.

So it’s no surprise that developers, especially those who work for smaller companies or are a “one-person company,” are always on the lookout for tools and technologies that increase productivity and save work, time and money (not necessarily in that order!).

Hybrid Mobile Apps

Hybrid mobile applications is a specific category requiring a developer to write source code in a platform agnostic way and through some SDK magic, build and package it so the code will work on a range of different target platforms. That’s right. You develop one version of your application only but it will work on iOS, Android and if you really want it to, quite possibly Windows Phone and BlackBerry 10 too. On the face of it, this is precisely the alchemy that developers have been looking for.

But why “hybrid?” To understand this, we need to peek under the covers to find out how hybrid mobile apps work and how they achieve their cross-platform capability.

Native Applications vs. Web Applications

This is one of those topics to argue about at the pub…or café. Actually, the location doesn’t matter, it’s a fine topic for a good old debate anywhere, any time!

Platforms, mobile or otherwise, typically include a wide range of APIs which give application developers access to their features and capabilities, such as user interface components, persistent data storage, networking, GPS and of course, Bluetooth. Direct access to those APIs will be available via one or more programming languages. Android developers typically use Java and iOS developers most likely use Swift.

SDKs allow native app developers to build and package their application and then have it hosted in an app store for users to discover, download and install onto their devices. 

Web browser applications, on the other hand, are downloaded by the browser from a remote server whenever they are accessed by the user. They consist of a variety of “content” types which typically include HTML, CSS and JavaScript. The browser renders the HTML, applies the styling rules in the CSS and executes JavaScript functions as required. Web apps execute inside the browser’s “sandbox” and there are limits regarding how they can interact with the local device and its features. HTML5 and JavaScript are progressing all the time and there’s a great deal of power available to the web developer these days, but there are still limitations which the native application developer does not have to accept. There’s a degree of support for Bluetooth coming to the browser itself too (see the ‘Progressive Bluetooth Web Apps’ webinar here).

Application stores are a key element in today’s mobile platform ecosystems and one of the primary mechanisms by which developers make money from their apps. They’re designed for native applications which get downloaded from the store and installed on a device. Web applications, as I’ve described, cannot be hosted by an app store.

So, there are limitations regarding what you can do on a mobile device with web applications. One key limitation being you cannot have them hosted in an app store. That’s food for thought.

Where the web application developer can win hands down against the native application developer though, is that their applications are “cross-platform” applications. The application should be usable on any device with a sufficiently up-to-date browser on it, regardless of whether that device runs iOS, Android, Windows 10 and so on.

There are some shades of grey here and the stark distinction I’m making isn’t necessarily the whole story, but simply a way of positioning the two approaches. Allow me to elaborate.

Enter the Hybrid Mobile Application

This, as the name suggests, is a hybrid approach which attempts to give the application developer the best of both worlds. Hybrid mobile apps are developed using web technologies, so they’re cross-platform. They have access to native platform features like sensors and so on. They are installed on the mobile device, just like a native application, and can be hosted within one of the app stores.

So how do hybrid mobile apps work and what about Bluetooth^® support?

It’s All in the WebView

In the final analysis, hybrid mobile apps are a special type of native application, supported by an SDK which lets you “go cross-platform” and a series of APIs which usually get packaged in components often called “plug-ins.” The basic architecture of a hybrid mobile application is shown below, and as you can see, the secret sauce is something called a WebView component.

The WebView component is a native GUI component which can be included in an application’s user interface and its magical property is the ability to render web content, packaged locally or downloaded from a remote server. It’s like a mini, embeddable web browser which can render HTML, process CSS and execute JavaScript, all inside an otherwise standard native application. iOS, Android, and others have a component like this. It’s a multi-platform, architectural common denominator which the hybrid mobile approach exploits.

Writing Hybrid Mobile Apps

Hybrid mobile application developers only need to worry about authoring the HTML, CSS and JavaScript code which the WebView handles. Everything else is provided or generated by the hybrid mobile SDK for a specified target platform. You write your WebView HTML/CSS/JS content in a platform-independent way and then use the SDK to generate an installable application for each of the platforms you wish to support. You end up with an apk file for Android, an ipa for iOS and so on, each wrapping around the same web content that you wrote. Once…for each platform.

Hybrid Mobile SDKs

There are quite a few SDKs for hybrid mobile application developers to choose from. Apache Cordova is free and open source and it’s what I use if I decide to produce a hybrid mobile application. But there are other offerings too (some of them based on Apache Cordova as it happens). Adobe Phonegap is perhaps the best known but Ionic has a growing fan-base.

What about Bluetooth?

A fine question. Apache Cordova and Phonegap can use the same plugins and there are several Bluetooth^® plugins to choose from, spanning both GAP peripheral and GAP central capabilities.

In part 2, I’ll explore how you can create Bluetooth^® enabled applications that are cross-platform and can be published in app stores using Apache Cordova.