Why you should be considering hybrid mobile apps

If you’ve ever had any need to develop mobile apps, you’ll probably be aware of the choice between going native or web app. For those not aware, native apps are developed using the language and platform of the phone in question (Objective C for iPhone, Java for Android etc.). Web apps, on the other hand, run in the mobile browser of the device. Like all great techie debates, the reasons for choosing one or the other relate to performance, design and even philosophy. Not everyone, however, is aware of the existence of a third option — a hybrid of the two.

A hybrid app has the outward appearance of a native app. It can be found in the App Store, Android Marketplace or BlackBerry App World and it downloads and installs itself on your phone as expected. When you load it up, familiar user interface elements may appear, such as the iPhone’s title bar. However, the main content of the app is composed not from the widgets provided by the platform, but instead is presented by a browser embedded within the app. In effect, the app developer is using the mobile browser as a large widget, and the content is composed in HTML5 inside it.

Why would you want to do this? First off, cost. If you are targeting native apps for iPhone, Android, BlackBerry, Nokia etc., you will have to rewrite the app for each platform, increasing the cost of the project dramatically. Secondly, complexity. Not only is finding developers skilled in the different platforms hard, but managing each platform project (and ensuring you correctly share resources between them) is a significant challenge. Finally, updates. Updating your app in the App Store not only means Apple needs to approve it first (a process not known for its speed), it also means that your user will need to download the update and install it before it becomes available. This is very unlike the constantly updated web we have become accustomed to.

Since hybrid apps are in effect a type of native apps, all the phone features (such as geolocation and camera) are available to the developer. This is not (yet) the case for mobile web apps. In fact, hybrid app frameworks like PhoneGap make the phone’s features available inside the embedded web browser through their provided JavaScript APIs. The disadvantages (compared to a fully native app) are regularly quoted as performance and native appearance, but most content-driven apps do not have unusual demands in these areas. (If you are developing a game however, you may need to go native.)

So, who’s using hybrid apps already? A number of very significant companies, in fact. For example, did you know that the Facebook app (one of the most downloaded apps in the world) is a hybrid app? The Microsoft “Bing for Mobile” app, the Netflix app, the LinkedIn app, the Yelp app — all hybrids. In terms of tooling, Adobe recently acquired the creators of PhoneGap — a very significant move strategically considering they need to replace Flash on mobile devices. The creator of an HTML5 app distribution mechanism, Strobe, was recently hired by Facebook to work on its app strategy, which is clearly embracing hybrids.

As with all new “bridging” technologies, there are still rough edges in the hybrid approach, and plenty of poor looking and functioning apps to give the pundits reason for expressing concern. But it is very significant that some of the big tech companies that are not app store owners are backing hybrid apps — companies who certainly do have the resources to target different mobile platforms natively should they wish to. These decisions are taken with a long view on the future of HTML5 and the desire to not be tied to another company’s often slow or fickle distribution mechanism.

Taking this into account with the cost savings of developing for one platform rather than several, there’s a persuasive argument for hybrid apps. Consider also that web development is more common and costs less than native app development, a fact which becomes especially important when updates are needed and the relevant developer skills need to be found.

Clearly, fusing HTML5’s presentation to the power and distribution of native apps makes a lot of sense. So long as you are able to ensure that the performance and look of the app is similar to native apps for that platform, there are few credible reasons not to consider this approach for a cross-device mobile app project. And if your business isn’t making plans to reach the mobile generation yet, it probably should be.

Image: Daniel Y. Go