Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Hybrid Mobile Apps: Providing A Native Experience With Web Technologies

According to a recent report1, HTML is the most widely used language for mobile app developers. The main reasons among developers for selecting web technologies2 are cross-platform portability of code and the low cost of development. We’ve also heard that hybrid apps tend to be sluggish and poorly designed. Let’s prove whether it’s possible to deliver the native look and feel that we’re used to.

HTML can do that.

This article provides many hints, code snippets and lessons learned on how to build great hybrid mobile apps. I’ll briefly introduce hybrid mobile app development, including its benefits and drawbacks. Then, I’ll share lessons I’ve learned from over two years of developing Hojoki and CatchApp, both of which run natively on major mobile platforms and were built with HTML, CSS and JavaScript. Finally, we’ll review the most prominent tools to wrap code in a native app.

What Are Hybrid Mobile Apps? Link

Mobile apps can be generally broken down into native, hybrid and web apps. Going the native route allows you to use all of the capabilities of a device and operating system, with a minimum of performance overhead on a given platform. However, building a web app allows your code to be ported across platforms, which can dramatically reduce development time and cost. Hybrid apps combine the best of both worlds, using a common code base to deploy native-like apps to a wide range of platforms.

There are two approaches to building a hybrid app:

  • WebView app
    The HTML, CSS and JavaScript code base runs in an internal browser (called WebView) that is wrapped in a native app. Some native APIs are exposed to JavaScript through this wrapper. Examples are Adobe PhoneGap3 and Trigger.io4.
  • Compiled hybrid app
    The code is written in one language (such as C# or JavaScript) and gets compiled to native code for each supported platform. The result is a native app for each platform, but less freedom during development. Examples are Xamarin5, Appcelerator Titanium6 and Embarcadero FireMonkey7.

While both approaches are widely used and exist for good reasons, we’ll focus on WebView apps because they enable developers to leverage most of their existing web skills. Let’s look at all of the benefits and drawbacks of hybrid apps compared to both native and mobile web apps.

Benefits Link

  • Developer can use existing web skills
  • One code base for multiple platforms
  • Reduced development time and cost
  • Easily design for various form factors (including tablets) using responsive web design
  • Access to some device and operating system features
  • Advanced offline capabilities
  • Increased visibility because the app can be distributed natively (via app stores) and to mobile browsers (via search engines)

Drawbacks Link

  • Performance issues for certain types of apps (ones relying on complex native functionality or heavy transitions, such as 3D games)
  • Increased time and effort required to mimic a native UI and feel
  • Not all device and operating system features supported
  • Risk of being rejected by Apple if app does not feel native enough (for example, a simple website)

These drawbacks are significant and cannot be ignored, and they show that the hybrid approach does not suit all kinds of apps. You’ll need to carefully evaluate your target users, their platforms of choice and the app’s requirements. In the case of many apps, such as content-driven ones, the benefits outweigh the drawbacks. Such apps can typically be found in the “Business and Productivity,” “Enterprise” and “Media” categories in the app store.

Both Hojoki and CatchApp are very content-driven productivity apps, so we initially thought they would be a great match for hybrid development. The first three benefits mentioned above were especially helpful to us in building the mobile app for Hojoki in just four weeks. Obviously, that first version lacked many important things. The following weeks and months were filled with work on optimizing performance, crafting a custom UI for each platform and exploiting the advanced capabilities of different devices. The learning in that time was crucial to making the app look and feel native. I’ll share as many lessons as possible below.

So, how do you achieve a native look and feel? To a mobile web developer, being able to use the features of a device and operating system and being able to package their app for an app store sounds just awesome. However, if users are to believe it is a native app, then it will have to behave and look like one. Accomplishing this remains one of the biggest challenges for hybrid mobile developers.

Make Your Users Feel at Home Link

A single code base doesn’t mean that the app should look and feel exactly the same on all platforms. Your users will not care at all about the underlying cross-platform technology. They just want the app to behave as expected; they want to feel “at home.” Your first stop should be each platform’s design guidelines:

While these guidelines might not perfectly suit all kinds of apps, they still provide a comprehensive and standard set of interfaces and experiences that users on each platform will know and expect.

DIY vs. UI Frameworks Link

Implementing all of these components, patterns and animations on your own can be quite a challenge. All kinds of frameworks exist to help you with that, ranging from commercial (Kendo UI11) to open-source ones (Ionic12) and from ones with a common UI (jQuery Mobile13 and Onsen UI14) to many platform-specific UIs (Sencha Touch7615 and ChocolateChip-UI16). Some are really good at providing a pixel-perfect layout, while others are rather sloppy, thus making it easy for the user to identify a web app. However, my impression is that their main drawbacks are performance-related, because most UI frameworks try to be as all-embracing as possible. Judge for yourself by taking a few minutes to try the demos on your own device.

At Hojoki, we try to craft all components on our own using CSS3 and minimal JavaScript. This keeps us in control of performance and reduces overhead. We obviously use small libraries for complicated tasks that someone else has solved just fine.

Custom UI Components Link

Custom UI components also have many good use cases. Deciding between a platform’s UI and a custom UI will obviously depend on your target audience. If you want to do your own thing, you should have a deep understanding of UX design, because the guidelines linked to above were crafted by experts to meet the particular requirements of their platform’s users.

Whether you stick to a platform’s UI guidelines or do your own thing with custom components, know that there are certain design patterns that most people use every day and love. How are people usually introduced to a new app? Through a slideshow walkthrough or an instructional overlay. How do people navigate? With a tab bar or a sidebar drawer17. How do users quickly load or refresh data? By pulling to refresh. (Native-like scrolling will be covered extensively further below.)

Resources for Mobile UI Design Link

Design A Native-Looking Header Bar Link

One important part of a UI is the header bar, with its title and navigation elements, most notably the “up” and “back” buttons. To me, many popular frameworks fail to provide a HTML and CSS solution that compares to a native app. Mimicking this part of the UI with a minimal DOM and a few lines of CSS for each platform is actually fairly easy:

   <button class="back">Feed</button>
   <!-- more actions (e.g. a search button on the right side) -->

Check out the full code of the native-looking header bar for iOS, Android and Windows Phone21 on JSFiddle. This is my result:

Native-looking headers made with HTML5 and CSS.
Native-looking headers made with HTML5 and CSS.

Using the same DOM across all platforms is generally preferable because it results in cleaner code and, therefore, maximizes maintainability. I’ve found this to be easily possible for many UI components on iOS and Android (including the header bar, tab bar, custom navigation menu, settings page, popover and many more). However, this becomes much harder when adding support for Windows Phone, which comes with some very different design patterns.

Support High-Resolution Screens Link

Nowadays, smartphones and tablets with high-resolution screens make up the vast majority of mobile devices, making up more than 80% of iOS devices22 and over 70% on Android devices23. To make your images look crisp for everyone, you usually have to deliver twice the dimensions than what is actually shown in your app. Serving properly sized images for all different resolutions is one of the most discussed topics in responsive web design. There are various approaches, each with its benefits and drawbacks related to bandwidth, code maintainability and browser support. Let’s quickly review the most popular ones, in no particular order:

  • server-side resizing and delivering
  • client-side detection and replacement via JavaScript
  • HTML5 picture element
  • HTML5 srcset attribute
  • CSS image-set
  • CSS media queries
  • Resolution-independent images (SVG)

As always, there is no silver bullet for responsive images. It pretty much depends on the type of images and how they are used in the app. For static images (such as the logo and tutorial images), I try to use SVG. They scale perfectly without any extra effort and have great browser support as long as you’re fine with Android 3+24.

When SVG is not an option, the HTML5 picture element and srcset attributes25 are definitely where front-end development is heading. Currently, their main drawback is the very limited browser support and, therefore, their need for polyfills.

In the meantime, CSS background images and media queries26 are the most pragmatic solution:

/* Normal-resolution CSS */
.logo {
   width: 120px;
   background: url(logo.png) no-repeat 0 0;

/* HD and Retina CSS */
only screen and (-webkit-min-device-pixel-ratio: 1.25),
only screen and ( min--moz-device-pixel-ratio: 1.25),
only screen and ( -o-min-device-pixel-ratio: 1.25/1),
only screen and ( min-device-pixel-ratio: 1.25),
only screen and ( min-resolution: 200dpi),
only screen and ( min-resolution: 1.25dppx) {
	.logo {
      background: url(logo@2x.png) no-repeat 0 0;
      background-size: 120px; /* Equal to normal logo width */

However, your app might already contain a lot of content (such as news articles), and adjusting all of the img tags or replacing them with CSS would be exhausting. A server-side solution is the best choice in this case.

Starting last year, more and more Android manufacturers have gone one step further with what is called XXHDPI (or very very high-resolution) screens. Whichever solution above fits your need, keep in mind that you’ll need images that are three times the original dimensions to support Android’s latest flagship devices.

Use System Fonts Link

A simple yet important way to make users feel at home is to use system fonts.

Native fonts for iOS, Android and Windows Phone.
Native fonts for iOS27, Android28 and Windows Phone29.

These are my recommended font stacks on the major platforms:

/* iOS */
font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;

/* Android */
font-family: 'RobotoRegular', 'Droid Sans', sans-serif;

/* Windows Phone */
font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;

Furthermore, iOS 7 offers some interesting presets that automatically set the correct font family, font size and line height. It’s as easy as using font: -apple-system-body for normal text and font: -apple-system-headline for headings. This not only simplifies font declarations, but also improves accessibility through “dynamic type30,” Apple’s system-wide font-size setting. You can dig deeper into iOS 7 font presets in a post by Thomas Fuchs31.

An Icon Is Worth A Thousand Words Link

Iconography is an important part of the user experience on all major mobile platforms. As with fonts, you’re usually best off using icons that your target audience already knows. Recalling what I said about high-resolution screens earlier, make sure that your icons are scaleable. Implementing them as a font via CSS’ @font-face rule is a great way to achieve this, and it comes with wide browser support32. It even allows you to change an icon’s appearance (for example, its color, shadow and transparency) seamlessly via CSS. Here are my recommendations:

  1. Get various platform icon fonts.
    Ionicons33 is our baseline set because it includes nearly everything we need. This includes specific icons for iOS and Android in addition to their general ones. The rest come from specific platform icon fonts for iOS34, Android set 135 and set 236 and Windows Phone37.
  2. Combine them with a icon font generator.
    Using multiple icon fonts is confusing and quickly adds up in size. That is why we use Fontello38 to combine the different sets, adjust key codes and export them for each platform. The result is <span class="icon">s</span>, which looks like a search icon on iOS, Android and Windows Phone. Also, check out the popular alternatives IcoMoon39 and Fontastic40.

On Windows Phone, you can also get away with the native font-family: 'Segoe UI Symbol'41.

Optimize For Performance Link

Performance is usually considered to be one of the major disadvantages of a hybrid mobile app. This is mostly true if your app has a lot of heavy animations, contains huge scrolling lists and needs to run on old devices. However, if you are all right with supporting only newer platform versions (Android 4+, iOS 7+ and Windows Phone 8+), then you’ll very likely have satisfying results. It’s ultimately a question of how much effort you put into optimizing DOM and CSS selectors, writing performant JavaScript, reducing rendering time and minimizing the number of reflows and repaints. An endless number of articles and tutorials cover mobile web performance. These are some of my favorites:

Beyond that, mobile hardware and rendering engines are improving at a rapid pace, with new devices coming out every other day. Developers can make the performance of a hybrid WebView app difficult to distinguish from that of a fully native app on the iPhone 5 series and on Android phones comparable to Nexus 4 and 5.

Increase Perceived Speed Link

Building a performant app is one thing, but making it feel fast is a whole other. Whether your app needs some time for a certain task (such as some heavy calculation or client-server communication), presenting instant feedback is crucial to providing a fluid and responsive experience. A common technique is to delay tasks that the user doesn’t need yet, while predicting and preloading the steps the user might take next. A famous example is Instagram, which uploads photos in the background47 while the user is busy adding tags and sharing. Perceived speed can be very different from actual speed, so let’s use it in our favor. Here are some no-brainers.

Remove the Click Delay on Touch Devices Link

A normal JavaScript click event handler on a touch device comes with a slight delay between the touchstart and the click being fired (usually around 300 milliseconds). This feature is built into the browser to detect whether the user is performing a single- or double-tap. If you don’t need the “double-tap to zoom” feature, you can safely eliminate these 300 milliseconds to get a much more responsive tap behavior. My favorite solution for this is the FastClick48 library. Use it on everything except Internet Explorer:

if ('ontouchstart' in window) {
   window.addEventListener('load', function() {
   }, false);

Internet Explorer 10+ is a bit easier. You just need some CSS:

html {
   -ms-touch-action: manipulation; /* IE 10  */
       touch-action: manipulation; /* IE 11+ */

Style the Active State Link

As soon as the user taps an actionable element such as a button or a link, they should immediately get some kind of feedback that the app has detected their action. While the CSS pseudo-class :hover works great for this on the desktop, you need to switch to :active or a JavaScript solution for it to work on mobile. I’ve compared the three approaches to the active state49 on JSFiddle. While they all work one way or another, you judge which is best for you.

Furthermore, remove the default tap highlight while adjusting your active states on mobile. I’d also recommend disabling user selections on actionable elements, because the selection menu would be quite disruptive if the user accidentally taps the button for too long.

iOS and Android:

button {
   outline: 0;
   -webkit-tap-highlight-color: rgba(0,0,0,0);
   -webkit-tap-highlight-color: transparent;
   -webkit-touch-callout: none;
   -webkit-user-select: none;
      -moz-user-select: none;
       -ms-user-select: none;
           user-select: none;

Windows Phone 8+:

<meta name="msapplication-tap-highlight" content="no">

Indicate Loading Link

Whenever your app is performing an action that will take some time to finish, even just for a second, consider adding a loading indicator. If you don’t, users will think that your app freezes occasionally, or they’ll click around when they shouldn’t, or they might even break things and then blame your app. From what I’ve experienced, animated GIFs are usually a bad idea in mobile browsers. As soon as there is a load on the CPU, the GIF freezes, thus defeating its entire purpose. I prefer Spin.js50 for its configurability and ease of use. Also, check out some other JavaScript solutions51 and CSS loaders52.

Cross-platform tools like PhoneGap and also provide access to native loaders, which is great for showing a full-screen loading animation.

Get the Scrolling Right Link

Scrolling is one of the most important factors in the user experience of many apps. This is both a curse and a blessing because the success of its implementation will depend heavily on the scrolling niceties that your app relies on and on the mobile operating systems that need to be supported.

Scrollable content and a fixed header and/or footer bar are common to nearly all apps. There are two common approaches to achieving this with CSS:

  1. Enabling scrolling on the body, and applying position: fixed to the header;
  2. Disabling scrolling on the body, and applying overflow: scroll to the content;
  3. Disabling scrolling on the body, and applying JavaScript custom scrolling to the content.

While the first option has some benefits (such as iOS’s native scroll-to-top action and a simple code structure), I highly recommend going with the second option, overflow: scroll. It has fewer rendering issues53 (although still a lot), and browser support is great on modern platforms (Android 4+, iOS 5+ and Windows Phone 8+), with a nice little polyfill for some older ones54. Alternatively, you could replace overflow: scroll with a custom scrolling library (the third option), such as iScroll55. While these JavaScript solutions allow for more flexibility with features (for example, the scroll position during momentum, event handling, customization of effects and scrollbars, etc.), they always penalize performance. This becomes critical when you’re using a lot of DOM nodes and/or CSS3 effects (such as box-shadow, text-shadow, opacity and rgba) in the content area.

Let’s look at some of the basic scrolling features.

Momentum Effect Link

The touch-friendly momentum effect enables users to quickly scroll through large content areas in an intuitive way. It can be easily activated with some simple CSS on iOS 5+ and in some versions of Chrome for Android. On iOS, this will also enable the content to bounce off the top and bottom edges.

overflow-y: scroll;
-webkit-overflow-scrolling: touch;

Pull Down to Refresh Link

Various solution for this are available on the web, such as the one by Damien Antipa5756. While the solutions for iOS and Windows Phone have a similar look and feel, Android recently introduced its own mechanism (see below). We’ve implemented this in CatchApp using some JavaScript and CSS keyframes. (I have yet to wrap it up nicely and put it on GitHub, so stay tuned!)

Pull down to refresh on iOS
Pull down to refresh on iOS. (Image credit: Damien Antipa5756)
Pull down to refresh on Android.
Pull down to refresh on Android. (Image credit: Android Widget Center58)
Pull down to refresh on Windows Phone.
Pull down to refresh on Windows Phone. (Image credit: David Washington59)

Scroll to Top Link

Unfortunately, disabling scrolling on the body will also break iOS’ native feature that enables users to quickly get to the top of the page by tapping the status bar. I’ve written a small script that can be added to any element and that takes care of scrolling to the top using JavaScript60, even if the content is currently in momentum. Add it to the header of your mobile website or to the status bar with a native plugin (for example, in PhoneGap).

Many other scrolling features could be implemented on top of the native overflow: scroll, such as snapping to a certain element or just infinite scrolling. If your requirements are more advanced, definitely look at the JavaScript options out there.

Make It Easy To Hit Stuff Link

When performing a touch action, users will quite often miss their target by a few pixels, especially on small buttons (such as the ones in iOS’ top bar). Developers can assist users while keeping the design elegant by enabling an invisible touch area around small targets:

   <div class="innerButton">Click me!</div>

You’ll have to put the event handler on the button element, while restricting the styles to div.innerButton. Check out the full example, including CSS61, on JSFiddle.

Using Touch Gestures Link

A smartphone is all about touching and gestures. We swipe, pinch, zoom, drag and long-tap all the time when interacting with touch devices. So, why not offer users the same means of controlling your hybrid app? QuoJS62 and Hammer.js63 are well-known libraries for supporting all kinds of gestures. If you’d like more choice, check out Kevin Liew’s comparison of “11 Multi-Touch and Touch Events JavaScript Libraries64.”

Don’t Miss Out on Native Functionality Link

Building your app with web technology doesn’t necessarily mean that you can’t use native features. In fact, all major cross-platform development tools provide built-in access to the most important functionality. This includes APIs for device data, the file system, the network connection, geolocation, the accelerometer, notifications (including push) and much more.

You can usually even extend a development tool by building custom plugins. At Hojoki, we added many missing features, including reading the user’s setting for push notifications for our app, detecting the user’s time zone, and checking whether a third-party app is installed and launching it. Let’s look at two very simple examples for things that can be realized with native plugins. First, let’s enable JavaScript focus() for input fields on iOS 6+:

if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 6) {
   [YourWebView setKeyboardDisplayRequiresUserAction:NO];

And here’s the code to copy a given string to the device’s clipboard on iOS:

[[UIPasteboard generalPasteboard] setString:@"Your copied string"];

Always Provide a Way Out Link

Web developers often overlook how to handle bad situations in a hybrid app (for example, a connection timeout, a bad input, a timing issue, etc.). A hybrid app is fundamentally different from a website, mainly because there is no global refresh button, and an app can easily run in the background for weeks on some mobile operating systems. If the user runs into a dead end, their only option will be to restart the app, which entails force quitting and then restarting. Many people don’t even know how to do that, especially on Android 2.x (where it’s hidden deep in the app’s settings) and on iOS 6 and below (where you have to double-tap the home button, long-press the icon and kill it).

So, ignore the refresh button during development, and handle bad situations as they come up. For all other situations that would have unexpected outcomes, such as ones involving client-server communication, be prepared for things to go wrong, and provide a way out for users. This could be as easy as showing a full-screen error message — “Oops! Something bad happened. Please check your connection and try again” — with a big “Reload” button below.

How To Wrap It Link

Developing a hybrid mobile app means using the same tools and processes that you would usually use to develop (mobile) websites. Having said that, one thing I really like about the hybrid approach is that you can deploy HTML, CSS and JavaScript code as a mobile web app with relative ease. Make sure to implement fallbacks for native features, or find elegant workarounds if they are not supported at all. Most mobile developers prefer to keep users in a native app, and you could even advertise the app to your mobile website’s users.

Native WebView wrapper around a HTML/CSS/JavaScript code base.65
A native WebView wrapper, with an HTML, CSS and JavaScript code base. (View large version66)

What about the native part? Your mobile web app (plain HTML, CSS and JavaScript) will be loaded in a WebView, which is an internal browser engine that renders an app the way a default browser on the device would render it (there might be slight differences — your mileage may vary). Additionally, native “bridges” are used to expose features of the device and operating system through an API to make them accessible with JavaScript. This usually includes access to the device’s camera, address book, geolocation, file system and native events (for example, via one of the hardware buttons on Android), to name just a few features.

A few cross-platform development tools provide that native bridge and simplify the whole process of wrapping it. Let’s dive into some options.

PhoneGap and Apache Cordova Link

PhoneGap67 is certainly one of the most popular tools for cross-platform development. The name itself is often used synonymously with hybrid mobile app development.

There has been some confusion about its name68 and relation to Apache Cordova69, which is understandable. The latter is a top-level Apache project that was formerly called PhoneGap. It offers a set of device APIs to access native functionality from HTML, CSS and JavaScript code running in a WebView. Now, Adobe PhoneGap is a distribution of Cordova — not unlike the way Chrome uses WebKit as its engine.

Both are open-source and free to use, with support for all major platforms and with an active community developing all kinds of plugins and extensions.

PhoneGap has shaped the hybrid lanscape significantly, and many new tools have emerged that offer additional services or that streamline the development process. They usually add a lot of convenience by enabling you to build an app in the cloud, thereby saving you the effort of locally installing all of the different platform SDKs and tools. Each tool has a different focus, level of platform support and price:

Sencha Touch Link

Sencha Touch7615 started out as a UI framework for the mobile web and has been around for years. Traditionally, developers have used Sencha to build an app while using another service, like PhoneGap, to deploy it as a hybrid app. Nowadays, Sencha offers this kind of functionality built in for free. Platform support includes iOS and Android (both via Sencha’s own native packager) BlackBerry, Windows 8 and more (via PhoneGap Build). Link

At Hojoki, we started using Trigger.io77 two and a half years ago because we were looking for a lightweight alternative to PhoneGap. Even though iOS and Android are its only supported platforms, it offers a good set of native APIs, custom plugins and third-party integration (including Parse push notifications, Flurry analytics and parts of Facebook’s SDK).’s command-line tools allowed us to integrate the app’s packaging into our Grunt78 build process, which is great if you love automation.

One of its key features is Reload9179, which enables developers to push HTML, CSS and JavaScript updates to an app on the fly. Unlike PhoneGap Build’s Hydration80, Reload is specifically designed for development and production apps. This makes it possible to legally bypass Apple’s submission process to push bug fixes and iterate quickly with A/B testing.

Once the 14-day trial is up,’s steep pricing81 is probably the biggest downside for many developers.

With MoSync having gone offline a couple of days ago, seems to be the only remaining tool that is not associated with PhoneGap. MoSync82 seems to be another tool that is not associated with PhoneGap, however I’m not sure how actively it is being developed at the moment.

Test on Real Devices Link

Building a mobile app with web technologies obviously tempts us to do most of our testing in a web browser. This might be fine when developing non-native features, but definitely avoid it when releasing. Test with as many manufacturers, platforms and form factors as possible before submitting the app. Android’s fragmentation brings endless possibilities of differences in browser rendering, unsupported features and manufacturer modifications. While iOS does much better with rendering differences, Apple has a growing number of devices with varying sizes, resolutions and pixel densities. Check out “Prioritizing Devices: Testing and Responsive Web Design83” to learn more.

When Facebook famously ditched most of its HTML5 and went native in 2012, it cited missing debugging tools and developer APIs84 as one of its main reasons. LinkedIn drew the same conclusions85 half a year later, stating that HTML5 itself is ready, but basic tools and the ecosystem don’t support it yet. From what I’m seeing, the situation is getting better, with remote debugging in WebView on Android 4.4+ and an increasing number of development tools on all platforms:

Start Thinking in Terms of Hard Releases Link

When building an app for web browsers, deploying a hot fix to users is a simple step, which means that testing can lose some of its importance. This obviously needs to be reconsidered when you’re releasing an app through an app store. Think of it like software development in the ’90s: You’re now living in the world of hard releases.

So, why is this bad? First, the submission process could easily take a week or two (Hello, Apple!). Secondly, even if your hot fix is released quickly, that doesn’t guarantee that users will update the app any time soon. Here are my suggestions:

  1. Make testing a high priority.
  2. Have some kind of “force update” logic to deprecate old client versions.
  3. Use mechanisms like’s Reload9179 to fix code on the fly.
  4. Apply for an expedited app review92 (Apple only) if you need to be fast.

Get It in the Stores Link

The tools mentioned above spit out a binary for each platform, which can then be submitted to the relevant store. From this point on, the process is exactly the same as publishing a “normal” native app. Some of the tools we’ve looked at might even have better documentation for this. Nevertheless, here are the official guides:

Conclusion Link

Now that our hybrid mobile apps have been in Apple’s App Store and in Google Play for two years, I’d like to recapitulate some of the benefits and drawbacks mentioned at the beginning of this article.

For us, a web startup company with very limited resources and no native iOS or Android experience, building an app for multiple platforms in just a few weeks would have been impossible. Choosing the hybrid path enabled us to reuse a lot of code from the web app and to iterate quickly based on user feedback. We’ve even managed to publish native apps for Windows 8 for the desktop and Microsoft Surface as well as Mac OS X with exactly the same code base. The effort of moving to another platform will depend largely on the capabilities of the given browser and device and on the level of your need for native functionality. We needed push notifications, in-app purchases and access to the user’s contacts, among other things. Depending on your needs, a lot of native functionality could make you heavily dependent on the native wrapping tool that you choose.

Finally, let’s see whether hybrid apps really can deliver a native look and feel. Below is a compilation of user reviews from the app stores. Both positive and negative comments are included, but many of the negative reviews are for early releases, which had the same UI for all platforms and was comparatively slow in performance.

★ Great idea, but not a good app. The app runs extremely slow on my Samsung Galaxy Ace and Tab. The app also looks and controls like an iPhone app. This is confusing when you have never had an iPhone.

★★ Another reason apps should not use WebViews for UI.

★★ Service great but WebView app sucks.

★★★ It’s the right app in concept, but it really is too laggy to be practically used. And I’m using Jellybean so there is no excuse.

★★★ It lags a lot and the UI is not beautiful.

★★★ Good but very very slow.

★★★★ This app is very handy, but is a little slow to boot up.

★★★★★ This is working really hard well since the update. It’s a great app to begin with and now it’s working smoother and faster than before.

★★★★★ Extremely smooth and effective.

★★★★★ The app work flawlessly…

★★★★★ Beautiful designed app! Love the interface and the great overview of all your tools! Good job! Keep shippin!

★★★★★ This is an absolutely beautiful aggregate that runs buttery smooth, even on a 3GS. Recommend to anyone doing any sort of project.

We’re definitely moving away from platform-specific app development and towards the many new technologies that are emerging. Larry Page said this97 when asked at Google I/O last year about the future of the web:

In the very long term, I don’t think you should have to think about, as a developer, am I developing for this platform or another, or something like that. I think you should be able to work at a much higher level, and software you write should run everywhere, easily.

The (mobile) web is a major success story in this regard. Being able to use this platform and still be able to distribute an app in all stores is a huge step forward. It will be interesting to see how this all plays out. Whatever happens, using a technology that over a third of the world’s population98 (over two thirds in Europe and the US) relies on probably won’t be a bad choice.

(da, al, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95
  96. 96
  97. 97
  98. 98
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Patrick is currently responsible for the mobile and web applications of the Eyo EmployeeApp. Before that he was Mobile Lead for the productivity apps Hojoki and CatchApp. Starting a couple of years ago, his initial task was to create mobile apps for iOS and Android within one month, which meant learning hybrid mobile development the hard way. He also got a degree in Business Information Systems, has a passion for entrepreneurship and helps people to keep track of their Google Drive shares with WhoHasAccess.

  1. 1

    I use Ionic Framework to develop Hybrid Apps, it works wonderfully. It works with Apache Cordova and it’s very easy to handle the tests and the builds.

    • 2

      Martin Spierings

      October 21, 2014 4:55 pm

      You should mention that Ionic is mostly using the iOS look. Having an app look like Android or even WP is very hard with Ionic at the moment.

      • 3

        An Ionic app can be styled using CSS and behaviors changed via JavaScript for the other platforms. But yes, it doesn’t do this for you with the default scaffolding.

  2. 4

    There’s no two ways about it. If you want to write HTML keep it in browser! Do not under any circumstances ever wrap it into an app. You might be able to make it look native(ish) but it will not work correctly.
    There’s nothing wrong having mobile web apps. Do that or hire app devs who can build native apps. Going hybrid road might look tempting but nearly 100% devs tend to end up rewriting the app very soon as they run into limitations. In the end the lucrative deal of saving money by using web devs / unified codebase you’ll end up writing it twice and wasting tons of money.
    Forget hybrid. Go native or web.

    • 5

      Probably the most ridiculous comment I’ve read on SM.

      It sounds like you just don’t know how to make hybrid apps work properly.

      • 6

        I tend to agree with Juhani. Just curious, do you know of any Hybrid apps at the moment that are a fairly polished user experience?

        • 7

          Stig Kristensen

          November 5, 2014 10:58 pm

          Netflix and BBC Sport
          Both hybrid apps, both pretty damn decent.

          And iTunes on iOS could be counted as a hybrid app. All navigation is done natively but the content rendered is all web based.

    • 8

      Martin Spierings

      October 21, 2014 4:54 pm

      You obviously haven’t seen any hybrid apps built with latest tech on new devices. It aint that hard to do native stuff, but if you are going for default native controls than a native app might be better, but most apps are only using a small percentage of native implementations anyways.

      More important is the fact that Apple, Google, and Microsoft aren’t doing their best to support web and make sure people will develop apps for it. They all support some kind of Javascript-app but still keep them on the down low so your only alternative is Phonegap/Cordova at the moment (which has greatly improved the past few months).

    • 9

      Thomas Williams

      October 22, 2014 12:28 am

      Sorry, he’s right.

      HTML5 was supposed to be the holy grail three years ago. You could write once and wrap it in diffferent mobile os wrappers for wide distribution. Didn’t happen. Is currently not happening. Doubtful it will happen.

      We need a drastic improvement to the mobile browser and the ability to hook into all the hardware on the phone the mobile os has access to.


    • 12

      This isn’t ridiculous. It’s the truth.

      Cordova is cool and Im glad the steps are being taken to make hybrid apps possible. But if we say hey, it runs just as fast as native (and it isnt), then people will stop pushing for a faster webview.

      You can be optimistic, but being blind doesn’t help.

    • 14

      Sure, there’s nothing wrong with having mobile web apps but the benefits of an app store is a compelling reason to use the hybrid model.
      Heck, a mobile web app has even more limitations than a web hybrid!

      At the end of the day, it depends on what the app is meant to accomplish.

      People who tend to say “never do this” or “this will never work” are wrong almost “100%” of the time.

  3. 15

    “The result is s, which looks like a search icon on iOS, Android and Windows Phone, respectively”

    Thats not the correct use of respectively. Respectively defines things in the order given, here, you’re only defining the span tag, which is one thing.

    Example use: My son and daughter are 3 and 5 years old respectively.

  4. 18

    Martin Spierings

    October 21, 2014 4:52 pm

    This article would greatly benefit examples. Plus you should definately mention that when building an web-app, you should probably support less devices than what you would support when doing native (no iOS7 anymore, nothing lower than Android 4 (or even 4.3) and no Windows Phone 8.0 but 8.1). Why? Because your app will otherwise have lots of bugs (most of which aren’t easy to fix) and will take you much longer to support everything. On iOS and WP you can assume people are able to get the latest version (and ask yourself if its worth the trouble supporting if you arent sure they are going to be your customers anyways, chances are: they will not).

    Another thing i’d like to note is that people tend to think that these kinds of apps are way cheaper than going native for all platforms but thats hardly the case. Yes you might shave off a few weeks in total, but it will take longer than creating one native for a single platform and needs proper testing. The web is currently changing greatly (mostly due to NodeJS and AngularJS) but there are still problems and difficulties making your apps. Many techniques are handy but very new and often have bad legacy support.

    So think well about doing web, but don’t throw the towel after your first bump. The web is a weird place but can achieve a lot these days. Seeking your answers and techniques is mostly half the work as not a lot of things are documented (or at least not up 2 date with latest versions).

    • 19

      It is the tension between richness and rich. By targeting more platforms (reach) the richness of the app (features, look and feel etc) is compromised so limiting the number of platforms is a necessary adjustment.

      What is constantly a stumbling block is how “standards” are not standard. I have faced bugs caused by invalid native JSON objects or most recently Chrome changing how number inputs are accessed via JavaScript. By going native these problems can be accepted and resolved (richness). As a hybrid app developer I have used jQuerymobile, Titanium and Ionic and none are a silver bullet. I might go native on my next app so I have more tools in my belt.

      But who has time and money to buy devices for and support iOS 7+, Google Nexus, Samsung Bada, Blackberry, Windows 7/8.x et al?? Perhaps we have fallen ill with the Java curse – write once run everywhere. I think graded support is the optimal strategy for hybrid apps.

  5. 20

    Great read. I’ve been building a hybrid app with Ionic and I find it’s awesome to work with. I’m liking the hybrid app approach because it gives guys, much like myself, the ability to build apps now that aren’t familiar with a language used to build native apps. Just my O2. Again, this was a great read.

  6. 21

    Thanks, great article. It gave me the confidence to start developing with hybrid, knowing you guys are successful without a native background.

  7. 22

    Yay! I do believe JavaScript will be the one and only language for apps. So much that I spent an awful lot of time writing a framework that takes care of all these aspects plus more, delivering quite the native feeling.
    I’d be delighted if someone is willing to give it a try.

  8. 23

    Kendo UI Mobile is part of Kendo UI Core which is now open source and not a commercial package as specified in the article!

    • 24

      Hi Rob, I probably missed that change, thanks for the heads-up. Is it correct that the open source version does not include all available widgets and UI for PhoneGap?

      • 25

        Kendo UI Core contains the mobile framework and all of the mobile widgets (a.k.a. UI for PhoneGap). It doesn’t contain the “pro” grade widgets such as a grid, scheduler, and data visualization components.

  9. 26

    Excellent article. Starting my first hybrid app soon, I’m sure I’ll be referring back to this once or twice.

  10. 27

    Excellent article.

  11. 28

    awsom.. article. i will try my first hybrid app soon..

  12. 29

    I’m sorry but hybrid apps do suck, for now. Their speed is not the same.

    However, Apple is implementing WKWebView in iOS8 which may speed them up significantly.

    I’d rather build web apps for Firefox type phones where every website is an app waiting to be installed.

  13. 30

    Vignesh Swaminathan

    October 23, 2014 8:22 am

    Good article thanks, the pointers mentioned in the article are very helpful. The only point that I disagree with is on the native UI look and feel. Some counter points

    1. Games are the most used apps in any smart phone/tablet and irrespective of whether the game is native or hybrid (ignoring the performance question), all of them have one thing common and that is they have the same UI across all OS. Why then do people not mind it and even love games?

    2. Some UI interactions that are popular (& controversial) such as Hamburger menus were not native and never a part of the OS style guideline. However that did not stop, many top apps such as LinkedIn and others to implement them. This is because, style guidelines are essentially ‘guidelines’ they are not rules. App developers should feel free to innovate UI interactions and not be constrained by guidelines.

    Finally the negative app review comments that you have posted very much point to ‘developer’ users and not everyday users. This is evident from the negative comments which specifically mention ‘webview’, which any normal user would have no clue of. Never get swayed by the comments of users of this type because there is a risk that their view might be biased.

    The key I feel is that people will use apps that they want to or have to use. App developers should focus on building apps that people want to / have to use rather than UI guidelines.

    • 31

      Hi Vignesh, I’m glad you liked the article.

      I definitely agree with you when you say that there are many good use cases for custom UI components. As I mentioned in the article, it always depends on your requirements if you want to stick to each platforms guidelines or now. However, if you want to do your own thing, you should have a good understanding of UX design and general design patterns.

      Thank you for your feedback!

  14. 32

    For Android, if a hybrid app utilizes native methods (and by saying native I refer to java not C/C++ like I usually do when talking about the Android NDK (N for Native)), you are leaving the benefits (a single code base for instance) of the hybrid approach. You will need devs who are capable of implementing these nativ methods if you haven’t any ready to use by the framework of your choice.
    You see yourself now dealing with HTML/JavaScrip/CSS *and* java/objective-c/C#
    I firmly believes this is diminishing the benefits.
    Also, you experience a greatly fragmented market. Various devices, various browsers, various WebViews, various OS with various versions, various rendering engines and so on.
    And html5 should be the one to rule them all? It would be if your hybrid app never has code lines like “if os=android && version >=4.0” and this will in the nearer future (< 5 years) not be the case.

  15. 33 is back online, so you can change that paragraph :)
    Nice article, I didn’t know about mosync :)

  16. 35

    This is my first time stumbling on this website and it just so happens I’m making my first hybrid app. This article is a gold mine for me :) Good job.

  17. 36

    I’m surprised to see references and comments about fragmentation and WebView performance, and yet nothing about or

    They basically allow you to bundle a WebView into your hybrid app (replacing the native one) , thus improving performance and minoring the fragmentation problem by assuring your app will always use the same WebView (at the cost of a bigger app for the user to download).

    I’ve personnally never used any of them, but am planning to integrate it with my latest project using Ionic / Cordova.

    Beside that this is one of the most comprehensive and complete articles about hybrid apps I’ve read lately, thanks. :)

    • 37

      Now this makes Cordova way more interesting. If this can take care of Android and iOS8 uses WKWebView then hybrid apps will be much closer to native than ever before.

    • 38

      Thank you for linking those resources. The bundled WebView sounds very helpful. I had no chance to give it a deeper look yet, but will definitely check it out.

    • 39

      Actually, I took look at new additions in Android L and looks like that they’ve injected a (chromeview) in the os which would update it self independently from other apps in the phone!

  18. 40

    Hi Jeremy, thanks for the notice. It looks like they’ve already removed the article.

  19. 41

    Hi Gav, glad you liked it. Thanks for the notice regarding Webzin. Seems like the post has already been removed from their site.

  20. 42

    Hey Nate, thank you! Crosswalk is a very interesting approach on hybrid apps. I’ll definitely consider it for my next projects.


↑ Back to top