Forem: Kevin Basset

10 real-life PWA examples you can learn from in 2025

Kevin Basset — Thu, 16 Jan 2025 03:11:29 +0000

1. Redmenta

Redmenta is an AI-powered platform designed to help teachers and students create personalized learning paths from existing lessons. The software generates learning activities for students and enables teachers to track progress.

As a Progressive Web App (PWA), Redmenta can be installed on any device directly from the browser, without the need for app store downloads.

Perfect example of a great modern app: built with React, powered by AI, beautifully designed, mobile-responsive, and distributed via the open web.

2. Fodmapedia

Fodmapedia is an app designed to assist individuals with Irritable Bowel Syndrome in managing their symptoms through a low-FODMAP diet. This PWA example, developed without code with Bubble, helps users identify which items are suitable for their dietary needs. As this is a tool meant to be used daily, the option to install the website as an app is available right from the home page:

Tap on “Install” and you’ll be guided through step-by-step instructions to add the PWA to your home screen. The instructions are smartly tailored to your specific device. With modern web technology, PWAs can now be installed from almost anywhere.

For users who may have missed the initial prompt, Fodmapedia offers a convenient installation link right in the header. This link takes you to a dedicated installation page, complete with app screenshots, detailed information, and even reviews.

Fodmapedia is a great example of a PWA that demonstrates how solving a clear, tangible problem for users can be achieved without code and distributed outside of app stores.

While the PWA format isn’t a universal solution for every app, it’s often the ideal choice for niche, informational apps that users rely on daily. Seamless integration, no commission fees on in-app payments, and effortless updates. It’s hard to beat that level of simplicity and efficiency.

3. Bingo em Casa

Bingo em Casa is a Brazilian sports betting and casino app that opted for the PWA format over native — a clear choice given that their app falls under prohibited categories on both Google Play and the App Store.

In fact, PWAs are an ideal solution for apps in sensitive industries such as gambling, adult content, crypto, cannabis, and health. With a PWA, you retain full control over distribution while still ensuring your app can live conveniently on users’ home screens, without having to ask them to download dodgy executable files.

Bingo em Casa encourages users to install its PWA directly from the login page. Installation is instant, and once the app is launched from your home screen, you’ll be prompted to enable push notifications. This flow is particularly effective — on iOS (starting with version 16.4), push notifications are only available in installed PWAs.

Unlike intrusive websites that present notification prompts immediately upon launch, Bingo em Casa thoughtfully waits until you’ve demonstrated meaningful engagement with the app before gracefully inviting you to opt in for notifications. Nicely done!

4. Nekodex

Nekodex is a crypto wallet app. Like the previous PWA example, it leverages the web format to sidestep app store restrictions while delivering a seamless user experience.

With its beautiful animations and polished interface, this web app is virtually indistinguishable from a native app once installed. Some developers assume PWAs are less visually appealing or less powerful than native apps. Nekodex proves otherwise, showcasing that yes, a PWA can look and feel super sleek.

Their cross-device installation approach is also very clever. Click “Launch App” in the top-right corner of their website to display a code. Scan the code with your phone, and you’ll be guided to install the app directly. Smart!

5. Run247

Run247 is a global community for trail and ultra running enthusiasts, offering news, events, and expert advice. Along with its sister app, Tri247, it has chosen the PWA format for distribution.

Unlike the primarily mobile-focused PWAs mentioned earlier, Run247 caters equally to both desktop and mobile users. A particularly nice touch is the “Add App” button located in the top-left corner of the site. With a single click, you can instantly install the app on your computer or phone, ensuring easy access across devices.

PWA installation isn’t limited to mobile devices — it’s also available on macOS (via Safari, Chrome, Brave, or Edge), Windows (using Chrome, Brave, or Edge), and even ChromeOS!

This PWA example handles the installation logic really thoroughly. For example, below is what happens if you click “Add app” while using one of the few browsers incompatible with PWA installation (mostly just Firefox on Desktop, really).

6. Fou d’la bouffe

Fou d’la Bouffe is a meal delivery service operating in Quebec and Ontario, a region where both French and English are spoken daily. To cater to this bilingual audience, the app is available in both languages. Upon loading the page, the app detects the user’s language and prompts users to install the PWA accordingly:

For a meal delivery service, securing a spot on customers’ home screens is of the utmost importance. And with advanced features like geolocation and push notifications, this PWA example perfectly shows what the web is capable of.

7. Music League

Music League is a cross-platform music discovery game. Like many native apps, its landing page offers a concise overview of the app along with installation options. However, unlike most native apps, Music League provides remarkable flexibility:

There’s no mandatory installation — you can play the game directly in your browser or choose to install it on your phone if you prefer. This is a brilliant example of how to leverage the PWA format effectively. By eliminating the friction of navigating traditional app stores, the developers of Music League increase adoption of their app.

Most native apps could provide a web option, but many avoid doing so because of the extra development effort. That’s where PWAs really shine — their biggest strength is having just one codebase that works the same way on every platform. Compare that to native apps, where an iOS app, an Android app, and a web app are basically three separate projects to build and maintain.

8. Sky Freebies

Sky Freebies is a platform that helps you discover great deals on free items and samples from various retailers offering promotions.

But as you can imagine, freebies don’t last forever! That’s why users need to check the site regularly to catch the latest offers. To make this even easier, they’ve added a handy installation widget that’s always available as you browse the site:

Once you install the app and launch it, you’re greeted with the content itself. Sky Freebies detects the display mode and tailors the user experience accordingly. The entire experience is a smooth, seamless journey — from visiting the homepage to launching the app directly from the home screen.

Sky Freebies also makes great use of push notifications, alerting you to new offers as soon as they’re added to the app. Of course, these notifications are entirely opt-in.

Interestingly, while the app is fully functional on the web, it’s also available for download on Google Play or the Windows Store. While Apple restricts PWAs, Google and Microsoft are more open to web apps. So, choosing the PWA format doesn’t mean giving up on users who are accustomed to the traditional app stores.

9. The Bedford Guide

PWA is an ideal format for local guides, and The Bedford Guide is a perfect example. It helps you explore the best restaurants, bars, attractions, and other hotspots in Bedford, UK.

Planning to visit Bedford? Simply install the website on your device for easy, on-the-go access whenever you need it.

Developed with WordPress, The Bedford Guide greets you with a pretty splash screen upon opening, just like a native app!

