Paths To Your Mobile Application Development Web Hybrid Or Native

・17 min read
Paths To Your Mobile Application Development Web Hybrid Or Native

The year 2011 has ended and I think one might justifiably claim that it was a ‘year of mobile’ indeed. We are going through tough economic times and yet we can observe how smartphones, tablet devices and mobile technologies are driving the growth of world’s largest markets like the US, Europe and Asia.

The trend has important implications for entrepreneurs and enterprises. A growing number of their customers migrate to another channel – the mobile channel. If several years ago an entrepreneur grappled with the dilemma whether to be on the web or not, now the dilemma is about ‘presence’ on mobile devices. And the key issue about mobile solutions is often not so much a question of “if” or “when” to enter the game, but rather “ how” to do so – should you develop a web application, a hybrid / cross-platform solution or a set of native apps for specific OS platforms? Let us first figure out why the question is of utmost importance and should be answered with a lot of thought if you intend to develop a mobile solution. The complexity of the issue is rooted in the enormous diversity of the mobile market as well as the rapid changes it is undergoing. The diagram below shows the market share of the Operating Systems for smartphones worldwide.

The decision about which platform to choose, should not be based primarily on the market share of the devices sold; it is advisable to carefully consider the associated application store markets as well as the target customer’s app acquisition volumes and trends thereof. Putting the important note aside, the point is clear – each operating system determines the selection of programming languages and related technologies with which to implement your solution. These days at least, if you are thinking about native apps, you will surely consider iOS and Android. That means you will need at least two (teams of) developers with proficiency in each platform-specific language. Moreover, if your requirements in terms of platform coverage go beyond the most popular iOS and Android, then you may have to develop separate apps for Blackberry, Windows Phone or other platforms. This is the single biggest pain, as each native application has to be developed and maintained as a fairly independent process. Even some elements that one might think are easily reusable as, for example, UI, need to be tweaked for each platform to deliver the look and feel the user is familiar with. Is there a remedy for it? Some say, there is. Web technologies can offer a solution in the form of a WebKit – a layout engine for rendering) web pages, currently applied in most modern web browsers. It gives enough flexibility to achieve the look & feel that is close to native interface experience for the user. However, it is only partially true since there is no such thing as a uniform WebKit on mobile platforms, as Peter-Paul Koch @ppk, a renowned mobile platform strategist, consultant, and trainer pointed out. Mobile implementations of the WebKit differ slightly from platform to platform. Still the underlying engine is very much similar across all the platforms usually considered, possibly including even MS IE9, as a lot of the web standards have been incorporated into the release of the MS web browser. So instead of developing separate apps for iOS, Android, Windows Phone 7, RIM/BlackBerry, you just create a single one and distribute it on all the platforms, saving time and money. Can it really be that easy? Unfortunately, not. There is a price to pay if you choose the apparently attractive alternative. The decision on which approach to adopt should be made upon careful consideration of the trade-offs involved. The pros and cons of each option should be weighed against the specific business conditions you are confronted with, e.g. the motivations underlying your decision to enter specific app markets. So what are the options you may consider? What are their key advantages and disadvantages?

  • a web application. It is, basically, an HTML5 and CSS3 web page optimised for mobile devices. It can be developed using responsive design concepts or mobile web frameworks such as Sencha Touch or Jquery Mobile.
  • a hybrid application. It allows you to distribute your app as a native solution by adding a wrapping layer for the browser (for instance, Adobe’s PhoneGap). The end result is native or close to native performance, native UI look and feel and access to native distribution channels. The approach is an attempt to get the best of both worlds. It should be noted that PhoneGap allows you to run the app in a given device’s browser, which enables you to use Sencha Touch or jQuery Mobile to develop your app.
  • a native application / native applications. They are written for specific operating systems and can, therefore, easily integrate with the associated devices’ hardware as well as make full use of native speed, responsiveness and UI look and feel.


