Offline web apps
What is an offline web app ?
A web app is a HTML5 / JS / CSS software running within the browser.
Traditionaly, the frontend part of the web app (the code executed in the browser) is communicating via a REST API with one or more backends.
An offline web app can be used even if the user is not connected to internet or a local network.
Why using offline web apps ?
- More and more mature technological stack :
- Evergreen browsers : Modern browsers all implement offline web app mechanisms. Even better, they self update
- Frontend stack : JS frameworks such as Angular and Backbone helps building bigger application, RequireJS and Browserify allows modular building
- Backend stack : API REST are easy or coming natively with modern frameworks such as Rails, Laravel, Slim or Epiphany
- Ease of distribution : Installing a web app is as easy as visiting its URL from a browser
- Maintenance and updates : Updates propagate semalessly as the browser is in charge of it
- Portability : Web app can be run on mobiles, tablets and desktop browsers. They can even be embeded within app contaniners such as PhoneGapp.
Implementing an offline web app
To leverage offline capabilities, the web app needs to use the browser App Cache, via the manifest file. The browser then allows to access the web app even if the device is not connected.
The manifest file contains a list of assets that need to be stored for offline usage. This file typically contains the required CSS, JS and images file of the app.
The App Cache storage size depends on browsers. As of writing, a safe bet is 10MB for mobile (Safari) devices and 200MB+ for desktop (IE10+).
Note as well some precautions need to be taken when working with this capricious manifest file.
While the manifest file is ideal to store static assets with little need for change, other storage points must be used for the app actual data.
Possibilities and limits varies greatly depending on the user’s browser as you can see on this HTML5Rocks article.
Thankfully, Mozilla released localForage which abstracts IndexDB, WebSQL and localStorage with a common easy to use API.
The data storage solutions size depend as well on browsers. As of writing, 5MB can be leveraged on mobile devices (Safari) and 250MB+ on desktop (IE10+).
If excluding Safari mobile, 50MB can be leveraged on mobile devices.
App data managed by a backend is generally made available over a REST API. The web app, when online, access data via some API routes.
Part or all of it is stored (with localForage for example) for later offline usage.
Some data syncing mechanisms may be implemented, including optimisations (such as version numbers or hashs comparaisons before actual data transfer).
- Download from the server binary images and store them as binary objects. When retrieving them,
window.URL.createObjectURLare used to pass it to a dom image tag. Work for modern browsers and IE10+.
- Or download from the server binay images and store them as base64 objects (with
Canvas). Work for modern browsers and IE9+.
- Or download preprocessed base64 images from the server. Work for modern browsers and IE8+.
How to deal with bad browsers ?
As of writing, IE7 and 8 do not allow offline web app and Safari mobile and IE9 desktop do not allow more than 5MB data storage.
As of writing, these setup are not too bad :
- Dekstop : IE10+, Firefox, Safari, Chrome, 50MB+ data, 10MB+ assets (css, js)
- Mobile : Chrome, Firefox : 50 MB data, 10MB assets (css, js)
For B2B apps, the app can detect bad browsers, forbid using the app and give users Chrome installation link.
For B2C apps, either limit how much data is stored for offline use (by date, not the images, etc.), either detect bad browser and advise for a better one
When not to use web apps ?
- If native notifications mechanisms are needed (ie. iOS or Android notification bubbles or messages), as a web app cannot yet provide such features
- If the users will be using IE9- and Safari mobile
- if offlined data are big, such as videos (as a compromise, videos could be available online only)
- If the app demands high graphic performances, such as complex and very fluid animations (like for every web project ran in the browser)
In theses cases, Adobe Air or native developments should be considered.