Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to develop a mobile application. I recently read an article on Telerik Forum, which compares among three types of mobile application and I don't know which one should I select to begin with. Here is an image describing the pros and cons of different mobile design choices

Telerik mobile design chart

To decide between these design choices, I would like to better understand the pros and cons of each architecture choice listed in the diagram. What are the pros and cons of each architecture approach?

share|improve this question
This question appears to be based on this prototype. The original question attracted 88 answers, only one of which is exemplary. I appreciate the effort the author put into the original question, but history hasn't looked favorably on these kinds of questions, and I've voted to close this question accordingly. – Robert Harvey Jun 13 '13 at 22:21
@just_name While asking which one is better is off topic, I revised your question to ask for a list of pros and cons to each architecture approach. I then reopened your question. Hopefully you get better answers now. – maple_shaft Jun 16 '13 at 13:39
Based on wording I expected to see a discussion of some sort of general non-ageing principles (e.g. battery life, connected/disconnected etc.). Instead there is another HTML5 vs native thing. – Den Jun 17 '13 at 17:14
You may find this article about LinkedIn's decision making process interesting. – Brian Jun 17 '13 at 17:56
up vote 19 down vote accepted

I'm a mobile developer who has spent a great deal of time considering this issue.

Why do you ask?

Most likely, you hope to reduce app development costs by:

  • Using existing HTML5/Javascript development skills
  • Targetting multiple platforms without writing multiple apps from scratch
  • Not having to maintain multiple codebases in the future

Reasons may also include:

  • HTML5/Javascript development perceived as "easier" than native platform development
  • Avoiding payment of developer programme registration fees
  • Avoiding appstore content restrictions (gambling etc)
  • Avoiding purchase of development hardware (e.g. Mac for iPhone development)


Let's establish exactly what we mean by each of the three approaches mentioned:

An app that is installed on a device, usually from its app store (although can sometimes be sideloaded). For the purposes of this discussion, the UI of a native app does not usually consist of a full-screen webview only.

Mobile web
This can in fact be any web page at all, however for this discussion let's consider a single-page web app which attempts to imitate the look and feel of a native app. It is not a native app, it runs in the device's browser.

Hybrid app instanceof native app.

Most people probably understand a hybrid app to be a single-page mobile web app (again most likely imitating the look and feel of a native app), but packaged as a native app with access to native services (à la Phonegap).

However there is in fact a spectrum between the Phonegap model and fully native which I'll come to later.

Mobile web

Technical restrictions
Let's first list some technical restrictions on mobile web apps which could in themselves be deal-breakers depending on what you're doing:

  • HTML/canvas UI only
  • No access to certain device events and services (these are widely documented)
  • Cannot be listed in app stores (affecting discoverability)
  • Can become full screen and have homescreen icon on iOS, however this is an unusual and unfamiliar experience for most users

If you can live with all the above, then read on for more about the challenges of single-page native-style web apps. However this section wouldn't be complete without reference to the FT app.

Financial Times
The FT web app is a famous example of this style of app. Here's an interesting feature from the UK Guardian newspaper about it.

It's certainly a remarkable feat of engineering. Note that it is currently still only available on iOS only -- this tells me that they are finding that resolving the challenges of advanced cross-browser development to be very difficult indeed.

Single-page native-style web apps

This section applies to both mobile web and Phonegap-style apps.

Native-style look and feel within a web app is usually achieved with a framework such as Sencha Touch which provides a suite of UI components for you to use.

Such frameworks are fine for very simple UIs. However they lack flexibility. You won't be able to implement any native app design using Sencha, you'll need to adapt your design to what the framework can accommodate.

The main way in which these frameworks suffer is in trying to emulate the platform's own UI intricacies. That nice little bouncing effect you get when you've scrolled to the end of a list on the iPhone? Your framework needs to emulate that in Javascript. It's impossible to recreate it completely, it will be prone to slow down, and your users will be stuck in the the "uncanny valley" of an app which looks sort-of like native, but clearly isn't, and a non-technical user won't be able to put their finger on exactly why.

The "HTML5/Javascript is easy" myth

Device fragmentation within web browsers is rife, and when you get beyond the most basic HTML and CSS you'll notice things don't quite work as you'd expect. You might find yourself spending more time solving fiddly UI issues than you'd have saved doing it natively twice over. If you're going native, note that native app webviews are not the same as device browsers and have their own fragmentation issues.

And as your app gets more functionally complex, you'll find that you need more than basic jquery skills to keep your Javascript clean and maintainable.

That said, it's perfectly possible to create simple, functional apps pretty quickly with this approach. But it's pretty obvious when an app is doing it.

Further along the spectrum

So, we want a better UX than Phonegap-style apps can offer, without writing absolutely everything from scratch multiple times. What can we do?

Share non-UI code

There are a range of techniques available for sharing business logic across multiple native platforms. Google have launched J2ObjC which translates Java into Objective-C. With careful factoring of code, a Java library could be used on both Android and iOS.