With all the hype about mobile and mobile applications, I have noticed one very important fact that is often missing in the debate: consumers use mobile web just as much as native apps. In June, 2010, Comscore published a report which revealed that 72 million mobile users in the US accessed a website compared to 69 million users who used an application running in their device OS environment. Interestingly enough, both groups showed a year-to-year growth rates of more than 25%. A web application is an application that runs in the browser, providing users with the look and feel of a desktop application. Likewise, mobile web apps are designed to run in a mobile device’s browser, and are meant to imitate the look and feel of other applications installed on the mobile device. It is usually accessed via the same URL address as its desktop counterpart, yet the server can detect that the client is connecting from a mobile device and redirects the user to the mobile version of the application. When it happens, the browser adds “m.” before the URL you have typed. Techniques such as Responsive Web Design allow to adjust your app layout to fit the user’s device screen size. Additionally, with the detection of the mobile device and its operating system, your mobile web application can send a different HTML and CSS markup to further optimize the look and feel of your application for the user. As regards the Ruby on Rails web framework, it can be the same Model-View-Controller pattern, but the views should be somewhat different for every OS/device type. It all boils down to well-architectured web apps. The biggest advantage of the web app is that it is a very cost-effective option, in particular when compared to the effort and expense needed to develop a set of native applications.


  • Fast application development at a reasonable cost, mainly because a web app option means less code in general, more reusable code as well as a greater skill and infrastructure reuse. Timing may be crucial for some businesses – when the short time to market often means competitive advantage. As regards skills development, a specific team takes less time to learn how to use JS for mobile web than it takes them to master Objective-C from scratch.
  • Fast and easy version deployments and updates. You simply deploy a new version and all the users gain instant access to it. By contrast, the deployment of native applications requires an explicit update action performed by the user and is likely to be connected with a lengthy approval process in some stores (e.g. Apple’s App Store).
  • Usually one codebase to maintain. Note: if you use some native bindings, you have to maintain them separately.
  • HTML5 apps are searchable by crawlers such as Google’s search engine, which ensures that the apps can be discovered by a number of consumers searching the web (SEO).The same URL is used to display a regular website for a PC user and a lightweight version for mobile visitors. Support for native animation, canvas painting APIs, webgl (all of them hardware accelerated), file APIs and video, image interactions, like drag and drop or live editing – all of them available thanks to HTML5/CSS3.
  • Access on a wide range of devices.


  • Limited hardware access. You often cannot access hardware with HTML5 and CSS, which means you cannot access device-specific interfaces or special hardware / software features; you need to write a native plugin, i.e., in Java or Objective-C, to do away with the limitation. However, even when you have such a native plugin, you still have to ask the user for permission to activate it. It can lead to many pop-ups and negatively impact user experience. By comparison, a native app user grants permission once only, when they download the app. With web apps, you also do not have access to “push notifications”. Local storage is limited to 5MB.
  • Performance – a web app is not and will most probably never be as fast as its native equivalent. An application built on html tags requires a strategy for cleaning the tags; otherwise, the app becomes ever more bloated with every user’s click. This applies in particular to big applications.
  • Bandwidth requirements defined through its cost for the user and page load experience. The user may need to download the whole application or parts thereof each time he accesses it through the web browser.
  • Limited offline experience. In principle, the user needs to go online to use the app. Offline mode can be incorporated by introducing caching techniques, though the results may not be satisfactory. Lack of native look and feel. A web app can merely strive to mimic the latter. A web app is an application that runs in a web browser. If there is a bug in JS, the application will silently fail, leaving the user confused. A developer has to put extra effort in order to prevent it.


  1. made an iPhone native version of the application. The app was for a long time included in the Top 10 iPhone reference application list. At the same time, their mobile Ruby on Rails powered webpage version of the application turned out to be equally popular, exhibiting a comparable user base. When users visit the whitepages using mobile devices, they are offered a mobile version of the page and are asked for localization permissions.
  2. The Financial Times. It is often claimed that the newspaper industry is struggling hard to make ends meet and mobile solutions might help at least some titles recover. The FT had a dilemma whether to use the distribution channel offered by Apple and relinquish 30% on each subscription or launch an independent service as an HTML5 mobile web app to buck the Apple’s commissions. Though the FT was not sure if HTML5 would work for news, they decided to try the mobile web app approach. According to the FT, by the end of 2011, had hit 1 million registered users who accounted for 20% of the outlet’s online page views, and 15% of new digital consumer subscriptions. Moreover, 45% of the 1 million registered users added the web app to their home screens, possibly due to an aggressive set of in-app prompts which vastly increased return visits. If someone claims that a mobile web application cannot be monetized, this is the best example to prove them wrong.


