Native apps for smartphones and tablets are still popular but not always necessary. Instead you can create web applications using HTML5, CSS3 and JavaScript. Thanks to the JavaScript APIs, you have access to the accelerometer, enabling you to recognize gestures and react accordingly. The web app manifest allows you to add classic app features to your web application, including special launcher icons and names that are shorter than the usually very long titles of HTML documents.
Create and "Install" a Manifest
If you have experience with programming native apps for Android or iOS, you are familiar with the setting options for apps. Besides setting a launcher icon and name, you can also define the preferred orientation or run the app in full screen mode – without action bar. These and other features can’t be set in HTML5, CSS3 or JavaScript, though. You will need the so-called web app manifest instead. This text file contains configuration settings in form of a JSON object. The manifest file is implemented as a link element in the head of the HTML document.
1
|
<link rel="manifest" href="manifest.json" />
|
It is important to specify the link with a
rel attribute to indicate the reference to the manifest file. We will define each web app feature in the manifest file in the following step. This manifest file is not to be confused with the identically named file you need for the "application cache". The latter is implemented by a <html> element instead of a link element.
Give the Web App a Native App Look
By changing a few settings in the manifest, you can make the web app look and act like a classical native app. This requires the web app to be started from a shortcut on the homescreen of the smartphone or tablet. To create such a shortcut, choose the Chrome menu item "Add to homescreen".
Chrome is currently
the only browser that supports the web app manifest.
In the manifest you can define a name for the homescreen shortcut that is shorter than the standard title of the HTML document. Although "name" and "short_name" are two different properties for the shortcut title, "short_name" overwrites the value "name". So, if "short_name" exists, "name" will be ignored.
1
2
|
"name": "Long name for web app",
"short_name": "Short name"
|
You can also use an individual shortcut icon and define size and pixel density. These are referenced by the JSON array.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
"icons": [
{
"src": "launcher-icon-36x36-1x.png",
"sizes": "36x36",
"type": "image/png",
"density": "1"
}
{
"src": "launcher-icon-36x36-2x.png",
"sizes": "36x36",
"type": "image/png",
"density": "2"
}
]
|
Depending on the device, the appropriate icon will be displayed according to the "sizes" and "density" values. If no accurate icon can be found, Chrome will choose the one that fits best.
Usually, a homescreen shortcut would open a normal website within the browser – including the navigation bar. To disable the navigation bar, use the property "display". Then the web app looks identical to a native app.
1
|
"display": "standalone"
|
The value "standalone" disables the browser’s navigation bar; the other value, "fullscreen", disables the "action bar" of the device. Especially games run in fullscreen mode. But don’t confuse it with the fullscreen mode of the browser. Currently, Chrome seems to not support the "fullscreen" property. Our test device ignores this property and uses "standalone" instead, which is the default fallback if fullscreen is not supported by the browser.
With a disabled navigation bar, the website’s URL is not visible anymore. But if you click on a link that leads to another domain, the browser shows a small status bar with the URL on top of the screen, so you will always know where you are.
You can also define the device orientation for the web app. The app will then run independently from the device orientation in either landscape or portrait mode – upright or vertical.
1
|
"orientation": "portrait"
|
Furthermore, it is possible to define a start URL for the web app. The web app starts with a separate URL.
1
|
"start_url": "webapp.html"
|
If this property is not set, it uses the URL from which the website was added to the homescreen. This allows you, for example, to force a web app to start with its homepage.
Sometimes a developer wants to know if their website was called up from the homescreen or as a normal website. To find out, you can divert "start_url" from its intended use by simply adding a parameter which can be used to determine call ups from the homescreen later.
1
|
"start_url": "webapp.html?homescreen=1"
|
You can query this parameter using JavaScript or a server-side scripting language. Then analytics tools can draw conclusions from where the website or web app was started.
Later Changes to Manifest Properties Not Possible
If a website was added as a shortcut to the homescreen, you can’t change properties for the shortcut anymore. If you want to change, for example, the value for "orientation", your users would have to delete the existing web app shortcut first, and add the website to the homescreen again. Only then the manifest file can be read.
Conclusion
Once a web app was added as a shortcut to the homescreen, it looks like a native app. With the appropriate HTML5 technique you can load the web app just like a native app on the smartphone or tablet (cue "application cache") and save settings via "local storage" on the device. An internet connection is not required to call up a website.
The only drawback with the web app manifest is the missing link to add the website to the homescreen. You will have to explain users that they need to to go to the browser menu and choose "Add to homescreen". Moreover, you will need the current version of Chrome (39) on your users' Android devices.
(dpe) 
A sample or complete example or online fiddle would have been a plus to this great article, hope you don’t mind editing it once again for us.
Bob
Thank you for this post! It certainly helped me a lot to learn more about web apps. It also told me that with a web app, things can get easier. But I was thinking, are there any drawbacks with using native apps as well?
Mark
I’m a big fan of the manifest for web apps. From a dev perspective it’s so much cleaner than having a bunch of meta tags for different characteristics, and of course good to standardize it. The manifest also start organizing the characteristics that makes a web app an “app”.
Also note how we are using this same app data to generate hosted web apps for the store in this other noupe.com post https://www.noupe.com/development/manifold-js-how-to-build-a-hosted-web-app-on-android-ios-and-windows-92331.html