Here's an
executive summary of the decisions that need to be made when deciding
between HTML5 and native mobile app development. This isn't meant to be
an exhaustive study of all the pros and cons; if more information is
needed, I will be happy to go into greater depth.
Definition
The HTML5
moniker gets thrown around loosely. Technically, it refers to the fifth
revision of the HTML standard, but it is commonly used as an umbrella
term to describe a combination of HTML, CSS, and Javascript technologies
to render modern web content.
Native applications consist of code that is compiled
and installed onto a device. Apple iOS applications are commonly coded
in Objective-C and compiled using Xcode; Android applications are
commonly code in Java and compiled with the Eclipse toolchain. The terms
"app" or "apps" usually refer to native, installed applications.
Webapps or web applications consist of code written
in web presentation technologies: HTML, CSS, and Javascript. They run in
a web browser on the device and do not require the compilation step. On
iOS devices, special HTML tags can be used to remove the browser chrome
(the address bar, status bar, bookmarks, buttons, etc. that surround
the area where the web page is displayed) and status bar, allowing the
web page to be displayed in full screen mode and launched from an icon
on the springboard. (The Springboard is the iOS "desktop" screen where
the icons are displayed)
HTML5 Apps are native applications that usually
consist of a full-screen web browser window with no chrome around it.
Inside the web browser, content is rendered using web technologies such
as HTML, CSS, Javascript, SVG, or Canvas. (Usually HTML) Most often,
the HTML content resides on the device as part of the application data
to prevent the latency of URL calls.
The HTML5 Panacea
A
popular point-of-view in mobile development is that HTML5 solves the
"write once, run anywhere" challenge. The idea is that developers can
spend a few minutes building a native shell application consisting of a
single browser window on multiple devices, then serve a common set of
content files to all the target devices. With the proper design, the
content will look nearly identical across all devices and you don't have
to spend time on device-specific code.
This idea sounds great in theory, but the reality is
far from simple. Differences in HTML capabilities, screen
size/resolutions, CSS rendering quirks, and HTML rendering engines (such
as webkit, gecko, and IE) make achieving a consistent look across
devices extremely difficult. It's hard to do on the desktop and it's
just as hard on a mobile device.
HTML5 Frameworks
A
handful of frameworks exist to make developing HTML5 applications very
easy, Cordova (formerly named PhoneGap) is the most popular. Cordova
takes care of the native part of the implementation for each device,
freeing the developer to spend their time working on the content. You
download the code for your target device, open the files, and drop your
HTML code into a specific folder. Cordova offers an cloud-based build
service that allows you to send your code to their servers where it is
compiled into an installable application.
Frameworks such as Cordova often expose and abstract
hardware APIs with Javascript. For example, many devices have
accelerometers or gyroscopes but lack a consistent method of reading
their values. Cordova takes care of how to "talk" to each device's
sensors and adds new method's to Javascript's navigator object, such as
navigator.accelerometer.getCurrentAcceleration(). (The browser's
navigator object does not have an accelerometer property by default,
Cordova adds it) Similar properties exist for camera, compass, contacts,
etc.
HTML5 Development: Speed and Cost
In
recent years, iOS and Android developers have experienced very high
demand for their skills, driving up the cost and demand for this talent.
By comparison, web developers are much more plentiful and commonly
offer their services at a lower rate. (and they have more availability)
If a native app and HTML5 app take the same number of hours to develop,
the development cost for the latter will be lower. If you need to
develop for both iOS and Android, the development cost might double when
the developer creates different codebases for each platform.
Native application development, especially custom
interfaces and code, are much more difficult and time-consuming to
develop as compared to web development. The initial development is often
cheaper with HTML5 apps.
Dynamically Updating Applications
If
your HTML5 app designed to be able to call Internet URLs for its
content, it is possible to update what the end user sees without
recoding and recompiling the application. (and then sending the update
to the platform's app stores) Some HTML5 applications are able to update
their layouts, look-and-feel, and even change functionality by
modifying HTML code and FTPing it to an online web server.
The Dark Side of HTML5 Development: Going Beyond the Demo
So
far, everything about HTML5 development sounds great: cheaper
developers, shorter development cycles, easier updating, and the ability
to target multiple platforms. Why wouldn't everyone do this? In
minutes, you can have a demo-able prototype that works well enough to
convince management that this is a slam-dunk and the rest of the world
is crazy for spending big bucks on native app development.
Indeed, if you are targeting a small amount of
devices, have a content-heavy application (as opposed to something like a
game that requires custom drawing and layouts) and offer a concise
amount of easily organized content, HTML5 app development might be a
very good solution for your needs. Many real-world applications,
however, don't fit nicely into this set of requirements.
Rendering Speed
The
first place that HTML5 applications show their limitations is in
rendering speed. Rendering is the process of turning the code into
something that can be displayed on-screen.
Native applications are compiled, so much of the
process of turning human-readable code into something the CPU
understands was done when the app was first developed. Often dynamic
content is displayed in compiled applications, but the code is usually
designed to efficiently transform this data into on-screen content.
Additionally, the screen drawing is optimized and often has a dedicated
graphics chip to help complete this task as quickly as possible.
(Remember that 30-60 times per second the screen is redrawn, so graphics
rendering is one of the most intensive processes that is happening)
HTML5 applications don't have the benefit of
pre-compilation*. When the app loads, the HTML content's markup code
must be read by the browser's rendering engine and turned into a
document object model (DOM) that the browser knows how to draw on the
screen. This process of interpretation is very fast, but it can be
enough to make an application feel sluggish, especially when the process
must be repeated many times. Additionally, this step requires a fair
amount of RAM to perform, and mobile devices don't have nearly the
amount of memory that desktop machines do.
* The authors of the web rendering engines are
constantly working to speed up the process of turning HTML markup and
Javascript into byte code, and there are attempts at performing
compilation-like steps inside the browser.
Native applications can perform many optimizations
to increase the speed and reduce the amount of memory required to render
content. HTML5 applications, however, can only be as fast as the
underlying web browser, and there are very few tricks beyond optimizing
your HTML markup that can be done to speed it up after that.
Native User Interfaces
Another
major problem with HTML5 applications (especially cross-platform ones)
is the lack of native UI controls. Anything displayed on-screen is
either a browser-rendered control, an image, or a CSS-created layout. If
you want to present a look-and-feel that is consistent with native
applications, you'll have to build these yourself using images and CSS.
For example, native iOS applications often display a
navigation bar with a title and back button to allow a user to navigate
through sections of an application. With native development, you get
these "for free" with the software development kit (SDK). If you want to
use this technique inside of an HTML5 application, however, you will
have to create images and CSS that mimic the native controls.
There are a number of projects that help you do
this, and often they are nearly indistinguishable from the native UI.
When you want to do this for a cross-platform application, you'll have
to write Javascript logic to detect what platform the user is on and
which set of UI "widgets" to use - iOS, Android, etc. Choosing to render
an iOS-specific checkbox vs an Android checkbox is pretty easy, but
some techniques aren't as easily swapped - for example, iOS presents
tabs at the bottom of the screen, where Android presents them at the
top. If you are going for a native "feel", you'll have a lot of work to
do to get it right on all platforms.
Often HTML5 developers work around this problem by
not trying to create a UI that looks exactly like the UI that is native
to a specific platform, instead providing a generic UI that can be used
on multiple target platforms. (the jQuery Mobile project does this very
nicely) The downside to this approach is that users will be less
familiar with the controls than the consistent ones that are idiomatic
to their platform.
Screen Size and Resolution
A
benefit of iPhone web application development is that you can count on a
screen that is 320x480 pixels*. Android device, however, are not
consistent - you will need to account for many screen sizes. This can be
extremely challenging when developing pixel-perfect layouts with HTML
and CSS. (To be fair: This is also very challenging when developing
native apps for Android)
* An iPhone retina screen has 640x960 device pixels,
but you still develop HTML and CSS as if there are 320x480 pixels and
the webkit rendering engine takes care of mapping the pixels properly,
though you will still have to create multiple versions of each image at
different resolutions
Access to Device-Specific Hardware and Features
When
developing applications that run inside of a browser, you don't have
access to everything the device offers. The iOS webkit browser, for
example, has no ability to access the user's address book, calendar, or
photo library.* These limitations can be overcome by frameworks like
Cordova - the authors of the framework have added "hooks" into the
device's hardware and given developers a way to access them through
Javascript. When a developer calls a Javascript function such as
navigator.compass.getCurrentHeading(), the underlying native
application (the one showing the web browser) uses its access to the
compass to get the heading, then it sends it back through Javascript to
the code that wanted the value.
These hooks are extremely valuable, but it requires
the authors of the framework to constantly stay on top of changes and
additions to the platform SDKs and add them to their code. If a feature
isn't of a high enough priority for the community, you might have to
wait for the features to be added (or pay someone to add them) before
you can use them in your HTML5 application.
* Browser access to the photo library is being added to iOS6
Stop and Look Where You Ended Up
If
you've accounted for the items noted above and created an HTML5
application that looks consistent across many devices and platforms,
consider what you've had to do to get here:
Write logic to handle multiple screen sizes and display images and CSS appropriately
Written separate user interfaces and layouts for each platform you are targeting
Wrote multiple navigation schemes that match each platform's user expectations
Wrote logic to show/hide features that are not available on certain devices
Created multiple versions of each image to handle retina displays
Hired a web developer who is familiar with the intricacies of cross-platform mobile development
An argument could be made that you didn't save a lot of time and effort to get this far.
The Facebook Dilemma
Described
above is exactly what Facebook has been doing with their mobile
applications for the past few years. They have worked extremely hard to
provide a consist experience across a massive variety of devices and
platforms. At the end of the day, users still complained loudly about
the speed and sluggishness of the applications. In 2012, they rewrote
their iOS application from scratch to provide a better experience to
their users.
Here are some links describing the effort:
A Hybrid Approach
There is a way to save development time when
creating native applications, especially ones that deliver a lot of
text-heavy content. I call it the hybrid approach:
Write
the chrome of your application as a native application. Make your tabs,
menus, navigation, tables, etc. using the native controls and layouts
of the platform. Make your application "feel" native to the platform
it's being used on so that users are familiar with the way it works and
operates. Use native performance optimizations to ensure that animations
and scrolling feel responsive and fast. On the detail/content screens
of your application, render that content using HTML, and make it reflow
properly so that it can be displayed at multiple screen sizes and
resolutions.
For example, say you have an application that allows
a user to browse a library of information about birds. The user will be
able to filter, search, and scroll through categories and lists of
birds, then they can view the entry about a specific bird with text and
photographs. The UI to filter, search, and scroll should be native to
the platform - this will ensure it renders quickly, efficiently, and
using UI idioms that the users are familiar with from other apps on
their device. When it comes time to create the content pages, write them
once in HTML and include them in the app on each platform. You'll save a
lot of time by writing the 1000 detail pages just once, and you'll
spend a few dozen hours writing the chrome/shell of the application for
each platform. As long as the text and images reflow properly in each
web container, you'll save yourself the hassle of trying to create
multiple copies of each page for every platform you are targeting.
Where Does HTML5 Fit?
At
this point, it sounds like we've completely written off HTML5, but that
isn't true. For the reasons outlined above, HTML5 is a poor choice for
many native application development projects. There are a few scenarios
where the technology can work very well:
- You are deploying to a limited platform of devices (non cross-platform apps)
- Your performance requirements are light
- You don't need deep access into hardware/sensors/APIs that the web browser can't access
- You aren't trying to emulate native UI
- You are developing the early version(s) of your application as prototypes
If
you are only deploying to a single platform, such as the iPad, then the
cross-platform UI considerations outlined above don't really apply. If
your content does not require lots of scrolling and heavy screen
drawing, the sluggish performance of HTML rendering won't be as much of
an issue. If you are primarily displaying content and media, then the
lack of access into the hardware sensors shouldn't be much of a concern.
If your UI is custom (and not trying to mimic native UI controls) then
the concerns over non-standard UI elements aren't a consideration.
If you are prototyping your applications, HTML can
be a much faster tool than native development, and it is much easier to
make changes to without recompilation and redeployment. You could also
develop the app in HTML to get it into the hands of customers, gather
feedback, and see what customers want. If nobody complains about the
performance and the app functions well enough to meet users'
expectations, then perhaps the extra pain of native development wasn't
necessary. As the programmer/author Donald Knuth said: "We should forget
about small efficiencies, say about 97% of the time: premature
optimization is the root of all evil."
Summary
In summary,
there is no "right" and "wrong" for HTML5 and native app development.
There are pros and cons to each approach and a thorough set of
requirements must be analyzed before making a decision. Beware the trap
of thinking HTML5 is an "easy win"; there are circumstances where it can
be a great alternative to native development and others where you'll
end up down a rabbit-hole of target-specific optimizations and hacks.
