Create A Pwa by adding a web app manifest, registering a service worker, and serving the site over HTTPS or localhost so the browser treats it as installable.
The exact-match query how to create a PWA describes a short, ordered build path rather than a single file. A progressive web app is a normal website that gains installability and offline behaviour through two additions: a manifest that describes the app, and a service worker that intercepts network requests. Everything else — icons, display mode, caching rules — supports those two pieces.
This page follows the sequence that matters: manifest first, service worker second, secure context third, then verification. It stays framework-neutral because the platform requirements do not change with the toolchain.
How to create a PWA. the build sequence
Work in this order. Each step produces something the next step depends on, so skipping ahead usually means debugging two problems at once.
- Create a web app manifest file and place it at the site root.
- Link the manifest from the
<head>of every page that should be installable. - Register a service worker from a script the page loads.
- Cache the app shell — the HTML, CSS, JavaScript, and icons needed for the first screen.
- Serve the site over HTTPS, or test on localhost during development.
- Verify installability by checking the browser's install affordance and launching the installed app.
The order is not arbitrary. A manifest with no service worker leaves the app without offline handling. A service worker on an insecure origin will not register at all. Verification last confirms that the earlier pieces actually connect.
What makes a web app installable
Installability is a browser decision, not a developer declaration. The browser checks that the page is served from a secure context, that a manifest is linked and parseable, and that a service worker with a fetch handler is registered and controlling the page. When those conditions hold, the browser may offer installation.
Two consequences follow. First, installability is progressive — a site can be a perfectly good website without ever being installable, and that is a valid state. Second, the install prompt is the browser's to show or withhold. A site cannot force it, and behaviour differs across browsers and platforms.
Manifest members that installability depends on
A minimal manifest needs a name, a short name, a start URL, a display mode, and at least one icon. The table below separates what the manifest owns from what the service worker owns, because the two files are frequently confused.
| Requirement | Owned by | Purpose |
|---|---|---|
| App name and short name | Web app manifest | Labels the installed app on the device |
| Start URL | Web app manifest | Sets the page opened at launch |
| Display mode | Web app manifest | Controls whether browser chrome is shown |
| Icons | Web app manifest | Provides home-screen and task-switcher artwork |
| Fetch handling | Service worker | Lets the app respond when the network is unavailable |
| Asset caching | Service worker | Stores the app shell for repeat visits |
The web app manifest file
The manifest is a JSON file, conventionally named manifest.json or manifest.webmanifest, referenced from the document head with a link element carrying rel="manifest". It is declarative. it describes the app to the browser but runs no code.
Required members are the ones the browser needs to construct an installed app. A name and short name give the app its label. The start URL defines the launch page, and it should sit within the scope the app controls. The display mode determines the frame — standalone removes most browser chrome, while browser keeps it. Icons should be supplied at multiple sizes so the operating system can pick an appropriate one.
Two practical constraints are worth planning for. Icon files must actually exist at the paths the manifest declares; a manifest that points at missing images fails validation silently in some tools. And the manifest must be reachable — if the server returns an HTML error page for the manifest URL, the browser cannot parse it.
Manifest members worth adding after the minimum
Once the required members are in place, several optional members improve the installed experience. A theme colour tints the browser interface. A background colour fills the splash screen while the app loads. A description supports richer install UI in browsers that display it. Screenshots can be referenced for the same purpose. None of these are required for installability, and adding them before the basics work simply delays the first successful install.
The service worker and offline caching
A service worker is a script that runs separately from the page and sits between the app and the network. It can intercept fetch requests and decide whether to serve a cached response, go to the network, or do both. That interception is what makes offline behaviour possible.
Registration happens from page code, typically after the page has loaded, and the script must be served from the origin it controls. Once registered, the worker moves through a lifecycle: it installs, then activates, then controls pages. A newly registered worker does not control the page that registered it until that page is reloaded or the worker claims control.
Caching strategy is a design decision, not a default. Caching the app shell — the core HTML, CSS, JavaScript, and icons — gives a fast repeat load and a usable offline first screen. Caching every response indiscriminately creates stale content problems, because the cache will keep serving old data after the network has newer data. A common middle path is to cache the shell aggressively and let data requests fall through to the network.
Updates need a plan. When the service worker file changes, the browser installs a new version, but the old worker may keep controlling open pages until they are closed or the new worker takes over. Sites that change frequently need a deliberate update path rather than assuming the new worker applies immediately.
Serving over HTTPS or localhost
Service workers only run in a secure context. In production that means HTTPS. During development, browsers treat localhost as a secure context, so a service worker can be registered and tested without a certificate.
This creates a common failure pattern: a service worker that registers cleanly on a developer machine and fails on a staging server served over plain HTTP. The fix is at the hosting layer, not in the JavaScript. Any host that terminates TLS correctly will satisfy the requirement; the specific certificate provisioning method depends on the host and is outside the scope of the app code.
One edge case matters for teams testing on real devices. A phone on the local network reaching a development machine by IP address is not on localhost, so the secure-context exception does not apply. Testing installability on a physical device generally requires either HTTPS or a tunnelling setup that provides it.
Testing the install prompt and launch
Verification is the step that separates a site that should be installable from one that is. Browser developer tools expose an application panel that reports manifest parsing, service worker status, and installability signals. Reading that panel is faster than guessing why no install option appears.
After the checks pass, the practical test is behavioural. Install the app, launch it from the device rather than the browser, and confirm the start URL opens in the intended display mode. Then test the offline path. load the app, disable the network, and reload. If the app shell appears, the service worker is doing its job. If a browser error page appears, the cache is missing the assets the first screen needs.
Two limits are worth stating plainly. Install prompt behaviour varies by browser and platform, and no supplied evidence here verifies current behaviour for any specific browser or market. And app store distribution is a separate exercise from web installability, with its own packaging and review requirements that this sequence does not cover.
Where this sequence fits in a wider build
For teams in Malaysia building or rebuilding a site, the PWA layer is usually the last addition rather than the first. A site needs stable URLs, a clear page structure, and working hosting before a manifest and service worker add value. Blackstone Intelligence, a Kuching-based AI systems and digital growth agency operated by Blackstone Consultancy Sdn Bhd, works across web development, SEO, and AI systems, and its public case studies include local SEO work for Sinar Saredah Sdn Bhd and Eyonic Sdn Bhd. Those projects illustrate the same principle that applies here: the technical layer performs better when the underlying structure is already sound.
If the goal is a site that installs from the browser, the sequence above is the whole requirement. Build the manifest, register the worker, serve it securely, and confirm the result on a real device.