10. Photopea

Last but certainly not least, I have to mention Photopea, which, in my humble opinion, is one of the greatest pieces of software ever built on the web. In a nutshell, it’s a free Photoshop alternative, fully developed using web technologies like HTML, CSS, and JavaScript.

Like the other examples, you can install it as a PWA on your device. I have it in my Mac’s dock and use it almost daily. And it works so well that I honestly can’t tell it’s not a native app.

What’s truly remarkable about Photopea though is what it actually does. Enabling designers to tackle such complex tasks directly on the web was nothing short of genius.

Skeptical about the potential of PWAs? Try Photopea — it might just change your perspective.

Differences between background_color and theme_color in a PWA manifest

Kevin Basset — Wed, 18 Oct 2023 03:36:52 +0000

Every PWA has an app manifest. Within that document, you can define two key colors: the background_color property and the theme_color property. While the official W3C specs provide definitions for these properties, their practical applications might not be immediately clear. In this article, we'll delve into where and how each of these properties is used in practice.

About `background_color`

Let's start with the background_color. This property plays a crucial role in the visual presentation of your PWA on various platforms.

Android generates a splash screen for your app based on the background_color specified in the manifest. This creates a visually cohesive experience for users during the initial loading phase.

If you use Progressier, this color is also automatically used for the splash screens on iPhones and iPads.

This background_color parameter also controls the color of the body of a desktop app during its loading phase.

About `theme_color`

Now, let's explore the theme_color, which serves as the manifest equivalent of the theme-color HTML meta tag. Its primary role is to control the color of the status bar on your PWA.

theme_color is used while the app is loading. After the initial loading phase, browsers typically look to the theme-color in your code. If both exist, the meta tag property takes precedence.

In essence, the theme_color property in the manifest mainly influences the status bar's color during the splash screen phase. For post-loading color adjustments, it's more convenient to rely on the theme-color meta tag, which can be easily modified on the client side.

Note that the theme-color meta tag can also affect the URL bar's appearance in light mode. In dark mode, most browsers automatically choose a dark shade for the URL bar and its surroundings.

My Recommendation

To simplify your PWA development, consider using the same value for theme_color as you do for background_color. This approach ensures a seamless splash screen experience.

This recommendation becomes particularly evident when you look at the splash screen of this gag/demo app with different manifest theme_color properties.

If you want to change the color of the status bar after the splash screen has disappeared, simply modify the theme-color meta tag in your app's HTML:

Alternatively, with Progressier, this is how it works:

Fill color controls background_color and theme_color in your app manifest (so you get a perfect splash screen).
Status bar color controls the theme-color meta tag after the splash screen has disappeared.

Conclusion

In conclusion, understanding the roles of background_color and theme_color in your PWA manifest is crucial for ensuring a consistent and visually appealing user experience across platforms.

While background_color sets the stage during the loading phase, theme_color is most useful for controlling the status bar color during that same phase. For post-loading adjustments, opt for the theme-color meta tag, and consider using tools like Progressier for effortless color management.

How to fix iOS push subscriptions getting terminated after 3 notifications

Kevin Basset — Fri, 30 Jun 2023 03:28:49 +0000

With iOS 16.4, Apple has added push notifications to installed PWAs. However, you may have noticed that iOS push subscriptions appear to be automatically terminated after 3 push notifications.

You send a notification, then a second, then a third. Everything works fine. However, when sending the fourth, everything breaks.

Well, the good news is that it's fairly easy to fix!

TL;DR: It's a problem with your push implementation.

Of course, push subscriptions are never automatically terminated when implemented correctly. This would defeat the whole purpose of the feature!

