10 Best Practice for Hybrid Applications

Often times, I meet developers or companies that have written a hybrid application that to one degree or another has not been successful, and want to rewrite it natively. There are cases in which a rewrite is a good idea. Facebook, for instance, initially wrote its apps in HTML5, CSS, and JavaScript, but soon changed these out in favor of native apps. The reason was simple: hybrid apps didn’t have the performance needed to handle the volume of data and features that is everything Facebook.

But most people and companies aren’t Facebook, nor are they writing apps that have even close to the complexity of Facebooks apps. The reason that they are wanting to rewrite an in hybrid technologies probably stems from a bad decision point when building a hybrid application.  Like any app, there are a number of landmines one can step on when building a hybrid that can result in a poorly performing app or one that is just downright impossible to maintain.

By definition, a hybrid app is an desktop or mobile app that uses HTML5, CSS, and JavaScript for the majority of the app, but is supplemented by native components that can be called from the JavaScript to perform tasks on the device. This is different that a web app that doesn’t have any native components and a native app that doesn’t use web technologies.

When hybrid applications first came on the scene, they were met with great fanfare and web developers started making apps right away. A few years later, there are many bruises, apps both good and bad, and lessons learned. Out of this grew this list of best practices – partially out of necessity and partially out of lack of another good list.

General principles for successful applications:

  1. Build apps with a purpose, not just to have an app. One of the biggest motivations for writing a mobile app is driven by marketing — business want a presence in whatever application store that is provided by the platform, but the app itself does little or nothing in terms of business value. A company will use a hybrid app that is more or less portals used to load a business’ website.  Apps like this are generally rejected by the iOS App Store, and this approach really does not help a brand.
  2. Write apps to target multiple platforms. Perhaps the biggest motivation for writing hybrid applications is device portability. However, if an app is intended to target a single platform, there is little or no benefit from writing a hybrid application. Native applications in almost every case perform better and have a better user experience than hybrid applications.
  3. Choose a good platform. The platform doesn’t make the app, but it helps. It is the tool that enables the developer to write and deploy apps. Choosing a platform from the plethora of available platforms can be daunting, so here’s a few tips:
    • A good development platform should provide a way to bootstrap a hybrid app without tight integration with the platform itself. Usually, this is accomplished by simply pointing the webview to index.html page and the JavaScript in the app takes over. Some platforms are more intrusive to the HTML and JavaScript, so apps will have tighter coupling to the platform.
    • Avoid vendor lock-in. Hybrid applications by nature are highly portable and there is a plethora of tools available to build from. Vendor lock-in for this reason isn’t necessary. Do a thorough investigation of a platform, its licensing, and also how it says build applications. If applications require high reliance on a platform to run, odds are vendor lock in will occur.
    • Hybrid platforms should be extensible. Usually, a hybrid platform will have an API wherein a developer can write custom native code that can be used by an app. While this practice isn’t usually necessary and really should be used to avoid device lock-in, sometimes it is necessary.
    • As with any development platform, a good development platform should have good documentation and support. Good support doesn’t mean that one has to pay for it. Many popular platforms have excellent community support, ample and complete documentation, code samples, and tools for debugging to help developers understand and use the platform.
    • Look for a platform that receives updates regularly. Platforms from fly-by-night companies or indie developers run a high risk of abandonment. If the project is open source, look at the spans between commits and how many people are making commits. This can help gauge the viability of a platform. If the project is closed source, search online to see how popular a project is — does it have lots of plugins? Does it get a lot of attention on Stack Exchange? Are there lots of tutorials on YouTube? Are there lots of blogs posting about it? These more informal metrics can help gauge the viability of a platform in the same way looking at source code does.
    • Look for a platform that is mature. Start-ups projects are usually cool, but they don’t always translate into successful application platforms. Mature platforms usually gain a following with a vibrant community. Look at how many open problems a platform has and also how long it takes to resolve problems. More mature projects will have fewer problems and will rapidly close existing problems.