Libraries such as Calatrava and Kirin allow codebases written in Javascript (and therefore anything that can be compiled to Javascript) to be manipulated from native code. Disclaimer: I work for Future Platforms who created Kirin; we have had great success using it on iOS with Javascript generated from Java with GWT, with Java code also being run natively on Android.

Use webviews... where appropriate

Full screen webviews have a lot of work to do to be able to imitate screen transitions and bounce effects. But a webview inside native app chrome can be indistinguishable from native.

There are standard and well documented methods for native apps and webviews to communicate.

Lists and tables can work particularly well when done in this way, however text entry is an example of something best handled natively (for full control over keyboard).

In summary

The approach that's right for you depends on how complicated your app is, and what level of UI polish you'll be satisfied with.

My motto: use webviews wherever you can, but make sure your users can't tell.

share|improve this answer
Great answer! And good you talked about J2ObjC, I wasn't aware of that. – momo Aug 21 '13 at 17:06

First check this survey to know what is going on !

comparison between the three types: Understanding Your Mobile Application Development Options

Comparisons between native and hyprid:

HTML5 vs Native

HTML5 vs Native App : Which to choose ??

This one is really good : HTML5 v native apps: key considerations for your mobile strategy


  • You can go for one of them depends on what you have (skills) and what you can get(look and feel,performance ,functionality ,...)
  • Every mobile app developer should have a clear vision/requirements about the application he is about develop for the first versions and the future ones ! just to ensure that the option he would use will not limit him at some point.
  • There is nothing like having a real experience with the three ways and being up to date at the same time, this will give you the sense and the ability to take right decision.
share|improve this answer

If you need to access the phones hardware, you should build a native app (in HTML5 you can access some of the hardware components of the device such as GPS).

If you are more comfortable with web development, you should stick with that unless you need to make a native app.

As far as what you should know, i would say that you should keep in mind all the different screen sizes (including vertical and horizontal orientation). You should keep in mind various versions of the OS (this is more for android). Since these are mobile deivces, there is the chance that the user will answer a phone call it its a phone and also they do not have the computing power of a desktop or server.

share|improve this answer

With the below, my current stance on this debacle is that hybrid is good to start with, to explore your app, quickly iterate on customer feedback and stabilize the feature set. Then, to rewrite the app to native according to the spec, to enhance the experience.

I've left Mobile Web out, because it serves a completely different purpose. If you want to be in the app stores, Native/Hybrid is the way to go. If you want to simplify deployment and willing to sacrifice experience and technical ability, go for Mobile Web.

Pro/Cons Native:

  • Pro: It fits with the rest of the device experience, no uncanny valley issues.
  • Pro: It mostly provides a smooth consistent UI experience, no delays, no stutters.
  • Pro: Few technical limitations, you can fully utilize the device.
  • Pro: Native tools provide compliance with app stores validation.
  • Pro: Native frameworks include tweaks per platform version, less time spent on fine-tuning.
  • Con: It's build to last, and therefore takes more time to build.
  • Con: Requires polyglot-developers which are hard to find, expensive.
  • Con: Need to familiarize each device platform API's (iOS/Android/etc).
  • Con: Steep learning curve.
  • Con: Different toolset per platform.

Pro/Cons Hybrid:

  • Pro: Single codebase to target multiple device platforms.
  • Pro: Quick development cycles, great fexibility in layout, perfect for prototyping and MVP's.
  • Pro: Comfortable learning curve, lots of documentation, frameworks to help you out.
  • Pro: Single development toolset. Chrome debugger tools are excellent.
  • Pro: One codebase to target multiple device platforms.
  • Pro: Lots of developers available, easy to learn.
  • Con: Requires decent UI framework to adapt UI for every different platform to be consistent with the device experience. There are solutions like Kendo UI, Sencha Touch.
  • Con: Need to be very conscious about memory and compute usage, some CSS, javascript loops can seriously slow down the app. Not very good tools available on-device to debug.
  • Con: Not matured yet, things can suddenly change, tools are getting better though.
share|improve this answer

To me when writing any consumer app, what is paramount to its success is user acceptance and perception of the app. Because of that four reasons to lean in favor of native apps, despite the additional costs associated with learning, training and losing WORA(write once run anywhere) are:

  1. Faster App startup
  2. Smoother scrolling
  3. More consistence app ui that ties in more consistently with the rest of OS and apps
  4. Faster App UI response

What you want above everything else is a great user experience that helps your app succeed in a cut throat market place. Of course there are exceptions especially lack of skillset, lack of time and budget. Sometimes apps are geared to a limited set of business users who may not care that much about these things.

It is reasons similar to these that Facebook ditched their app strategy in favor of native apps for IOS and android:

Please read:

Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5

Why Facebook Ditched the Mobile Web & Went Native With its New iOS App

Hope this helps.

share|improve this answer

Being a mobile developer myself, the worst thing is offline access. You simply force users to be online which should work in a lot of apps, but not in all.

The other great bad aspect is slowness. Time needed to parse remote data can take significant time. Yes, you can pre-fetch data during the load time, but in all other cases you cannot avoid slowness.

I found that such app ended app more expensive than native ones. I no longer recommend them to any client of mine.

share|improve this answer

protected by gnat May 18 '15 at 13:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.