Home Web App vs Native App
Post
Cancel

Web App vs Native App

Companies deciding how to invest in mobile applications ask the question of web app or native app. To understand the answer companies need to understand the pros and cons of each.  Ultimately it's not one or the other.

HTML gives ubiquity. Native development gives excellence. You want both.

Development Costs

HTML will win hands down in simplicity. You can get a basic web page online and running on every major mobile browser in an hour and have time left over to check your email and update your status. The complexity and development costs on native apps however can add up, especially if you need to develop for multiple platforms.  Getting a basic "Hello World" app running in 2 major app-stores requires knowledge of ObjectiveC & Java. Not to mention the submission, review and approvals of these apps.

There is little code re-use across platforms in native apps. Your typical Android app isn't going to improve the development of your iPhone app or vice-versa.  There are cross compilation projects that attempt to bridge this gap however only lower level C/C++ cross compiles with any consistency and this generally is the functional, not user-facing portion of the app.

There are at least a dozen tools that promise cross platform development. These tools are either compilers that produce native code or wrappers around web API's. These tools generally sit between you and the platform you're trying to support. This layer between you and your users can dramatically impact the...

Quality of experience

When it comes to quality of experience native applications tend to win. Native applications perform faster and have access to more aspects of the phone's operating system. This allows for better animations, camera and video access, richer native controls and navigations and more.

HTML has greater flexibility in presentation and allows for content updates to happen via the web. This can enhance the user experience when content is updated frequently or the user interface tends to change often.

In some cases the quality of experience when using web technology is acceptable in others it's clearly a sore spot. One down side to native experience is crashing.  While web apps can also crash they often fail more gracefully.

HTML - The promise of write once, run anywhere

HTML(5) promises developers that they can write their web-app once and have it run anywhere. Tools like phonegap & Sencha provide bother wrappers for native API's and Javascript libraries to allow web developers to look and perform closer to native.

Sounds good, except when you deal with the details. In particular performance and native user interfaces.

Things like scrolling a list and basic object manipulation in HTML can feel... "Sticky."  This is because the design and layout are interpreted by the web-browser and this interpretation takes time.

HTML is reasonable to use on layouts that are primarily presentation of static content (the original purpose of HTML). It tends to break down in quality of the user experience as it strays toward interactivity or large amounts of data.

Some examples:

  • Facebook uses HTML to present static status updates but their slide to reveal interface is native.
  • LinkedIn uses HTML to present static profile data on users but much of their core UI is native
  • FlipBoard uses HTML to layout content pages of their articles but the animations and flip transitions are native
Even in these examples the use of HTML can impact the performance. Ideally the technology choice should be transparent. Users shouldn't be able to tell.
How to choose?
Design should come before you choose. Don't choose a technology before you understand what you want to build. There may be places where you want to use HTML and places where you want to be native.  Don't try to force native things to be web or web things to be native.
HTML performs best in mobile when it's informational/content. It's possible to get some performant interactivity out of HTML but it's difficult.
Native code tends to interact better with core services, it tends to provide better animations and transitions. If you're interacting with lower level OS features or tying into the platform or 3rd party SDK's, you'll likely want that aspect native.
Choosing the right technology is a balancing act between providing a great experience and providing developers with some flexibility.
It comes down to a choice between ubiquity or excellence. Use HTML to give you elements of ubiquity and native to push the bounds of excellence.
This post is licensed under CC BY 4.0 by the author.