In a perfect world with unlimited resources like money, people with skill sets needed and time, you would choose to develop a set of native applications for all operating system to be covered. A native application goes a long way towards brilliant user experience, because you are building a solution for a target operating system / devices, which gives you a lot of control on the look and feel of your product. Native apps ensure the fastest response to touch events. Besides, when you leverage native UI in your application, you increase the odds of positive reception if only because the user is already familiar with their device’s UI. You can produce decent – sometimes even impressive – things with HTML/CSS/JS, yet they are unlikely to reach what is possible with native solutions. They do have their limitations. It should also be noted that, there is a constant race between operating systems and devices allowing new functionalities vs. web application frameworks’ developers that are trying to catch up with HTML5 and CSS3.


  • Full hardware access as long as permission is granted by the user. To list the most important features available: uploading pictures from the phone, calendar integration, access to the address book.
  • Native speed and responsiveness.
  • Native UI look and feel.
  • Access to distribution channels like Apple App Store or the Android Market.
  • It can be launched and used without Internet connection, so bandwidth requirements are considerably lower than for a web application.


  • Greater development effort. It definitely takes more workload to develop a set of native apps than a single web / hybrid app. With the same resources (velocity) given, it may take more time to finish the solution.
  • Longer iteration cycle time compared to the other alternatives. Even if we ignore the availability of resources needed to develop a few native apps vs. a single web app, you still need to account for a rather time-consuming process of application approval by the app store owners.
  • The most expensive option. The app needs to be developed and maintained for every platform to be supported. You need a set of apps to cover the platforms you want to serve.
  • Native apps need to be approved by Application Store owners to gain access to their distribution channels. Similar approvals are needed for successive updates you want to implement.
  • People will not find your application using search engines like Google unless you set up a webpage promoting the app (SEO).


  1. Twitter is an example of a successful web service that expanded to the mobile market. Twitter has essentially covered all of the smartphone platforms and, what is interesting, some applications are not even vendored by Twitter themselves. Twitter applications are available on Iphone, Android, BlackBerry and Windows Mobile/Windows Phone 7.
  2. Instagram – “ (…) a fast, beautiful and fun way to share your life with friends through a series of pictures. Snap a photo with your iPhone, choose a filter to transform the look and feel, send to Facebook, Twitter or Flickr – it’s all as easy as pie. It’s photo sharing, reinvented.” – to use Instagram’s own words. The application was a huge success. It was picked by Apple as the iPhone app of the year 2011. It is also an example of an app, that could not be reproduced with HTML5 and CSS3 techniques as a web app which preserves the way the native solution works, looks and feels.


As regards native applications, there is a notable option that needs to be mentioned here as it is trying to break one of the key rules of the game – namely, that each OS platform requires the application to be developed and maintained as a fairly independent process. The alternative is a framework known as Appcelerator or Titanium. The idea behind it is to be able to extensively share the codebase among the applications developed for specific platforms. The approach is meant to retain the strengths of native solutions while at the same time significantly reduce the time and cost needed to develop them. Titanium exposes an API that enables JavaScript programmers to use native UI components – written in Objective-C (iPhone and iPad) or Java (Android). Titanium gives a developer over 300 APIs and a lot of support from their enthusiastic community, which helps to build applications that are more social, local, media rich, interactive, and extensible than web applications.

Example of a Titanium-based application

A good example of a solution based on Titanium is an application developed by the University of Wisconsin-Milwaukee (UWM). The cross-platform app for students, gives them access to their course schedules, bus timetables, laundry availability information, and upcoming campus events. The app was built by the university web development team that wanted to create a solution for both platforms: iOS and Android. The team, additionally, intended to utilize their JavaScript skills as well as the existing back-end web infrastructure while developing their mobile apps. As the case study claims, they managed to cut development costs by 80% and reuse 97% of the codebase between the Android and iOS versions.


The decision which of the options to pursue (responsive design, mobile web page, hybrid application, a set of native applications) depends on a specific company’s requirements, e.g. their target audience, the functionality or user experience needed as well as a host of other factors to be considered. Here are some questions which may guide you towards the issues that should be taken into account when deciding on the mobile approach to take:

  • What sort of content and functionality do you need to provide the customer/user with?

  • How complex is the application you want to develop?

  • Are you after an innovative solution and thus likely to iterate fast and pivot?

  • Will your app need to access hardware and software features of the mobile devices? Which features, specifically?

  • Who are your customers and/or users? Where are they? Which devices and / or OSs are they using? Where are they going to be, taking into account market trends?

  • Which platforms does your mobile app has to be available on?

  • Is your success dependent on the established distribution channels / app stores? Are there other ways to monetize your application to avoid sharing the revenue with application store owners?

  • What is your budget? Can you afford to develop an expensive set of native apps?

  • Are you pressed for time? What’s your cost of delay?

  • Are there bandwidth considerations? Is your app going to expose the user to incur high web app download costs / long download times?

When you have the answers to the questions above, you are fairly well equipped to make a reasonable decision on which path to embark. For example, if you have a substantial budget, your app needs superior look and feel, its performance is absolutely crucial for the customer, you need unlimited access to the devices’ hardware features and plan to monetize your application using established app stores – building a set of native applications for each OS you want to serve, is the best way to follow. On the other hand, if you operate on a shoestring, the time to market is critical and you need to validate your ideas quickly, your application is not very complex or bandwidth sensitive, plus you do not need to access many hardware features or sell through app stores – a well-architectured web application might be the preferred approach. In other cases the best choice may be a hybrid application. Still bear in mind that it also comes with its own strengths and weaknesses.


I would like to express my gratitude to Michał Czyż, Tomasz Bąk, Rafał Bromirski and Bartłomiej Wójtowicz for the expertise and insights they were kind to share as well as the invaluable feedback they provided me with.