Progressive Web Apps – Web App Manifest

The web app manifest is a simple JSON file that gives you, the developer, the ability to control how your app appears to users in areas where they would normally see apps in mobile devices.



Web app manifests are part of a collection of web technologies called progressive web apps, which are websites that can be installed to a device’s homescreen without an app store, along with other capabilities like working offline and receiving push notifications.

And, more importantly, how it behaves when it’s launched from the home screen.

Installs to the homescreen

When a user clicks “Add to homescreen”, they will see the app being added on the homescreen.

At a minimum, the manifest must contain the name of the app and a short_name.

The short_name is used on the home screen and in other places where there is limited space.

It also needs the start_url, the URL the app should open when launched from the home screen.

Defining the manifest metadata

"short_name": "Pandiyan",
"name": "Pandiyan Murugan",
"icons": [{
"src": "/img/portrait_small.jpg",
"type": "image/jpg",
"sizes": "192x192"
"src": "/img/portrait.jpg",
"type": "image/jpg",
"sizes": "512x512"
"start_url": "/?source=pwa",
"background_color": "#3367D6",
"display": "standalone",
"scope": "/",
"theme_color": "#3367D6"

Make sure, the page you specify is cached as part of the app shell. Otherwise, you won’t get the benefits of a cached app shell and your app won’t work offline.

One quick tip.

To track the number of users who are launching your app from their home screen, you can add a query string to the end of your URL.

And use any analytics to track launches, with that query string.

But don’t forget to ensure that you’ve cached the URL with the query string, in your service worker.

Adding icons and Splash screen color

Finally, we need to provide a set of icons for things like the home screen icon and the tab switcher, and splash screen.

The icons parameter takes an array of icons and must include the source, the size of the icon, and the type.

For example, image/jpg.

I recommend providing eight icon sizes,

48 x 48, 96 bx 96, 128 bx 128, 144 x 144,

192 x 192, 256 x 256, 384 x 384 and 512 x 512.

Just make sure you have icons for 1x, 2x, 3x and 4x devices.

Chrome uses the 48 device independent pixel icons for the home screen icon and the tabs footer. And the 128 device pixel icons for the splash screen.

Those are the minimum requirements. But there are a few other helpful things that you should set in the manifest.

The background color, and theme color are used by the browser along with an icon, as part of the splash screen.

Shown the instant the web app is launched, until its first render. As we provide the splash screen color as blue in manifest. The splash screen, icon and short name is displayed while the browser is rendering the application. (

Once the app is loaded, the theme color tells the browser, what color to display in the UI elements such as the address bar or the notification tray.

Display and orientation property give you control over how the app is displayed. For example, you can hide the address bar and the back and forward buttons, by setting “display”: “standalone”. Or if you’re building a game that works better in landscape, you can force landscape view by specifying, “orientation”: “landscape”.

Web apps will launch full-screen with no vestiges of a browser. The URL will not be present, nor will traditional browser actions such as bookmarking and navigation controls.

Linking the manifest

When you have created the manifest add a link tag to all the pages that encompass your web app:

<link rel="manifest" href="/manifest.json">

Manifest metadata in browser

To confirm whether the manifest is properly, we can use the chrome DevTools to view the manifest as below

(Switch to Application tab in the Chrome Dev Tools)


Happy Coding!

CORS Origin problem in C# Angular application

I’ve been working on some personal project which is built using angular and C#

The front end is built with Angular and backend (actually API) is built using C#

So technically both project has been deployed in different folders in my case.

Whenever I’m debugging and calling my API which is also running in debugging mode of local environment everything fine.

When I’ve deployed my API in IIS and tried access from the angular application which is debugging mode.

I have received the following error in my browser’s console as

No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

I have started looking a solution to this problem. I have started adding various headers in my angular httpclient, nothing works.

Later, found that we have to add access control header in server side. By default angular support and provides all the necessary things we need. So we don’t need to anything in angular application side

Then found a configuration which needs to be done in server side to avoid the cross-origin problem.

It’s pretty straightforward, we have to update our server-side configuration with the following change. In my case, it’s my C# API project web.Config

<add name=”Access-Control-Allow-Origin” value=”*” />

This one tweak allows us to add this custom header to all our API requests and provides us to access in cross-origin too.

That’s it.

Happy Coding!