(Side note: if you don't want to bother with these boring technical implementation details, go ahead and sign up for Progressier instead).

How to fix push subscriptions being terminated on iOS Safari

When you send a push notification to a subscribed user, the service worker for the matching domain fires a push event. The push event handler in your service worker is responsible for showing the notification to the user.

However, one very important detail that many implementations are missing is that your event handler must absolutely show the notification before the event itself terminates.

Notifications are displayed using registration.showNotification(). This function returns a Promise that resolves once the notification has been shown to the user.

Almost all cases of push subscriptions being terminated by Safari can be explained by push event handlers missing event.waitUntil(). This is a common issue. Even the sample code on MDN contains that problem:

❌ Incorrect:



self.addEventListener("push", function(e){
    self.registration.showNotification(e.data.title, e.data);
});

If you use the sample code above, push notifications won't work properly in the long run on iOS because the promise returned by registration.showNotification() will often resolve after the push event handler has finished.

❌ Also incorrect:



self.addEventListener("push", async function(e){    
  await self.registration.showNotification(e.data.title, e.data);
});

Making the event listener asynchronous and awaiting the registration.showNotification() promise to resolve looks like a very tempting solution. But you'll still run into the same issues.

Here is why: it's not enough for your event handler to wait for the work to be finished. You have to proactively tell the service worker what the event itself requires to be considered finished. This is counterintuitive because you rarely (if ever?) see that sort of behavior anywhere in client-side or server-side logic.

✅ Correct:



self.addEventListener("push", function(e){   
  e.waitUntil(   
    self.registration.showNotification(e.data.title, e.data)   
  );
});

This is a simplified example. In most cases, your code will do a few other things before invoking registration.showNotification(). Just remember to wrap that last bit in event.waitUntil() and remember that event.waitUntil() expects a Promise (not a function) as an argument.

So why are push notifications working in other browsers if my implementation is faulty?

This is because of a concept called silent push. A silent push occurs when the browser receives a notification but fails to display it to the user (or does so with a delay).

When you omit event.waitUntil(), Safari considers the notification to be a silent push because the event terminates before the notification is displayed (even if it is shown shortly thereafter).

Silent push has always been frowned upon across the board. In fact, when you register a push subscription, all browsers require you to configure it as userVisibleOnly, meaning you guarantee that you will only send notifications that you will actually show to users.

This is a security measure to prevent apps to do work in the background without users knowing about it. If you accidentally do 3 of those on Safari, the push subscription is canceled. Any further attempts would result in errors.

Other browsers have a different way of handling this. For example, Chrome does not invalidate push subscriptions, so as long as you call registration.showNotification() before the event handler terminates, you'll likely bypass Chrome's anti-silent-push security measure (which is to show a default This site has been updated in the background notification).

What seemed to work in many apps for years was always wrong. Many developers are claiming Apple released a bad push implementation — but this is not what's happening here. Apple's implementation is arguably closer to the W3C specs than Google's. If your setup worked in other browsers, it's essentially because... you were able to avoid the issue by chance. In any case, implement event.waitUntil() properly now. You'll eliminate timing randomness and make your implementation more future-proof.

That's it for me! Hopefully, now you know how to get around push subscriptions being canceled after 3 push notifications. If you have any questions, feel free to contact me here.

How to translate a PWA app manifest

Kevin Basset — Tue, 11 Oct 2022 03:38:22 +0000

As of October 2022, there's no native way to localize properties of the web app manifest in multiple languages. Although there's been an open request for that since 2018, so far there's no definitive way to achieve this with a conventional static app manifest file.

In this article, I'll tell you about the three methods you can use to localize your PWA manifest, including the one I'm using to provide the localization functionality at Progressier.

Method 1: Static app manifests

If your app has properly scoped language versions hosted at their own URLs, you can simply create different app manifest for each of them.

Say your English app is at https://example.com/en/ and your French app is at https://example.com/fr/, then you can simply host the manifests at https://example.com/en/manifest.json and https://example.com/fr/manifest.json respectively.

This would work similarly if your English app is at example.com and your French app is at fr.example.com. You'd then host your manifests at example.com/manifest.json and fr.example.com/manifest.json

The first drawback of that method is that browsers consider each entity unique PWAs. So when a user installs the English version from example.com, they'll be prompted to install the French version when they access fr.example.com.

Not great.

Counterintuitively, in this specific case, having overlapping scopes would actually be the better option.

The second issue is that this method violates Don't Repeat Yourself principles. In the long run, this is harder to manage and tends to lead to errors. It also doesn't scale well — if tomorrow your app is available in 20 different languages, do you really want to modify 20 different manifest files whenever you update your logo?

Method 2: Server-side dynamic app manifest generation

In general, one PWA = one app manifest. A PWA typically isn't updatable after installation if the URL of the manifest changes. So you should strive to keep the URL of the manifest unchanged as much as possible — even if it might be possible to do things a bit differently now thanks to the new id property.

A more scalable approach is to generate the manifest server-side instead of simply storing it as a static asset. This is the method I use at Progressier.

Browsers automatically add a Accept-Language header to every fetch request. The Accept-Language is determined based on the user's preferred language set in their browser. If you're using Chrome, you can define your own list of preferred languages at chrome://settings/languages.

Here is how to translate your manifest server-side:

Link to the manifest as usual in your client-side code. Simply add <link rel="manifest" href="https://example.com/manifest.json"> between the <head> and </head> tags in your HTML document.
In your server-side code, add a GET route for /manifest.json
Get the Accept-Language header
See if you have localized content that matches that header. If so, use it in your app manifest. Else, fall back to your default language.

Here is a complete example using Node/Express:

This is a user-level setting, and since the manifest is automatically fetched by the browser based on the meta tag you add to the <head> of the HTML document, it's not possible to directly overwrite the Accept-Language header.

In other words, it won't work hand in hand with a dropdown menu that would allow users to select the language themselves — it'll just still use their browser language.

<link rel="manifest" href="https://example.com/manifest.json">

The above does not offer any way to overwrite headers added to the fetch request for that specific asset.

There's one slightly convoluted way to achieve this: by intercepting the fetch request in the service worker, and then manually changing the Accept-Language. Since you'll need the service worker to be registered for that to work, the very first fetch request for the manifest might not return a JSON file in the right language. Plus, you'll have to make sure it uses the right caching strategy.

Method 3: Progressier

If you're using Progressier, localizing your app manifest is fairly easy. Since the platform is entirely no-code, all you have to do is click on the Localize button next to any of your manifest's parameters, choose a language, and translate. The rest is automatically taken care of for you.

In Progressier, you can localize any of the following manifest parameters: name, short_name, description, start_url, screenshots in any of these 108 languages: English, Afrikaans, Albanian, Amharic, Arabic, Armenian, Azerbaijani, Basque, Belarusian, Bengali, Bosnian, Bulgarian, Catalan, Cebuano, Chinese, Corsican, Croatian, Czech, Danish, Dutch, Esperanto, Estonian, Finnish, French, Frisian, Galician, Georgian, German, Greek, Gujarati, Haitian Creole, Hausa, Hawaiian, Hebrew, Hindi, Hmong, Hungarian, Icelandic, Igbo, Indonesian, Irish, Italian, Japanese, Javanese, Kannada, Kazakh, Khmer, Kinyarwanda, Korean, Kurdish, Kyrgyz, Lao, Latin, Latvian, Lithuanian, Luxembourgish, Macedonian, Malagasy, Malay, Malayalam, Maltese, Maori, Marathi, Mongolian, Myanmar (Burmese), Nepali, Norwegian, Nyanja (Chichewa), Odia (Oriya), Pashto, Persian, Polish, Portuguese, Punjabi, Romanian, Russian, Samoan, Scots Gaelic, Serbian, Sesotho, Shona, Sindhi, Sinhala (Sinhalese), Slovak, Slovenian, Somali, Spanish, Sundanese, Swahili, Swedish, Tagalog (Filipino), Tajik, Tamil, Tatar, Telugu, Thai, Turkish, Turkmen, Ukrainian, Urdu, Uyghur, Uzbek, Vietnamese, Welsh, Xhosa, Yiddish, Yoruba, Zulu.

It also works pretty well with the screenshots property. Progressier comes with a complete solution for designing and managing screenshots.

Questions? Feedback? Please let me know!

Why haven’t PWAs killed native Apps Yet?

Kevin Basset — Thu, 08 Sep 2022 02:04:38 +0000

Kevin Basset is the Founder at Progressier, a software toolkit used by 5,000+ apps to emancipate themselves from the app stores.

On paper, PWAs are the perfect alternative to native apps: only one code base to manage, instant updates that require no approval, and no commissions to pay on in-app purchases. What’s not to like?

Although Progressive Web Apps have gone a long way since their inception, they’re not quite at the point where they can act as a perfect replacement for native apps.

So… what is still missing in 2022? Why haven’t they become the default format for apps just yet?

The PWA identity problem

I’ve written about this specific topic in more details, but PWAs still suffer from their reputation of being second-rate apps — or worse, in some cases, of not being apps at all.

In 2022, the default behavior is still to go look for apps on either Google Play or the App Store. Funnily enough, installing an app directly from a website is both faster and more convenient. But users still aren’t accustomed to this without dedicated prompts and promotion elements.

At the core of the problem is the question of trust. Downloading an app from a third party means that the third party in question (Google or Apple) attests that the app is safe to download.

But here is the thing: PWAs don’t need Google and Apple‘s approval… because they’re already guaranteed to be secure — by design. A PWA can’t read your phone’s contacts, send SMS on your behalf, or access any of your phone’s features that could expose your private information.

The value proposition of an “app store” is twofold: logistics (installing your app on the user’s device) and promotion (getting more people to discover your app). Arguably, app stores no longer do such a great job at the latter. And the logistic of installing PWAs is embedded within the browser itself.

In 2022, the whole app store paradigm is redundant.

iOS push notifications

// Detect dark theme var iframe = document.getElementById('tweet-1533893843799748610-682'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1533893843799748610&theme=dark" }

After many years of seemingly hopeless wait, Apple has finally announced that push notifications will be coming to iOS in 2023. This is great news. Until now, you could send notifications to your Android/Windows/macOS users, but not to your iOS users.

For many developers, this meant that it wasn’t possible to rely on push notifications completely to deliver important information to their users. Web push notifications were a nice added bonus — not a crucial part of a product‘s workflows.

Provided that Apple implements web push notifications the right way (as in, following the W3 specs), this is about to change. You’ll be able to notify users on both Android and iOS with very little effort — and without having to list your apps on Google Play and the App Store.

That being said, web developers have abused the Web Push API so much (e.g. news websites requesting access on your first visit) that people have grown to detest these prompts. As a result, in some cases, Chrome (and other browsers) auto-blocks push notification requests — making it harder for developers with legitimate use cases to request access to this feature.

One of the top items on my personal wishlist would be for PWAs to be granted a higher authority than a regular website, once installed (but not quite as much as a native app). Getting people to install your PWA is evidence that they sort of trust it — they haven’t just stumbled upon your site.

A few examples of what higher authority could translate into:

Installed PWAs could automatically be granted access to the Push API.
Restrict access to the Push API to installed PWAs. Regular websites wouldn’t be allowed to request access at all. Goodbye BS spam.
Bundle requests to multiple browser APIs within the installation prompt. For example, when installed, a PWA could request to get automatic access to the Push API, the Geolocation API, or the Microphone API — with toggles for users to granularly allow or disallow each individually.
Or more modestly, Chrome could simply not auto-block push notifications when requested from within a PWA.

Native install prompt on iOS

Installing a PWA on iOS requires showing users custom instructions
Installing an app on iOS currently requires opening the Share panel and clicking on the Add to Home Screen button. This mostly does the job, but it isn’t as straightforward as installing a native iOS app.

If Safari implemented support for the beforeInstallPrompt event, the experience would be streamlined. Or at the very least, Apple could change the wording of Add to Home Screen to Install the app — Android has done exactly that a few years ago.

Although the current flow is an okay-ish workaround, it does have some unintended consequences that are detrimental to the experience for both users and developers.

For example, it’s impossible to distinguish between actual Safari (which has an Add to Home Screen button) and a SFSafariViewController view (which does not). For the record, the latter is used by a number of in-app browsers, e.g. the Twitter iOS app.

As a result, you have no choice but show your custom instructions… even when the option isn’t there. A tad confusing for users who may not be into that sort of technical nitpicking, aka 99.99% of users.

Similarly, I’m looking forward to the day when PWA developers no longer need to generate 25+ individual splash screen image files just to support every iPhone and iPad.

Better post-install manifest updates

PWAs would also become a lot more competitive if the developer was able to update the key details of the manifest (icon, name, splash screens, etc) after installation.

Google has a whole article about this, but I’ll give you the TL;DR: none of the properties you actually want to change can be changed. So once it’s installed, you can’t update how it looks on the user’s home screen.

Or at least, that was the case until very recently.

Luckily, there’s been some interesting developments in that area. Now, desktop Chrome supports changing the name of an app after it’s been installed. It even comes with a nice — albeit confusing — anti-phishing prompt so users can approve the change or uninstall the app.
// Detect dark theme var iframe = document.getElementById('tweet-1558484746564509698-609'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1558484746564509698&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1558432138067955713-135'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1558432138067955713&theme=dark" }

Better scope management

If there’s one area where PWAs really shine is programmatic app creation.

One of my customers at Progressier is a company that commercializes software for photographers. Photographers use that software to create unique wedding galleries for their own customers.

With Progressier, each of these galleries is a unique app with its own name (the name of the newlyweds) and icon (a photo of the couple). With 10,000s of such galleries, this would simply be impossible to manage any other way.

It doesn’t come without a few bottlenecks and gotchas, however.

While it’s generally preferable to host each PWA on their own subdomain (e.g. pwa1.example.com and pwa2.example.com), it’s often not possible. In this case, the second best option is to host each in its own directory (e.g. example.com/pwa1/ and example.com/pwa2/).

Managing scopes is very counter-intuitive because of what I like to call the trailing slash problem. In a nutshell, example.com/pwa1/ is a valid scope while example.com/pwa1 (notice the missing trailing slash) is not.

If you use the latter, browsers will instead consider the scope to be example.com/ (the root domain) — the problem is that there is no error message or warning. It just silently fails.

I wish browsers would be a tiny bit smarter and would automatically handle trailing slashes in the scope field. They could just auto-correct example.com/pwa1 to example.com/pwa1/. I don’t see any use cases where the former is not an error where the dev actually meant the latter.

Scopes could also be improved on iOS. Opening a link that's within the scope of a PWA from a third-party app on Android opens the installed PWA. However, on iOS, it opens Safari instead.

Desktop screenshots

The Richer Installation UI has definitely helped bridge the gap between native apps and PWAs. By including screenshots in the installation prompt, developers can show their app in action — and it looks and feels like a standard app store interface.

At Progressier, I went a bit further by providing a free tool for designing these screenshots in addition to integrating the tool into the product itself. So if you’re a Progressier customer, you can design, manage, edit, localize, and upload your screenshots within one interface. Kinda like Photoshop meets Google Play.

The screenshots property of the app manifest doesn’t currently do anything on desktop — but there is an active proposal to also display these screenshots on desktop Chrome. You can already test this by using the --enable-features=DesktopPWAsDetailedInstallDialog command line flag.
// Detect dark theme var iframe = document.getElementById('tweet-1547467531060883456-639'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1547467531060883456&theme=dark" }

What about native features?

Should PWAs ever be able to access your contacts? view your calendar? send SMS/MMS? set alarms? Personally, I would argue that they shouldn’t — ever.

The fact that PWAs are limited in their scope is the very reason why they are secure. Bypassing the browser limitations would set a dangerous precedent that would create an artificial need for a third-party approver (i.e. an app store) or a service like PWABuilder, hence invalidating the whole concept.

Of course, some apps do need access to these features. And for those, native is — and hopefully always will be — the only way to go.

But for the vast majority of apps that do not need access to these features, PWAs can not only be a great alternative —they’re increasingly becoming the best option.

When you consider the fact that more apps get built with Bubble, Softr, and other no-code platforms every day, it looks like this is the direction we’re headed.

And personally, I think this is awesome news for developers, users, and the web, as a whole.

Kevin Basset is the Founder at Progressier, a software toolkit used by 5,000+ apps to emancipate themselves from the app stores.

Why a PWA app icon shouldn't have a purpose set to 'any maskable'

Kevin Basset — Thu, 06 Jan 2022 04:54:38 +0000

A Progressive Web App requires a web app manifest, a JSON file that contains the details of your app (things like the name and icons of your PWA).

An app manifest must have an array of icons. Each of these icons has a purpose set to either monochrome, any ormaskable or a combination of these three values.

Why is "any maskable" discouraged by Chrome?

Lately, I've noticed quite a few PWA app manifests displaying a warning that until mid-2021 didn't exist (those created with Progressier always work great though!):

Declaring an icon with purpose "any maskable" is discouraged. It is likely to look incorrect on some platforms due to too much or too little padding.

{
…
"icons": [
{
"src": "icon2.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any maskable" // <-- triggers the warning
}
],
…
}


In this article, I'll show you exactly what Chrome means with that warning, but first I must explain what `maskable icons` are and why they exist.

## What are `maskable` icons?
Until a few years ago, app icons on Android could have a transparent background and use any shape they wanted. And that frankly made your home screen quite messy. Look at that Samsung Galaxy Note 4 from 2014:

![Home screen of a Samsung Galaxy Note 4 from 2014](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tg3zekcw3ih33dni1fs3.jpg)

Since then, smartphone vendors — probably in an effort to emulate iOS — standardized app icons. On a given home screen, every app icon has the same size and shape.

![Samsung Galaxy Note S21 vs Google Pixel 6 have different icon styles](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ntlr11okhwkitahxeb4y.jpg)
_Samsung Galaxy Note S21+ (Square icons with rounded corners) vs Google Pixel 6 (circular icons)_

_Thankfully_, the W3C folks came up with the [maskable icon](https://www.w3.org/TR/appmanifest/#icon-masks) feature. A maskable icon is one that has a safe zone that is cropped so that the icon can be displayed within a variety of shapes and occupy the entire space available.

(I say "_thankfully_" because just imagine the mess it would have become if developers had to provide a different icon for each possible shape.)

## Difference between `any` and `maskable`

Here is how a Android home screen renders the same PNG image with the purpose set to `maskable` (left) and set to `any` (right)
![Purpose set to maskable vs any](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7hoimei1exupph3jyg85.jpg)

## So why no `any maskable` icons?
In short, it's because it's very difficult to create an app icon that can be used as-is and as a mask. You'll almost always either have too much or too little padding.

## The perfect solution
Use [Progressier](https://progressier.com) to have icons perfectly sized automatically. Else to do it manually, create two 512x512 icons, one with the purpose `maskable`, and the other with the purpose `any`. Make your `maskable` icon fit the entirety of the area. And give your `any` icon 40 pixels of padding and 20% of border-radius (so that it looks great on all macOS versions).

{
…
"icons": [
{
"src": "icon2.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
},
{
"src": "icon2.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "maskable"
},
],
…
}


## Where do my PWA icons show?
Different platforms will use either of the two icons.
- On **Android**, the **home screen** and **install prompt** use the icon with the purpose `maskable`
- The **splash screen** generated by recent **Android phones** (post 2020) uses the icon with the purpose `maskable`
- Older or low-end **Android phones** may have a **splash screen** generated from the icon with the purpose `any` instead.
- **Chrome OS** uses the icon with the purpose `maskable`
- **Windows** uses the icon with the purpose `any` with all browsers, as it does not enforce any particular icon shapes
- **macOS Ventura** or lower uses the icon with the purpose `any`
- **macOS Sonoma** or higher uses the icon with the purpose `maskable`
- **iOS** requires an extra set of icons set with the `apple-touch-icon` (home screen icon)  and `apple-touch-startup-image` meta tags (splash screen)

Create a PWA from scratch with Vanilla JS

Kevin Basset — Thu, 30 Dec 2021 08:23:17 +0000

When COVID started spreading in China in January 2020, I took it upon myself to build The Coronavirus App. That simple PWA has since been used by more than 15 million individual users.

The problems I encountered while building that app then inspired me to create Progressier, a SaaS platform that makes it possible to add the entire block of functionality we call "Progressive Web App" to any domain without having to write any code.

In this article, I'll share some tips and tricks about what I've learnt developing PWAs from scratch with Vanilla JS.

Not so easy... but worth it

A PWA offers a sexy promise: only one code base to manage and your app works on all platforms. In practice, that means that you have to make that one code base do a lot more things than if you developed several standalone native apps.

The pros probably outweigh the cons most of the time. But it isn't black or white. Developers blindly promoting PWAs as a replacement for native apps simply haven't spent enough time developing PWAs. Native apps also have their place.

Don't go desktop-first... nor mobile-first

Until a decade ago, most websites were first and foremost optimized for desktop use. Then came mobile phones, and we started making websites responsive.

With PWAs, you can't think desktop-first. And you probably shouldn't think mobile-first either. A PWA created with Vanilla JS has to look and feel like a native app on mobile. But it also has to look like a proper desktop app on desktop.

These are two completely different UI paradigms — it's not just about the size of elements. For example, mobile UIs tend to display only one interactive element at a time while desktop UIs usually have many of them displayed simultaneously. Here are some concrete examples:

A standard dropdown menu on desktop becomes a bottom drawer with an overlay on mobile

Desktop accordion items become standalone full screen components on mobile

A side panel searchable list on desktop becomes a mobile search bar

As a rule of thumb, create one single HTML element and use CSS to style it. Often that will mean changing the element position from relative to fixed or absolute.

Sometimes, it isn't really possible. When developing a PWA with Vanilla JS, it's not uncommon to run into z-index issues. An element has to appear on top of a sibling of their parent container when it's open on mobile, while the parent has to appear underneath the sibling when it's not. When that happens, you'll have to implement a few tricks to modify the z-index of the parent dynamically with JavaScript.

When you design components for a PWA, start with the functionality, then design their mobile and desktop versions concurrently. And only then figure out what the right HTML structure should be.

Abstract away

Proponents of frameworks like React or Vue sometimes argue that Vanilla JS is too verbose and inefficient. They also argue that if you solve that by abstracting the browser APIs, you're essentially creating your own framework (aka "reinventing the wheel"). Below are two code snippets that do the exact same thing:

let onClick = function(e){console.log(e.target.value);}
let parentNode = document.querySelector('#parent')

//PURE VANILLA JAVASCRIPT
let input = document.createElement('input');
input.classList.add('cool');
input.addEventListener('click', onClick);
parentNode.appendChild(input);

//MY HOMEMADE VANILLA JAVASCRIPT ABSTRACTION
utils.node('input', 'cool', {parent: parentNode, click: onClick});

The benefits of my homemade abstraction are pretty obvious. 61 characters instead of 139 means you save time typing code and the browser saves time getting it from your server. Each HTML element being one line, your code also becomes easier to read and organize.

Yet both functions are semantically identical. They both create a DOM Node, add a class and an event listener to it, and append it to the DOM. Vanilla JS is about using the default browser APIs. Frameworks, on the other hand, are opiniated. They introduce their own preconceptions about how things should be done. Think how React uses JXS to create a hybrid HTML/JavaScript declarative style for example. Frameworks create different paradigms. Shortening the syntax of Vanilla JS doesn't fall into that category, in my humble opinion.

Ten years ago, jQuery was popular because it made things more consistent across browsers. Nowadays, most browser APIs are so well-built and documented that you probably don't need anything else. Another good example is Moment.js — dealing with dates and time used to be a pain in the ass. Now with the Date() interface, it's easy. And it's available in JavaScript.

So use Vanilla JS but build your own abstractions. Make it as simple as possible to write, understand, organize and modify your code. You're definitely going to need to be organized to make a PWA created from scratch with Vanilla JS work on all the platforms it has to support.

Design reusable components

Without a framework structuring your code for you, you have to be extra careful not turning your project into spaghetti code. What has worked well for me is create semantic silos / components. One component is a JavaScript function that contains everything that pertains to that component: the HTML, DOM nodes, event listeners, CSS, logic are all in the same place.

In addition to making your code more readable, it also makes it easier to iterate on your product. When you have to delete a component, you just remove the entire block of code. You can be sure it won't break anything else, and your code base never contains leftovers from previous iterations.

You don't really need to use frameworks to build components. In fact, you'd be surprised how easy it really is with Vanilla JS. And you don't even need the fancy class declaration either. Below is my basic structure for creating components.

function ComponentName(parent){
  let that = this;
  this.parent = parent;
  this.componentId = "component-id";
  this.styling = `
    .`+that.componentId+`{position:relative;}
    .`+that.componentId+`-inner{width:100%;}
  `;

  this.fetch = async function(){
    //do whatever async operations I need to do
    //e.g. query data of the component from DB
  }
  this.stylize = function(){
   //create a <style> node and set its id to that.componentId
   //set the content of the <style> node to that.styling
   //then simply append it to the DOM 
   //(or overwrite the content of an existing <style> with the same ID)
  }
  this.create = function(){
   //create a new container for the component
   //append it to that.parent
   //store it as that.element
  }
  this.render = function(){
   //empty that.element and recreate its inner content
  }
  this.init = async function(){
    await that.fetch();
    that.stylize();
    that.create();
    that.render();
  }
  //this component self-initializes when created
  this.init();
}

I can't recall ever needing more than that. It really does everything you might want it to do: create custom CSS, create a container, lets you wait for data from the network if needed, lets you re-render the container when data changes.

And because you're using Vanilla JS, you can structure each component slightly differently. For example, a different component may not be self-initializing like the one above. Or it may be invoked with completely different parameters, say data from another component.

Of course, there's probably a thousand other ways you could go about this that would work equally well.

Use the right tools for the job

Recommendation 1: Use libraries
Using Vanilla JS doesn't mean you can't utilize libraries that abstract some complex things that aren't available straight out of the box in the browser. The key is that these libraries should work in their own silo and not force you to rewrite your entire app around them. For example, don't build your own maps — use Leaflet.js. And don't build your own charts — instead, use Charts.js.

Recommendation 2: BrowserStack
You're going to have to spend a substantial amount of time testing your PWA in different browsers. Personally I'm a big fan of Browserstack. The platform allows you to test any web app or website on every browser/OS combination imaginable — even older devices. And these are real devices, not emulated devices. The $39 I pay every month for it are well worth it. I'm not affiliated with Browserstack in any way by the way.

Recommendation 3: MDN Web Docs
I absolutely love MDN. It's essentially a list of all APIs available to you in JavaScript. Each come with extremely comprehensive documentation. As a Vanilla JS developer, if you only allowed me access to a single site on the entire World Wide Web, that's the one I would pick.

Recommendation 4: Progressier
I built it so I'm obviously biased but I can't end the article without recommending Progressier. When building The Coronavirus App, it hit me that the entire block of functionality we call PWA (caching strategies, installability, push notifications) was unnecessarily annoying to implement. So I decided to build an abstraction for it — which you can add to your own app with a single line of code.

That's all folks!

Have you built a PWA with Vanilla Javascript yet? How was your experience with it? What other tools would you recommend using?

If this article helped you in any way, please consider leaving a comment below 🙏

Create a PWA app manifest dynamically

Kevin Basset — Tue, 28 Dec 2021 06:51:07 +0000

Every Progressive Web App has an app manifest, a simple JSON file that contains the basic information of your app, i.e. name, icon, description, etc.

If you just want to add PWA functionality to your existing web app, Progressier has everything you need (including dynamic app icons options). But if you want to create your own web app manifest dynamically, please read on.

How it's traditionally done

When building your first PWA, the simplest way to proceed is adding a link to your app manifest directly in the <head> section of your HTML template.

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

Host manifest.json anywhere on your site. The resulting JSON file should look like this:



{
   "short_name":"Coronavirus",
   "name":"The Coronavirus App",
   "background_color":"#ffffff",
   "theme_color":"#ffffff",
   "display":"standalone",
   "orientation":"any",
   "start_url":"https://coronavirus.app",
   "scope":"https://coronavirus.app",
   "icons":[
      {"src":"/icon512.png","sizes":"512x512","type":"image/png"},
      {"src":"/icon192.png","sizes":"192x192","type":"image/png"},
      {"src":"/icon196.png","sizes":"196x196","type":"image/png"}
   ]
}

Why you might want to do it differently

While the method above is a perfectly valid way of dealing with web app manifests, there are legitimate cases when a static file won't do and you'll want to generate it dynamically instead:

You need completely different icons on desktop and mobile
You want to host multiple distinct PWAs on the same domain
The PWA should look different for each logged-in user

And there are probably many more valid examples. To generate your app manifest dynamically, you have two options: build it on your server when it's requested by users. Or automatically generate it right in the browser (our preferred method).

Server-side dynamic app manifest generation

Rather than hosting the file as a static file on you site, make the path to /manifest.json an API, which will allow you to generate the content of the JSON file programmatically based on whatever your needs are. Here is an example using Node/Express:



app.get('/manifest.json', async function(req, res){
    //for brevity, we're not including the isDesktop function here
    let iconUrl = isDesktop() ? '/desktop.png' : '/mobile.png';
    let manifest = { 
       name: "App name",
       icons: [{
         src: iconUrl, 
         sizes: "512x512", 
         type:"image/png"
       }]
    }
    res.header('content-type', 'application/json');
    return res.status(200).send(JSON.stringify(manifest));
});

Client-side dynamic app manifest creation

Most people don't know that /manifest.json doesn't have to be an actual file. In fact, it works just fine with a Data URL.

I would even argue that a Data URL is a better way to go about this — even if you don't need to generate that particular asset dynamically.

No additional file to download from your server means faster load times and reduced server costs. And since the Data URL will be different every time you modify the content of your web app manifest, you don't have to worry about the browser not updating its content accordingly.

In your client-side code, here is how you can create it:



//for brevity, we're not including the isDesktop function here
let iconUrl = isDesktop() ? '/desktop.png' : '/mobile.png';
let manifest = { 
  name: "App name",
  icons: [{
    src: iconUrl, 
    sizes: "512x512", 
    type:"image/png"
  }]
};
let content = encodeURIComponent(JSON.stringify(manifest));
let url = "data:application/manifest+json,"+content;
let element = document.createElement('link');
element.setAttribute('rel', 'manifest');
element.setAttribute('href', url);
document.querySelector('head').appendChild(element);

At Progressier, we came across quite a few complex use cases of users needing completely different logos on their Android home screen, on their Android splash screen, on their iPhone splash screen and on their Windows/Mac installed PWA, so we've designed our dashboard accordingly.

Behind the scenes, we use these user settings to generate their app manifest dynamically with the methods above.

Questions or feedback? Leave a comment below!

Handling Opaque Responses in a Service Worker

Kevin Basset — Mon, 27 Dec 2021 08:47:12 +0000

Progressier handles opaque responses automatically so that you don't have worry about them. But if you're interested in learning more about opaque responses, why they're a problem and how you should deal with them in your service worker, please continue reading.

What's an opaque response?

When a website requests an asset, e.g. a JPG image or a JavaScript file, it sends a request to a server. This server then responds with the requested image or JavaScript contents.

Problems start when the asset is hosted on a different domain than the requesting site. Browsers follow a mechanism called Cross-Origin Resource Sharing (or CORS). In a nutshell, it greatly limits what you can do with a resource located on a different domain.

One way to prevent issues is for the owner of the resource to add a access-control-allow-origin: * header to the response (also works with your specific domain instead of *). It essentially tells the browser hey Chrome, just let anyone freely use that resource on their site.

Here is where it gets interesting — even without this header, <script>, <style> or <img> tags will still be able to request and use these resources. But your Javascript code or service worker won't be allowed to read or otherwise modify them. Responses that the browser can use but that you as a developer cannot are called opaque responses.

So... what's the problem with opaque responses, exactly?

When a server sends a response to a browser, it also sends a HTTP response status code, which tells the browser whether the request was successful or not.

Anything starting with 2xx usually means success. 5xx means there was an error with the server. And 4xx an error with the request.

For opaque responses, the response status code is always 0.

Your service worker has no way to know whether a request was successful or whether it resulted in an error. And because the request is made completely opaque, it does not contain any other clues that can tell you which way it went.

Editor's Note: I understand why opaque responses are necessary, but I honestly have no idea why 'opaque' also has to mean hiding the request status code. If anyone knows, I'm genuinely interested in learning more about the reasoning behind this choice.

The problem is that most apps and websites do receive quite a few opaque responses. And if you choose not to cache them, these resources won't be accessible offline at all when the network fails to send a successful response.

Approach 1: The Last Resort Approach

The approach we use at Progressier is to cache resources that have opaque responses but only serve them as a last resort — when there is no other response available in cache and the network couldn't provide a response (because that server is down or the user is offline for example).

In that case, the choice is between showing an error (100% probability of error) versus showing an opaque response that may or not have been a successful response (unknown probability of error but by definition less than 100%).

Approach 2: The No-Cache Approach

The default behavior in Workbox is to not cache opaque responses at all. This is another valid approach. It eliminates the uncertainty described above and it also ensures that the resource will NOT be available offline.

In cases where your front-end actually need to know what the error is (not just know that there is an error), this approach provides consistency and may be a better alternative.

Recognizing and caching opaque responses

An opaque response can be identified by the status code in the Response object. If it contains response.status === 0, then you're dealing with an opaque response.

Note that what you can do with opaque responses caching-wise is limited. You'll necessarily have to call response.clone() before putting it in cache. If you don't, the body of the response will be consumed when you put in cache and it will fail when you also return it as a response to the fetch event.

Response.clone() sometimes isn't enough, i.e. if you need to alter the response before putting in cache. That's why you can usually make a copy of the headers and body of the request, and recreate a response from scratch using the Response constructor.

Well, with opaque responses... you can't do that. The constructor simply doesn't allow to create opaque responses.

Conclusion

When building Progressier's caching strategy builder, I had quite a bit of fun figuring out the inner workings of service workers. And opaque responses were definitely one of the highlights! Their quirks can be hard to grasp at first, but once you understand how they behave, dealing with them becomes a lot easier.

If that article helped you understand anything about opaque responses, leave a comment. And if you have any questions, feel free to reach out to me 💪🎉😜

How to force a PWA to refresh its content

Kevin Basset — Fri, 17 Dec 2021 06:05:33 +0000

One of the most common questions we get asked at Progressier pertains to client-side caching. How does one ensure a PWA always displays up-to-date data and assets while also making good use of caching?

Although a PWA often looks and feels like a native app, from a technical perspective it really just works like any other website. When one opens a page, it loads assets (images, scripts, stylesheets…) and data (user data, product data…). These resources are fetched from the network and then used by the browser.

Enter the HTTP cache mechanism. In order to make loading websites faster, browsers cache these resources. On the initial load, an image will come from your server. On the following load, it may come from the cache instead. So if you update it in the meantime, the browser may display a stale version of that image. How can you prevent that?

The Versioning Trick

Versioning is probably the easiest way to force the browser to load a resource from your server. When you update a resource, add a parameter to the URL of the resource wherever your request in your code. For example, edit your client-side code to request domain.com/data.json?version=2 instead of domain.com/data.json?version=1.

A browser will see these two URLs and consider them completely different assets. So it won't use a cached version of the former when the page explicitly requests the latter. A good practice is to append a version number (or any other query strings, really) to key resources in your build process, so you don't have to do that manually every time you make a change.

The Cache-Control Header

When a server responds to a HTTP request successfully, it returns the asset itself (a JavaScript file, an image, a CSV file…) but it also sends headers - parameters that tell the browser what they are allowed or not allowed to do with the resource.

One of these headers is the Cache-Control header. It exists specifically so you can tell the browser how a particular resource should be cached (or not) and revalidated (or not).

If you control the server that responds to the request, you can set different Cache-Control headers and tell the browser how it should treat each particular resource. For instance, set the value of the Cache-Control header tono-cache to forbid the browser to cache the resource at all.

Of course, this method only works with resources that you own - not third-party scripts, CSS libraries, Google fonts or images hosted somewhere else.

The Network First Strategy

Truth be told, the HTTP Cache mechanism is a bit antiquated. With it, all you can really tell the browser is whether or not a resource should be cached and until when.

There is another caching mechanism called the Cache API. And it's available in service workers. Progressier uses that API for its caching strategy maker. You can define very specific rules for each type of resources without having to write a single line of code.

Use Network First and target all resources to prevent caching altogether. With the Network First strategy, resources will always be fetched from the network exclusively (so an error will be thrown if the network is somehow unavailable, e.g. if the user or the server go offline).

Of course, most of the time, you'll want to be more specific and apply that strategy to resources that are mission critical and use more caching-friendly strategies for less essential resources (Stale-While-Revalidate for example).

The Fake Reload Button

With the first three methods, you're essentially telling the browser whether a particular resource should be retrieved from the cache or the network when the page is loaded.

But once installed, opening a PWA may not always trigger a new page reload. You can launch a PWA from your home screen, do what you have to do with it, then launch another app, and go back to the PWA the next day.

If you haven't closed the app or turned off your phone in the meantime, it will not reload the page - instead it will simply allow you to continue your session where you left off. If you, the app owner, updated resources in the meantime, then the user may still be using stale resources. How can you force the PWA to refresh its content then?

When we launched The Coronavirus App in January 2020, users were very demanding when it came to data freshness. We updated data every 15 minutes automatically, so it was absolutely critical to not let users see stale data (or we would receive tons of angry emails!).

But rather than wait for actual updates, we used a simple trick: when the user had spent more than half an hour on the page, we would present them with an option to reload the page (which they had no other choice but click) and fetch resources again. It looked like this:

Giving the illusion that something is happening is a powerful UX concept. In our case, the purpose was two-fold: make it look like the app was updated constantly (which it actually was - just not in a synchronized manner with that fake reload button) and avoid showing data.

Conclusion

So there you go. Three different caching methods to ensure your PWA stays updated and one little UX trick.

The versioning trick is probably the easiest way to go about this - and it works universally, whether you own the requested resources or not.

And if that's not feasible easily in your build process, you can either use the Cache-Control header (for resources you own) or the Service Worker method to granularly define caching behaviors.

What do you think? Do you use other methods to keep your PWA updated?

Forem: Kevin Basset

10 real-life PWA examples you can learn from in 2025

1. Redmenta

2. Fodmapedia

3. Bingo em Casa

4. Nekodex

5. Run247

6. Fou d’la bouffe

7. Music League

8. Sky Freebies

9. The Bedford Guide

10. Photopea

Differences between background_color and theme_color in a PWA manifest

About background_color

About theme_color

My Recommendation

Conclusion

How to fix iOS push subscriptions getting terminated after 3 notifications

How to fix push subscriptions being terminated on iOS Safari

So why are push notifications working in other browsers if my implementation is faulty?

How to translate a PWA app manifest

Method 1: Static app manifests

Method 2: Server-side dynamic app manifest generation

Method 3: Progressier

Why haven’t PWAs killed native Apps Yet?

The PWA identity problem

iOS push notifications

Native install prompt on iOS

Better post-install manifest updates

Better scope management

Desktop screenshots

What about native features?

Why a PWA app icon shouldn't have a purpose set to 'any maskable'

Why is "any maskable" discouraged by Chrome?

Create a PWA from scratch with Vanilla JS

Not so easy... but worth it

Don't go desktop-first... nor mobile-first

Abstract away

Design reusable components

Use the right tools for the job

That's all folks!

Create a PWA app manifest dynamically

How it's traditionally done

Why you might want to do it differently

Server-side dynamic app manifest generation

Client-side dynamic app manifest creation

Handling Opaque Responses in a Service Worker

What's an opaque response?

So... what's the problem with opaque responses, exactly?

Approach 1: The Last Resort Approach

Approach 2: The No-Cache Approach

Recognizing and caching opaque responses

Conclusion

How to force a PWA to refresh its content

The Versioning Trick

The Cache-Control Header

The Network First Strategy

The Fake Reload Button

Conclusion

About `background_color`

About `theme_color`