HTML and CSS Reference
On top of that, updates have to be downloaded by the user, so beyond a marketplace prompt, your
encouragement, and notes in the support docs, there's nothing to guarantee that a user ever gets the latest version of
With a web app, rather than rolling out fixes to the Android, iOS, BlackBerry, and Windows Phone versions of the
app, only one version of the code—assuming the app is built to be responsive—needs to be updated to clean up issues
on any device for which the app is designed.
When creating a web app, it's an effort to create a “one size fits all” app. Therefore, it requires diligent testing on all the
devices it needs to support. Ideally, it should even be tested across different versions of each platform.
Native apps present similar issues to testing a website for cross-browser support: a fix for iPhone might introduce
a new bug on Android, a change in one version of Android might have an unexpected side effect in a different version
of Android, and there's always the possibility that a certain feature just can't work the same way on every device.
If your app needs to access the device's accelerometer or camera, the argument is over unless you know exactly what
web browser your users will be using on their phone. For example, to access the webcam on a device from a browser,
you use the getUserMedia API, which isn't supported by the latest versions of even the mainstream browsers; 14 as
ever, Chrome, Firefox, and Opera are leading the way.
If you don't know whether all the users of your web application will have support for all the features it requires ,
your best choice is to create a native app.
Operating systems expose access to most hardware features to native apps. Browsers are slowly exposing access
to these features, but again they're not available cross-browser. One such example is orientation control. In some
applications, you may always want the user to be viewing in landscape mode—for example, a racing game—but
although there are ways of detecting orientation initial state and changes, there isn't an API to control this in a web
browser right now, so the only solutions are effectively hacks. 15
Modern mobile web browsers are constantly evolving, and the number of browsers that do provide APIs that
enable access to hardware and other operating system features are increasing all the time. But right now, native
applications have the edge by providing complete control over the hardware and OS features that the application
We live in an increasingly connected world, so it's no surprise that a lot of applications rely on connectivity.
To initially fetch our application, native or web, we need an Internet connection. A lot of the features offered by
applications also require a connection, such as any piece of functionality that makes use of other Internet services or
APIs (for example: public transport apps, features that synchronize your information across devices such as to-do or
note-taking applications such as EverNote, or mapping applications that in no way could store all the information a
user could potentially request).
Some of these applications, such as EverNote, can still provide useful functionality while offline. But others, such
as Skype, can't offer any of its core functionality without a connection. They may as well refuse to open.
Once a native app is downloaded on your device, all the resources (in most cases, at least) are now stored on the
device, meaning it should be possible to use it offline. But many applications assume connectivity leading to a very
frustrating user experience.