Two personal favorites are Cordova/PhoneGap and Intel’s XDK (which includes Cordova) as they meet all the aforementioned criteria.


  1. Don’t assume hybrid apps are the same as web apps. Hybrid apps use cross-platform web technologies, which is a selling point for adopting a hybrid application. But one of the biggest mistakes that developers make when writing hybrid apps is to assume that all the same rules that apply to web apps apply to hybrid apps. Hybrid apps, however are different: they don’t necessarily involve a web server, so developers cannot take advantage of architectures or frameworks that depend in the presence of a web server. A good rule of thumb is to assume that the application is going to be served off the device file system, so all references to JavaScript, CSS, and images need to assume this, as well as any references to off device code or resources that is used to render the UI. In fact, it is better to install these resources with the application, as this cuts down on the number of sever calls made to a server. Likewise, applications that use AJAX or XHR calls for UI components are likely to run into problems with CORS once an application is deployed if the app needs to use these to pull data off the local device.
  2. Write the apps as Single Page Apps (SPA). Single Page Applications load the resources they need when the app starts. Once the app is loaded, application states can be maintained in memory as with a traditional native application and without the overhead of needing to reload the page with each successive action. Navigating away from a page means that state has to somehow be handed off to the new page such a URL, post or through some sort of data persistence on the device, the re-read after the new page loads. Additionally, the app has to go through the compilation phase of the application all over again. This has detrimental effects on the applications performance and user experience alike.
  3. Be militant about Separation of Concerns (SOC). Separation of concerns is the software design principle that says any one module of an app should address only on specific concern. Architectural patterns like MVC separate concerns it to three areas — models that represent the data, controllers that respond to user input and update the model, and views that provide data and controls to the user. There are other patterns, but the idea that models shouldn’t care about what is happening on the view and vice versa, and the coupling between these should be low.JavaScript does not enforce separation of concerns by design, and in fact makes it extremely easy to violate it, while other languages and frameworks make it more difficult. For this reason, the responsibility falls to the developer to be militant about making sure an app doesn’t violate this principle. One way that helps is to not use global variables in an app and use a framework that implements Inversion of Control, so that dependencies are injected into the modules of the application rather than directly referenced. But there is no sure-fire way prevent a developer from violating SoC other than disciplined programming.
  4. Remain device agnostic to the degree possible. The greatest motivation for using hybrid application is portability, so it’s imperative to remain as device agnostic as possible to insure device agnosticism. Hybrid apps by design can take advantage of features of a device such as the camera, GPS, file system, and so on. Any device interaction however, should be abstracted away from the application and exposed through a wrapper around the device. Better yet, use inversion of control and dependency injection so that device specific functionality isn’t a hard dependency and can easily be swapped out between devices.


  1. Minimize JavaScript frameworks and plugins. One of the biggest performance killers of any web or hybrid application is the overuse of JavaScript frameworks and plugins. There are literally thousands of them, with new ones coming out every day. Select frameworks and plugins with extreme prejudice, and always look for lighter ways to do things rather than use large, often unwieldy frameworks that add little or no value an application.One popular combination is using AngularJS with Bootstrap. Bootstrap provides a clean UI framework built entirely in HTML5 and CSS, so it doesn’t depend on JavaScript to render UI components. This cuts down on the amount of JavaScript running on the device. Angular is a high performance, lean framework that provides a lot of functionality without the need to import tons of other libraries.
  2. Focus on usability and performance over pixel perfect design. Developers want their apps to look good, but apps don’t have to have pixel perfect design to do so. Usually, frameworks that attempt to mock-up native looking UI components in HTML, CSS, and JavaScript are heavy and highly intrusive, which can bloat an app. Simply avoiding the temptation to make an app pixel perfect will save tons of time in terms of performance and maintenance headaches.
  3. Learn to use responsive design effectively. Odds are, if an app is targeting multiple platform, it’s going to target iOS and Android. Both of these platforms have a broad range device formats — everything from 3.5 inch phones to 12 inch tablets. Designing an app that looks good on any screen takes time, but it is possible. HTML5 and CSS provide the tools need to make responsive apps, so if an app relies heavily on JavaScript to accomplish responsive views, the app will suffer in terms of performance.

1 comment on “10 Best Practice for Hybrid ApplicationsAdd yours →

Leave a Reply

Your email address will not be published. Required fields are marked *

ten + fifteen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.