Author: Nitya Narasimhan [@nitya](https://twitter.com/nitya)

Welcome to Day 4 of #30DaysOfPWA! Want to learn more about this project? Check out our Kickoff post to get more details on the content roadmap and contributors. Now, let’s dive in!

Let’s Recap

What we learned so far:

• PWAs are web apps by default. They can provide a usable experience across all devices and platforms, from a single codebase.
• PWAs use progressive enhancement to scale up their experiences to suit richer platform capabilities. They can feel indistinguishable from natively installed apps in that context.
• PWAs use open web technologies to implement this behavior. Core building blocks are HTTPS, Web App Manifest and Service Workers. New web capabilities unlock even richer experiences on supporting platforms.
• Web App Manifests are like app resumes - providing identity, branding and skills information that is needed for app installation (on device) or publishing (to app stores).

What we’ll cover today: We’ll explore the remaining building blocks (HTTPS, Service Workers) with specific focus on using Service Workers.

PWAs are like startups!

To set the stage, let’s use another analogy. We previously talked about how Web App Manifests are like app resumes. Now think about the PWA like a startup - with each technology being a founding team member with a specialized purpose that helps deliver a progressively-enhanced experience.

• The app page is the CEO - it drives the core experience and remains responsive to user needs and interactions.
• The Web App Manifest is the resume - it describes app identity, brand and capabilities to devices and app stores for installability.
• HTTPS is the Chief Security Officer (CSO) - it encrypts end-to-end communications between app and server endpoints for safety.
• The Service Worker is the Chief Operations Officer (COO) - it unblocks the CEO from performing time-consuming or synchronous tasks, and takes proactive actions to ensure reliable operation even when offline.

Let’s see how this translates to PWA implementations that support desirable traits like safety, network-independent operation, and re-engageability. And in particular, we’ll explore service worker implementation and usage, to make this happen.

Make PWAs Safe

HTTPS enforces end-to-end encryption of all client-server communications, providing privacy safeguards for information exchanged over the network. Visualize this as a Chief Security Officer locking down all entry and access paths into your startup and protecting information from malicious third-party access or tampering.

HTTPS support is mandatory for using Service Workers. Thankfully, as we covered in our earlier post, it is easy to implement HTTPS support. Use modern cloud hosting providers (who enable it by default) or take advantage of free certificate options (e.g., Let’s Encrypt) to secure your own servers.

Make PWAs Reliable & Re-Engageable

Service Workers are a special type of Web Worker. Web Workers operate in a separate thread, allowing them to execute long-running or asynchronous tasks in the background, minimizing the impact on page performance (“unblocking” the CEO).

Service Workers make PWA operation reliable by helping deliver usable experiences even under flaky or offline network conditions. They do this by intercepting network fetch requests from the page (CEO) and strategically handling them using cached responses (if offline), or network-fetched resources (if real-time), or some combination of both based on predefined caching strategies for resource types.

Service Workers make PWAs re-engageable by having the ability to alert users to app changes or context, even if the page itself is inactive. They do this by listening for asynchronous push notifications (from a server) and working with platform capabilities to deliver alerts in a device-familiar way. When users engage with the alert, they are drawn back into the app seamlessly - just like with other native app experiences.

How do Service Workers work?

From a development perspective, we need to know two concepts: * Service Worker Registration - where CEO “hires” the COO. * Service Worker Lifecycle - where COO “handles” operational events.

Let’s look at registration first. Like all Web Workers, the Service Worker must be authored in its own file. The location of that file (relative to the root of the app) defines the scope of its authority. Service Workers can only intercept or manage requests to pages within their scope. Placing the file at the root of your app ensures your service worker will manage all pages within it.

Let’s inspect the DevTools Tips PWA in the browser again. Look at Service Workers under the Application tab. We can see that the service worker is implemented in the “sw.js” file in the root directory - implicitly setting its scope to the whole app.

If you inspect the application source (in Elements tab) you will find this snippet of code for service worker registration:

if('serviceWorker' in navigator) {
    // Register the service worker
    navigator.serviceWorker.register('/sw.js', {
        scope: '/'
    });
}

Because Service Worker is a more recent technology that may not be supported on all browsers, we test for its existence before registering it. The scope is set implicitly by the file location - the code shows how you can explicitly set this if needed.

Service Worker: Lifecycle Events

Service worker registration is like onboarding the COO. Once that is complete, the service worker is ready to listen for lifecycle events (install, activate) to set itself up for success. Think of this as three phases:

1. Registration: The browser registers the service worker, kicking off the Service Worker lifecycle.

2. Installation: The browser triggers install as the first event to the Service Worker. It can use this for pre-caching resources (e.g., populate cache with long-lived resources like logos or offline pages).

self.addEventListener( "install", function( event ){
    console.log( "WORKER: install event in progress." );
});

3. Activation: The browser sends the activate event to indicate that the service worker has been installed. This service worker can now do clean up actions (e.g., remove old caches from prior version) and ready itself to handle functional events. If there is an old service worker in play, you can use clients.claim() to immediately replace the old service worker with your new one.

self.addEventListener( "activate", function( event ){
    console.log( "WORKER: activation event in progress." );
    clients.claim();
    console.log( "WORKER: all clients are now controlled by me! Mwahahaha!" );
});

Service Worker: Functional Events

Functional events are those that require the asynchronous or background processing abilities of service workers to support reliable and re-enageable behaviors. For now, think about just two: “fetch” and “push”.

1. The fetch event is triggered when the browser tries to access a page that lies within the scope of the service worker. The service worker acts as an interceptor - returning a response either from the cache or from the network (or some combination of both) based on predefined strategies. We’ll cover more on this in the next post.

self.addEventListener( "fetch", function( event ){
    console.log( "WORKER: Fetching", event.request );
});

2. The push event is triggered when the browser receives a push message from a server to display as a toast notification to users. This occurs only if the PWA had previously subscribed for server notifications and user has granted the PWA permission to receive them. Push events are critical to re-engaging users when the app is not otherwise active.

self.addEventListener( "push", function( event ){
    console.log( "WORKER: Received notification", event.data );
});

In our next post, we’ll dive into details of service worker support for offline operation - looking at how service workers engage with the Fetch and Cache Storage APIs to provide continuity of experience in a network-independent manner. For now, it’s time for a hands-on exercise!

Exercise: Explore Service Workers

Use DevTools to inspect a different sample PWA and see if you can identify and understand the service worker hooks and implementation:

• Go to Elements tab and explore the application source
  • Where is the service worker registered?
  • What is the scope for registration?
• Go to Applications tab and explore the service worker file
  • What events is it handling?
  • Can you understand its caching strategy (for fetch)?
  • Is it re-engaging the user (with push)?
• Go to the Cache Storage section
  • What files or assets do you see stored there?
  • How do these correlate to actions taken for install event?
• Go to the Service Workers section - click “Offline”
  • What happens when you reload the page?
  • What happens when you go to a different site (offline)?

Author: Nitya Narasimhan [@nitya](https://twitter.com/nitya)

Welcome to Day 3 of #30DaysOfPWA! Want to learn more about this project? Check out our Kickoff post to get more details on the content roadmap and contributors. Now, let’s dive in!

Let’s Recap

• Day 1: We learned PWAs are web apps that are progressively enhanced to deliver experiences that scale to device and platform capabilities. They can behave like native apps on richer platforms and fall back to regular website behavior on less capable ones.
• Day 2: We learned this is enabled by open web technologies like Service Workers, Web App Manifest and HTTPS and support for modern Web APIs. These enable desirable PWA characteristics like installability and network independence in a cross-browser compatible way.

Plus, we picked a Sample PWA to look at as we explore the concepts. Now, let’s dive into PWA building blocks, starting with manifests.

What is a Web App Manifest?

Installability is a desirable PWA characterstic that allows it to be added to a device home screen and behave like other native apps - e.g., users can launch them, pin them to Taskbar, find them through device search etc.

The Web App Manifest is an open web specification of a JSON format that is critical to making PWAs installable. Functionally, it governs how your PWA looks and behaves when installed on device by defining the properties (key-value pairs) that characterize its appearance and behaviors. In other words, it describes details about your web app, such as your app name, description, icons, and more.

A Sample PWA Manifest

Let’s take a look at what a real manifest looks like using a Sample PWA. I’m using DevTool Tips - and I can view its manifest in two ways: * From runtime. In yesterday’s post we learned to inspect the app with browser DevTools to find the Manifest section under the Application tab. * From source. Look for a manifest.json file. Apps may choose to use a app_name.webmanifest naming convention if they serve it with an application/manifest+json MIME type. You can find a <link rel="manifest" href="manifest.json"> inside the <head> tag of the page. The href will specify the file name of the manifest file.

Here’s what my sample PWA’s manifest.json looks like.

{
    "name": "DevTools Tips",
    "short_name": "DevTools Tips",
    "start_url": "/",
    "categories": [
        "productivity",
        "devtools",
        "browser",
        "education"
    ],
    "display": "standalone",
    "background_color": "#ffffff",
    "theme_color": "#ffffff",
    "scope": "/",
    "description": "A collection of useful cross-browser DevTools tips",
    "icons": [
        {
            "src": "/assets/logo-192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "/assets/logo-512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ],
    "screenshots": [
        {
            "src": "/assets/screenshot-home.png",
            "sizes": "1992x1773",
            "type": "image/png"
        },
        {
            "src": "/assets/screenshot-tip.png",
            "sizes": "1992x1773",
            "type": "image/png"
        }
    ],
    "url_handlers": [
        {
            "origin": "https://devtoolstips.org"
        }
    ]
}

Manifests are like App Resumes

That’s a lot to take in right? It helps if you can put these properties into a few buckets - here’s what I see: * Identity - e.g., name, categories, starting URL. * Characteristics - e.g, icons, colors, screenshots. * Capabilities e.g., url_handlers

Wait - doesn’t this remind you of a resume? The identity information, the profile headshots, the list of skills? That’s exactly how I think of it:

• A Web App Manifest is like a resume for the application.
• The browser is where the application currently “works”.
• Installability is the “interview” to work in a new place (on device).
• Discoverability is helped by “publishing” app resumes (to app stores).

The visual explains how this analogy works for PWA.

The browser is like an amazing workplace where people look out for your success. PWAs are apps “working” there - they keep an updated “resume” (manifest) and “link” it in their HTML to tell the browser they can work “remotely” (on device). The browser uses it to “advertise” this to users (“Install This Site As An App”). Make sense?

If the user clicks that Install prompt, it triggers an “interview” between app new workplace (device), The latter looks up the resume for details (profile, appearance, skills) and adds it to its local “workplace directory” just like other native apps. Users can now launch the app, or discover it using device-specific search features. And, users and other apps can now target this app for tasks matching its listed capabilities (“url handling”). Isn’t that neat?

But wait - there’s more. The PWA can also list its resume in app stores just like native apps (publish to e.g., Microsoft Store for Windows devices). When users Install from app store, they just trigger the same interview process. Installability and discoverability for the win!

Creating an Web App Manifest

From a PWA developer perspective, creating a manifest involves: * Create a manifest.json and populating its properties. * Linking it to app HTML to advertise your PWA status. Ex:

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

Create your manifest with any text editor or IDE - just make sure your JSON is valid. Start with a minimal manifest to get a working PWA. Then iteratively add new members to improve PWA experience. Then add capability-driven attributes related to Web APIs you support.

Audit your PWA with tools like PWABuilder to find, and fix, issues in your manifest so you can deliver a best-in-class PWA experience to users.

What does a minimal manifest need?

The specfication defines a number of member attributes - but a suggested minimal manifest should have at least these three - where start_url defines the entry point (default path shown) when app is launched on device.

{
    "name": "My Sample PWA",
    "lang": "en-US",
    "start_url": "/"
}

A user-friendly description of the supported members can be read here - let’s see what our sample PWA is declaring for instance: * short_name - app name for constrained spaces (e.g., home screen) * categories - hints for stores or app catalogs. (See W3C examples) * display - how much of browser UI does user see in app? * background_color - placeholder to show (before stylesheet loads) * theme_color - default theme color for app * scope - what web pages can be viewed (navigation scope) * description - what is the app about? * icons - array of icon images used in various contexts * screenshots - showcase application UI/UX (e.g., for app stores)

What is a good manifest?

A good Manifest provides additional properties that help deliver the optimal experience for the user on that device. This can include: * adding recommended members and experimental members * adding properties to unlock new capabilities on device.

For the first part, an actionable step to use audit tools like PWABuilder that grade manifest quality and help fix issues interactively (see example below). Look for our Week 3: Developer Tools coverage for more details.

For the second part, we talked about two things

Experimental members. These are manifest members that are being evaluated for future inclusion, but subject to change. Browser platforms may offer early implementations under a flag for evaluation - but keep in mind that these could change, and be unevenly supported across browsers.

• Example: Our sample PWA declares a “url_handlers” member. This is an experimental feature that allows the app to register itself as a launch target when user wishes to open associated URLs. There is now a proposal to replace this with a “handle_links” member instead.

Web capabilities. The manifest can be used to declare support for using new Web APIs that unlock app access to rich platform hardware and features.

• Example: The “share_target” (used with the Web Share API), activates PWA ability to share content with other apps like any other native app. Watch for Week 2, when we talk about advanced capabilities.

One last thought. Remember our analogy for the manifest being a resume for the PWA? Where manifest “members” reflect different sections related to identity, characteristics and capability?

Think of web capabilities and other open web technologies (e.g, Service Workers) as being a rolodex of team-mates that this app can call upon, to get the work done. They can now list those skills on their resume because it’s a skill they are capable of. However, their ability to do that job on a given device is dependent on the availability of those teammates. Think of “feature detection” as equivalent to making a call to see if the required colleague is around before committing to support that task.

Exercise: Inspect Sample PWA Manifest

We covered a lot today - and now it’s your turn to learn by actively exploring the concepts. Pick a different Sample App.

• Inspect it’s Manifest in DevTools. What members did it define?
• Audit it with PWABuilder. What gaps did it identify?
• Explore the Manifest.
  • Are any experimental members in use? What do they do?
  • Are any capabilities declared? What Web APIs are behind them?

Share your insights using #30DaysOfPWA - we’d love to see them!

–

Author: Nitya Narasimhan [@nitya](https://twitter.com/nitya)

Welcome to Week 1 Day 2 of #30DaysOfPWA! Want to learn more about this project? Check out our Kickoff post to get more details on the content roadmap and contributors. Now, let’s dive in!

What are the Building Blocks of a PWA?

In our last post, we talked about how progressive enhancement was the key to scalable PWA experiences, the desired characteristics of PWA (including installability, reliability and secure operation) and how open web technologies were the key to developing good PWA.

Today, let’s dive into those technologies, starting with the three core building blocks for PWA development:

• HTTPS - makes your PWA secure.
• Service Workers - makes your PWA reliable and network-independent.
• Web App Manifest - makes your PWA installable.

Before we jump into details, let’s do a couple of activities to set the stage. In our last exercise, we picked a sample PWA to use as a reference when exploring concepts. Open that in your browser now and have it ready. I’m using DevTools Tips as my sample PWA.

Task 1: Inspect your PWA!

Open the PWA in a browser and inspect it using your browser’s Developer Tools - e.g., here is the guide for Microsoft Edge. Here’s what I see when I inspect the DevTools Tips homepage:

This is a runtime dashboard for your PWA, with debugging and profiling tools you’ll learn more in Week 3: Developer Tools.

For now, familiarize yourself with these sidebar elements and keep this tab open in your browser:

• Application - with Manifest, Service Workers and Storage
• Storage - options including Local Storage, Session Storage, Indexed DB
• Cache - representing Cache Storage in browser
• Background Services - profiling panel to view/debug these activities.

Task 2: Audit your PWA!

Visit the PWABuilder site. Look for the Enter the URL to your PWA prompt, type in your PWA’s URL (e.g., https://devtoolstips.org) and hit Start. In a few minutes, it should generate a report card that looks something like this:

This is an audit report for your PWA. It tells you how well your PWA meets “desirable characteristics” with a checklist of required (must-have), recommended (nice-to-have) and optional features. Our PWA has an excellent score!! You’ll learn more in Week 3: Developer Tools - for now, keep the tab open and let’s move on.

Time to learn about: HTTPS, Service Workers and Web App Manifest!

1. HTTPS

HTTPS or HyperText Transfer Protocol Secure is a secure version of the HTTP protocol, encrypting end-to-end communications between client and server endpoints in your web app by default.

Progressive Web Apps must be served from an HTTPS endpoint to ensure secure communications, provide user privacy safeguards and guarantee content authenticity. HTTPS is mandatory for Service Workers - the core PWA technology required for reliable, offline-friendly operation.

Want to audit your PWA for security? Look at the Security tab on the PWABuilder report. Here’s what that looks like for the sample PWA:

Getting a good Security score is the simplest requirement to meet. Just publish your PWA to an HTTPS-enabled endpoint. You have two options: * Use a hosting service that supports HTTPS by default. Cloud Providers like Azure offer options like Azure App Service that can help. * Use your own hosting provider and create the required certificates using free services like Let’s Encrypt.

Note that browsers, such as Microsoft Edge, will let you use http://localhost (non-HTTPS) to preview and test your PWA locally - for debugging purposes only.

2. Service Workers

Service Workers are a special type of Web Worker, a JavaScript task that can run in the background (for asynchronous or long-running operations) without impacting the performance of the page.

Service Workers make your PWA reliable and network-independent, ensuring that it provides a usable experience under flaky network conditions or when device is offline (ex: Flight Mode). It achieves this with two key capabilities: * Fetch API. Service Workers can intercept, modify and respond to all network requests from the application dynamically. They can listen for events indicating network changes, adapting their fetch responses based on the runtime conditions and app context. * Cache API. Service Workers can access client-side Cache as well as asynchronous storage options (like IndexedDB) to proactively store resources for offline access or performance efficiency.

Let’s see Service Workers in action with our sample PWA

Take a look at the Inspect tab that we opened in Task 1 - and click on the Service Workers tab. * Check the Offline button, taking the browser offline.
* Revisit the DevTools Tips home page. You should be able to view it even though you are offline. * Click an article. What happens? You may get the “You Are Offline” message if you have not visited it before. * Uncheck the Offline button. Revisit the article (it loads) then check Offline again. You should be able to move between Home and Article pages and see them both offline.

That’s the power of Fetch (interception) and Cache (storage) delivering a native-like experience (works offline) for the PWA!

Want to audit your PWA for Service Worker support? Look for the tab in the PWA Builder report. Here’s what that looks like for DevTools Tips.

We see it meets the basic requirements (has a service worker) and implements some recommended and optional behaviors (works offline, uses periodic sync, uses background sync) for a better PWA experience.

We’ll talk about Service Worker operations (scope, lifecycle) and caching strategies (for offline and performance needs) in a later post.

3. Web App Manifest

So we’ve made the PWA secure and ensured reliable, network-independent operation. But how do we make it installable like a native app?

That’s where the Web Application Manifest comes in. It’s a W3C Specification defining a JSON-based file format that provides developers with a centralized place to put metadata associated with apps.

From a PWA developer perspective, it’s a 2-step process: * Create your manifest.json file and associate it with your PWA by referencing it in the head of your HTML page (see below). * Populate the file with required properties (for minimal PWA) and other recommended or optional properties (for a best-in class PWA experience).

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

Let’s see this in action with our sample PWA

Go back to the Inspect tab we opened in Task 1. * Scan the Elements tab - do you see the link in <head>? * Scan the Applications or Network tab - do you see the manifest.json file?

Here’s what that looks like for DevTools Tips. Note that the dashboard also shows you currently populated Manifest properties grouped into categories (Identity, Presentation, Icons etc.) for convenience. We’ll dive into the details in a future post.

Want to audit your PWA for Manifest support?

Look at your PWABuilder report from Task 2. Here’s what that looks like for DevTools Tips:

The tool groups properties into Required, Recommended and Optional categories. Use it to prioritize and fix missing properties interactively to generate an updated manifest.json. Watch for Week 3: DevTools for more insights into this tool.

How does Web App Manifest support Installability?

It governs how the PWA looks and behaves when installed on your target device platform. It is used by the browser to determine that a website is an installable PWA - and to provide the relevant install experience to users. It also supports direct installs from app stores when you publish your PWA.

Summary

That was a lot to cover, but here are the core takeaways: - PWAs use open web technologies to implement progressive-enhancement techniques in a cross-brower compatible way. - Use HTTPS to ensure secure PWA operation. It is also mandatory for using Service Workers that provide reliable, offline experiences. - Use Service Workers to intercept fetch requests and manage local cache and storage resources, enabling reliable PWA usage even when offline. - Use Web App Manifest to describe relevant PWA properties for installability, enabling PWA to look and feel like native apps on devices. - Use Developer Tools (e.g., Inspect) to explore runtime operation of a PWA and see how these technologies are used. - Use Auditing Tools (e.g., PWABuilder) to validate PWA characteristics, and get actionable recommendations to make relevant fixes.

In our next post, we’ll unpack the details of the Web App Manifest - but for now, try this exercise.

Exercise: Inspect & Audit your PWA

In the previous exercise, you selected a sample PWA and installed it in your local device (desktop or mobile). Today you’ll open the app in a browser instead (I am using Microsoft Edge) and do the following tasks:

• Inspect your PWA - e.g., using Microsoft Edge DevTools.
  • Review the various Application tabs and sidebar sections.
  • Interact with the app while inspecting it - what changes?
• Audit your PWA - e.g., using PWA Builder.
  • Review the report and recommendations.
  • What differences did you see in this PWA’s score & features?
  • What incremental fix can you make to improve that score?
• Reflect on your PWA
  • What unique experiences does this app unlock by being a PWA?
  • How does installed PWA experience differ from in-browser one?

Author: Nitya Narasimhan [@nitya](https://twitter.com/nitya)

Welcome to Week 1 Day 1 of #30DaysOfPWA! Want to learn more about this project? Check out our Kickoff post to get more details on the content roadmap and contributors. Now, let’s dive in!

What is a Progressive Web App (PWA)?

A Progressive Web App (PWA) is a traditional web app that is progressively enhanced using open web technologies, to make sure it delivers the best possible experience on every device, based on available capabilities.

This means that users on modern browsers and newer devices will get an enhanced experience that rivals the native (installed) apps on that platform – but users on older browsers or devices will continue to get a usable experience in the form of familiar websites.

This allows Progressive Web Apps to combine the reach (broad availability and access) of website experiences with the capability (hardware features and rich resources) of platform-native experiences.

How does it do that? Let’s talk about progressive enhancement!

What is Progressive Enhancement?

Progressive enhancement is a design philosophy that puts emphasis on content-first experiences where developers * ensure there is a baseline experience so users can consume core content from any device, even those with older browsers. * detect existence of newer capabilities (e.g., on modern browsers, newer devices) and enhance the experience on those devices to use them.

To understand this better, take a look at the figure below.

Today, when users think of apps, they think of either platform-installed “native” apps (in blue) or browser-based “web” apps (in yellow) - where the browser is itself installed as a native app on device platforms.

• Native apps work only on their device platform. You need one codebase per platform and possibly a specialized developer team (familiar with tools, languages) - but you get to access to all platform capabilities.
• Web apps work everywhere with a single codebase. They can run across browsers, and all devices that browsers run on - using a single codebase. However, this limits them from using platform-specific capabilities that may not be supported everywhere.

Progressive Web Apps takes advantage of open web technologies - like Service Workers, HTTPS, Web App Manifest, Push Notifications, and other Web APIs and capabilities - to detect and adapt experiences to suit the available capabilities on the platform. * On older devices and browsers - where nothing new may be detected, it delivers a baseline website experience. * On newer devices - it can detect device form factors and deliver responsive experiences that align with native behaviors. * On modern browsers - it can detect support for Service Workers and Web App Manifest, and use those to unlock and support features like installability and offline operation - just like native apps.

As platforms evolve, and more platforms move to the right (in capabilities support), PWA development will become key to delivering scalable experiences across the broadest range of devices.

How does PWA compare to web and native experiences?

Progressive Web Apps have the ability to get the best of both worlds by offering a solid baseline experience that improves based on each browser’s and OS’s growing support for these open web technologies. Here are a few benefits:

• They have the reach of websites. They can be indexed by search engines, discovered or shared by URL, and used from any device with a browser.
• They can behave like native apps. They can work offline, be installed on device, handle push notifications, and access rich device hardware.
• They can use rich platform capabilities. Ex: on Windows, PWA can be added to Start Menu, pinned to Taskbar, provide Share Targets for other apps & be published in Microsoft Store with other Windows apps.
• They can reduce costs. PWAs are developed for all platforms from one codebase - not only does this reduce maintainability costs, it requires a single development team vs. multiple platform-specific teams, to deliver the same experiences.

What characterizes a “good” PWA?

Let’s look at an example PWA to keep in mind during discussions this week. Pick one of these sample PWAs – they have live demos & source code. I’ll be using the DevTools Tips PWA for my exploration. (See: Source)

What makes this a good PWA experience? Because PWA is based on a design philosophy, there are no prescriptive rules - only desirable characteristics that make experiences comparable favorably to existing native and web apps:

Try using the sample PWA to explore characteristics

• Can you find it in web search results?
• Can you find it in the app store (try: webboard)
• Can you access it when offline (try: flight mode)?
• Is it served over HTTPS?
• Does it adapt to screen size (mobile vs. desktop)?

How can we develop PWA that can better meet these requirements? Look out for relevant posts in Week 4: Platforms And Practices. For now, let’s close this discussion with a look at real-world PWA adoption.

What drives real-world PWA adoption?

Are PWAs deployed in the real world today? What motivates an app developer to deploy PWA to production - and what are the challenges and benefits?

Let’s look at some success stories for PWA:

2020 - Lyft	2018 - Starbucks	2017 - Trivago
PWA gets 40% more ‘Install PWA’ clicks vs ‘Download app’ option.	PWA had 2X daily active users at launch. Desktop & mobile order rates were comparable.	PWA got 150% more engagement post install, 97% increase in clockouts.
Image Credit: Lyft on AppScope	Image Credit: Starbucks Case Study	Image Credit: Windows Latest

The above reflects metrics from PWAStats.com – explore the site to see more such case studies and metrics. In general, PWA deployments can be evaluated on metrics like this that reflect reduced costs, improved efficiency, and user growth:

• App Installs - did more users install PWA (vs. download native app)
• App Revenue - did PWA usage drive more conversions or ad revenue?
• User Acquisiton - did PWA result in new users (growth) for app?
• User Retention - did PWA increase monthly active users on app?
• App Performance - did PWA reduce app size, page load times etc.?

The primary challenges remain cross-browser compatibility (for consistent experiences) and complexity in migrating large scale apps from existing web or native codebases to PWA. We’ll dive into developer tools and best practices in later weeks, to tackle these issues.

In the next post we’ll deconstruct Progressive Web Apps (PWA) to understand the core technologies that power our implementation, along with a peek at key developer tools to help our understanding.

Exercise: Install your first PWA

Ready to dive into your first exercise? Try this: 1. Choose a sample PWAs and explore the live demo. 2. Try installing it on desktop and on mobile. How does the experience differ? How is it similar?

In our next post, we’ll dive into the building blocks of PWA - and use this sample PWA to see how they are used in practice.

Coming soon!

WHAT WE’LL COVER TODAY

Coming soon!

WHAT WE’LL COVER TODAY

Coming soon!

WHAT WE’LL COVER TODAY

Coming soon!

WHAT WE’LL COVER TODAY

Coming soon!

WHAT WE’LL COVER TODAY

Coming soon!

WHAT WE’LL COVER TODAY