DEV Community: Oleksandr Trukhnii

Make your PWA installable — the manifest, the prompt, and the iOS catch (FieldKit #2)

Oleksandr Trukhnii — Mon, 20 Jul 2026 08:37:59 +0000

This is part 2 of FieldKit, a series where I build one real Progressive Web App and use it to dig into what modern PWAs can actually do. FieldKit is a field-notes app — geotagged notes, photos, and audio that work with no signal. It's open source (on GitHub). In part 1 we made it work offline. Now let's make it installable, so it lives on the home screen and launches like a native app.

Why bother making a web app installable?

In part 1 we did the hard part: FieldKit already loads and works with zero network. So why install it at all?

Because installation changes the relationship the user has with your app. An installed PWA:

launches from the home screen or app drawer with its own icon,
opens in its own window with no browser chrome — no address bar, no tabs,
shows up in the OS app switcher like any other app,
and gets a few capabilities that only unlock once installed (we'll need this in a later part — push notifications on iOS require an installed PWA).

For a field-notes tool this matters: you're standing on a trail, you want to tap an icon and start writing, not hunt for a bookmark. Installability is what turns "a website I saved" into "an app I use."

Two ingredients make it happen: a web app manifest (so the browser knows the app can be installed and how it should look), and a bit of JavaScript (so we control when and how we ask).

The web app manifest: your install contract

The manifest is a JSON file that tells the browser everything it needs to present your app as installable. FieldKit links it from the <head>:

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

Here's the manifest, trimmed to the fields that actually drive installation:

{
  "name": "FieldKit — Offline Field Notes",
  "short_name": "FieldKit",
  "start_url": "/?source=pwa",
  "scope": "/",
  "display": "standalone",
  "background_color": "#0b1120",
  "theme_color": "#0f766e",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

The fields that matter most:

display: "standalone" — this is the one that makes it feel like an app: no browser UI, just your content in its own window. (fullscreen and minimal-ui are the other useful values.)
start_url — where the app opens from the icon. I add ?source=pwa so analytics can tell launches-from-icon apart from browser visits.
icons — you need at least a 192px and a 512px icon. Ship a maskable one too: Android crops icons into circles/squircles, and a maskable icon keeps its important content inside the "safe zone" so it doesn't get clipped. Test it with maskable.app.
theme_color / background_color — the toolbar tint and the splash-screen background while the app boots.

The install criteria browsers actually check

A manifest alone isn't enough. Chromium won't offer installation until your app clears a bar:

served over HTTPS (or localhost in dev),
a manifest with name/short_name, a start_url, a display of standalone/fullscreen/minimal-ui, and the required icons,
a registered service worker (which we built in part 1).

Miss any one and the install prompt simply never appears — and the browser won't tell you why. Chrome DevTools → Application → Manifest lists exactly what's missing; that panel is your best friend here.

Checking this by hand on every project got repetitive enough that I built a tool for it: PWA & Installability Inspector, a small open-source Chrome extension (MIT — source). Click it on any site and it gives a one-click installability verdict — will beforeinstallprompt fire, and if not, which requirement is missing — plus a field-by-field manifest audit, a check that your icons actually load and include a maskable variant, and service-worker/offline readiness. Because fixing is the tedious part, it also generates a corrected manifest and a full icon set (maskable included) from a single image. Everything runs locally — no servers, no telemetry.

Full disclosure: it's mine, and I built it while working through this exact series, so it encodes the same checklist as this article. DevTools does the same job by hand; the extension just makes the loop faster.

Taking control of the install prompt

You could let the browser nag users with its default install UI. Don't. A better pattern: catch the event, suppress the default, and surface your own install button at a moment that makes sense.

When Chromium decides the app is installable, it fires beforeinstallprompt:

let deferredPrompt = null;

window.addEventListener("beforeinstallprompt", (event) => {
  event.preventDefault();          // stop the default mini-infobar
  deferredPrompt = event;          // stash the event for later
  if (!isStandalone()) els.installBtn.hidden = false; // reveal our button
});

Then, when the user clicks our button, we replay the stashed event:

els.installBtn.addEventListener("click", async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();                              // show the OS dialog
  const { outcome } = await deferredPrompt.userChoice;  // "accepted" | "dismissed"
  deferredPrompt = null;           // the event can only be used once
  els.installBtn.hidden = true;
  if (outcome === "dismissed") toast("No worries — install anytime from the menu");
});

Two things people trip on here. First, the event is single-use — once you call prompt(), that captured event is spent; you can't stash and reuse it. Second, you can't call prompt() on a timer or page load — it must be triggered by a user gesture, or the browser ignores it.

When the install succeeds — whether through our button or the browser's own menu — the appinstalled event fires, and we clean up:

window.addEventListener("appinstalled", () => {
  els.installBtn.hidden = true;
  els.iosHint.hidden = true;
  deferredPrompt = null;
  toast("FieldKit installed");
});

Don't show "Install" to someone who already installed

If the user opens the installed app, showing an install button is silly. Detect standalone mode and hide the UI:

function isStandalone() {
  return (
    window.matchMedia("(display-mode: standalone)").matches ||
    window.navigator.standalone === true   // legacy iOS Safari
  );
}

The display-mode media query is the modern, cross-browser check. The navigator.standalone fallback exists because older iOS only understands that. Belt and suspenders.

The iOS catch

Here's the part the happy-path tutorials skip. iOS and iPadOS Safari do not support beforeinstallprompt at all. There is no event, no programmatic prompt, no install button you can wire up. The only way to install on iOS is the user manually tapping Share → Add to Home Screen.

So on iOS you can't automate — you can only guide. FieldKit detects iOS and shows a small hint instead of a button:

function isIOS() {
  return /iphone|ipad|ipod/i.test(navigator.userAgent) && !window.MSStream;
}

function maybeShowIosHint() {
  els.iosHint.hidden = !(isIOS() && !isStandalone());
}

<div id="ios-hint" class="ios-hint" hidden>
  <span>Install FieldKit: tap <strong>Share</strong>, then <strong>Add to Home Screen</strong>.</span>
  <button id="ios-hint-close" aria-label="Dismiss">&times;</button>
</div>

A few iOS gotchas worth knowing while you're here: iOS uses apple-touch-icon for the home-screen icon (we link one in the <head>), it reads display for standalone launch, and historically it has been stingy about storage for non-installed sites. Installing is genuinely the better experience on iOS — you just can't force the door.

Honest support picture

Manifest + display: standalone + installation: works across Chromium (Chrome, Edge, Samsung Internet, Android WebView) and, in the manual form, on iOS/iPadOS Safari. Firefox on desktop doesn't install PWAs; Firefox on Android does add-to-home-screen.
beforeinstallprompt + appinstalled: Chromium only. Safari and Firefox never fire them. That's exactly why the code above treats the custom button as a Chromium enhancement and falls back to the manual iOS hint. Design for "no prompt event" as the baseline.
getInstalledRelatedApps() (checking whether your app is already installed) is Chromium-only too — handy, not reliable.

As always: confirm current behavior on caniuse and MDN before you lean on any of it.

How this compares to Electron

Installation is the sharpest contrast between the two worlds:

Electron is the install. You ship an .exe/.dmg/.AppImage, the user runs an installer, and you own the window, the icon, the auto-updater, the OS integration — all of it, unconditionally, on desktop only. It's heavy (you're shipping a whole Chromium), but there's zero ambiguity about whether the app is "installed."
A PWA flips the trade-off. There's no download, no installer, no app-store review — the user taps "Install" and it's there in a second, on desktop and mobile, and it updates itself silently via the service worker. The cost is that you don't fully control the experience: the browser decides the install criteria, Safari makes it manual, and you get less OS integration than a native shell.

Rule of thumb from having shipped both: if you need deep desktop-OS integration, Electron still wins. If you want the lowest-friction path onto a user's phone and desktop without app stores, an installable PWA is hard to beat — and it costs you a manifest and about 30 lines of JavaScript.

Try it

Serve FieldKit over localhost, open Chrome DevTools → Application → Manifest, and check it reports installable. You'll see an install icon in the address bar, or FieldKit's own Install button. Install it, reopen from the icon, and notice the browser chrome is gone — and the Install button no longer shows. On an iPhone, you'll get the Add-to-Home-Screen hint instead.

git clone https://github.com/JohnJunior/FieldKit.git
cd FieldKit
npx serve .

Next up (FieldKit #3): capturing and playing back media — using the camera and microphone with getUserMedia and MediaRecorder, and all the iOS permission quirks that come with them.

Can a web app really work with zero network? Let's build one (FieldKit #1)

Oleksandr Trukhnii — Wed, 15 Jul 2026 09:46:45 +0000

This is part 1 of FieldKit, a series where I build one real Progressive Web App and use it to dig into what modern PWAs can actually do — grouping related capabilities into an article as they fit, so the series runs as long as there's something worth showing. The app is a field-notes tool: you jot geotagged notes, photos, and audio out in the world — often with no signal — and it all syncs when you're back online. Everything is open source (on GitHub). I've spent years shipping desktop apps in Electron, so along the way I'll compare how each capability feels on the web versus that native-ish world.

Why "offline-first" is the foundation, not a feature

Most PWA tutorials bolt offline support on at the end. I think that's backwards. If your app assumes the network is always there, you end up retrofitting loading states, error handling, and data persistence into code that was never designed for them.

FieldKit is the perfect forcing function: the whole point is using it where there's no connection — a trail, a basement, a plane, the subway. So offline isn't a nice-to-have, it's the first thing we build. Get this right and every later feature (camera, geolocation, push) slots into a model that already expects the network to come and go.

There are three pieces to a genuinely offline-first app, and people often confuse them:

The app shell loads offline — your HTML, CSS, and JS are cached so the app opens with no network. (Service worker.)
User data persists offline — notes the user creates are stored locally, not lost on refresh. (IndexedDB.)
Changes reconcile when you're back online — queued work flushes automatically. (Background Sync, with a fallback.) Miss any one of these and "offline support" is an illusion. Let's build all three.

Piece 1: caching the app shell with a service worker

A service worker is a script the browser runs in the background, separate from your page. Its superpower is the fetch event: it can intercept every network request your app makes and decide how to answer — from the network, from a cache, or some mix.

We register it on boot:

if ("serviceWorker" in navigator) {
  await navigator.serviceWorker.register("/sw.js");
}

The interesting part is the strategy. FieldKit uses two:

Cache-first for the app shell (HTML/CSS/JS/icons). These rarely change between deploys, and we want instant loads, so we serve from cache and only hit the network on a miss.
Network-first for everything else. We want fresh data when online, but fall back to whatever we cached last when offline. Here's the install step, where we pre-cache the shell:

const CACHE_VERSION = "fieldkit-v1";
const SHELL_CACHE = `${CACHE_VERSION}-shell`;

const SHELL_ASSETS = [
  "/", "/index.html", "/css/styles.css",
  "/js/app.js", "/js/db.js", "/manifest.webmanifest",
  "/icons/icon-192.png", "/icons/icon-512.png",
];

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(SHELL_CACHE).then((cache) => cache.addAll(SHELL_ASSETS))
  );
  self.skipWaiting();
});

And the fetch handler that picks a strategy per request:

self.addEventListener("fetch", (event) => {
  const { request } = event;
  if (request.method !== "GET") return; // never cache mutations

  // Navigations: network-first, fall back to the cached shell offline.
  if (request.mode === "navigate") {
    event.respondWith(fetch(request).catch(() => caches.match("/index.html")));
    return;
  }

  const url = new URL(request.url);
  if (SHELL_ASSETS.includes(url.pathname)) {
    // Shell assets: cache-first.
    event.respondWith(
      caches.match(request).then((cached) => cached || fetch(request))
    );
    return;
  }

  // Everything else: network-first, cache as we go.
  event.respondWith(
    fetch(request)
      .then((response) => {
        const copy = response.clone();
        caches.open(`${CACHE_VERSION}-runtime`).then((c) => c.put(request, copy));
        return response;
      })
      .catch(() => caches.match(request))
  );
});

The gotcha everyone hits: stale caches

The single most common service-worker bug is shipping a new version and watching users stay stuck on the old one. The fix is a versioned cache name plus an activate handler that deletes anything that doesn't match the current version:

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys.filter((k) => !k.startsWith(CACHE_VERSION)).map((k) => caches.delete(k))
      )
    ).then(() => self.clients.claim())
  );
});

Bump CACHE_VERSION on every shell change and old caches get swept away. skipWaiting() + clients.claim() make the new worker take control immediately rather than waiting for every tab to close. (In a bigger app you'd want to prompt the user before reloading under them — instant swap can be jarring mid-edit — but for FieldKit's scope it's fine.)

Piece 2: persisting user data with IndexedDB

localStorage is tempting and wrong here: it's synchronous (it blocks the main thread), it's string-only, and it caps out around 5 MB. We're going to store notes with attached media, so we want IndexedDB — asynchronous, structured, and roomy.

I deliberately use raw IndexedDB rather than a wrapper library so you can see exactly what's happening:

function openDB() {
  return new Promise((resolve, reject) => {
    const req = indexedDB.open("fieldkit", 1);
    req.onupgradeneeded = () => {
      const db = req.result;
      const store = db.createObjectStore("entries", { keyPath: "id" });
      store.createIndex("createdAt", "createdAt");
      store.createIndex("synced", "synced");
    };
    req.onsuccess = () => resolve(req.result);
    req.onerror = () => reject(req.error);
  });
}

export async function addEntry(entry) {
  const db = await openDB();
  return new Promise((resolve, reject) => {
    const req = db.transaction("entries", "readwrite")
      .objectStore("entries").add(entry);
    req.onsuccess = () => resolve(entry);
    req.onerror = () => reject(req.error);
  });
}

Every note carries a synced flag. New notes start synced: false — that's our queue.

const entry = {
  id: crypto.randomUUID(),
  text,
  createdAt: Date.now(),
  synced: false,
};
await addEntry(entry);

Because the data lives in IndexedDB and the shell is cached, the app now fully works on a dead connection: open it, add notes, refresh, close and reopen — nothing is lost.

Piece 3: reconciling with Background Sync

Now the magic part. When the user adds a note offline, we want it to upload itself the moment connectivity returns — even if the app is in the background or closed.

That's the Background Sync API.

You register a sync from the page:

async function requestSync() {
  if ("serviceWorker" in navigator && "SyncManager" in window) {
    const reg = await navigator.serviceWorker.ready;
    try {
      await reg.sync.register("sync-entries");
      return;
    } catch { /* fall through */ }
  }
  // Fallback (e.g. Safari): just try now if we happen to be online.
  if (navigator.onLine) flushQueue();
}

The browser fires a sync event in the service worker when it decides the network is healthy. The worker then tells any open clients to flush the queue:

self.addEventListener("sync", (event) => {
  if (event.tag === "sync-entries") {
    event.waitUntil(notifyClientsToSync());
  }
});

In FieldKit the "upload" is faked so the demo runs without a backend — swap fakeUpload() for a real fetch() and you're done.

The honest browser-support picture

This is where being straight with readers matters more than a clean demo:

Service workers + Cache API + IndexedDB: supported everywhere that matters, including Safari and Firefox. This is solid, ship-it technology.
Background Sync (SyncManager): Chromium only. As of this writing Safari and Firefox don't support it. That's why FieldKit always has a fallback path — we listen for the online event and flush the queue manually:

window.addEventListener("online", () => {
  if (navigator.onLine) flushQueue();
});

So on Chrome/Edge/Android you get true background reconciliation; on Safari/Firefox you get "sync when the app is open and regains connectivity." Both are fine — the key is to design for the weaker guarantee and treat Background Sync as an enhancement. Always check caniuse.com before you rely on it, because support does shift.

How this compares to Electron

Coming from desktop, the web's offline story is genuinely different in feel:

Electron ships the entire app shell on disk by definition — "offline app load" is free, you never think about it. The web makes you earn it with a service worker, but you get automatic, incremental updates in return (no installer to re-download). The service-worker cache is essentially you re-implementing what Electron gets from the filesystem — except here the browser handles versioning and cleanup for you once you wire up the activate step.
For local data, an Electron app usually reaches for the filesystem or a bundled SQLite. On the web, IndexedDB is the equivalent durable store — more ceremony than fs.writeFile, but it's sandboxed, quota-managed, and works identically across every browser without you shipping a database engine. The mental model that ports across both worlds: treat the local store as the source of truth and the network as an eventually-consistent sync target. Build that way and offline stops being scary — on the desktop or on the web.

Try it

Clone the repo, serve it over HTTPS (or localhost), open DevTools → Application → Service Workers, tick "Offline," and keep adding notes. They persist. Untick "Offline" and watch them flush.

git clone https://github.com/JohnJunior/FieldKit.git
cd FieldKit
npx serve .   # any static server over localhost works

Next week (FieldKit #2): making the app installable — the manifest, the beforeinstallprompt dance on Chromium, and why iOS makes you do it by hand.

A Client Asked Me for a PWA Score of 90. It Doesn't Exist Anymore

Oleksandr Trukhnii — Wed, 08 Jul 2026 09:10:11 +0000

A client recently sent me a six-year-old Progressive Web App and asked for an audit. Their goal was simple and reasonable: they wanted better offline availability. Their acceptance criterion was less reasonable. They wanted a Lighthouse PWA score of at least 90.

So I opened Lighthouse and ran the report. Here is what came back:

Four rings. Performance, Accessibility, Best Practices, SEO. No PWA.

I had to write back and explain that the number they were asking me to hit doesn't exist. Google removed the PWA category from Lighthouse in version 12, back in April 2024. There is no PWA score to score. It's gone.

That email nagged at me for a week. Not because the client was wrong to want what they wanted — they weren't — but because it made me realize I'd been asking the wrong question. The interesting question in 2026 isn't "is PWA dead?" It's "what happened to PWA over the last six years while everyone stopped paying attention?"

PWA was never a technology. It was a checklist.

Here's the thing worth remembering. "Progressive Web App" was never an API, a framework, or a runtime. The term was coined in 2015 by Frances Berriman and Chrome engineer Alex Russell as a marketing wrapper around capabilities that already existed: a service worker, a web app manifest, and HTTPS. That's it. "PWA" was a name for a bundle, and Lighthouse turned that bundle into a checklist with a green badge at the end of it.

The checklist is what died. And it died in the most literal way possible.

First, in Lighthouse 11 (2023), Chrome dropped the service-worker requirement from its installability criteria — a service worker was no longer needed for a site to be installable, so the check was removed. Then Lighthouse 12 deleted the entire PWA category. The service-worker gatherer, the manifest installability checks, the "PWA optimized" audits — all of it, gone from the report and from PageSpeed Insights.

If you want a headline that says PWA is dead, that's your headline: Google deleted PWA from its own tooling.

But here's the reframe. The category didn't disappear because PWA lost. It disappeared because it won. Installability, offline caching, a manifest, push — these stopped being a special, badge-worthy achievement and became a normal, unremarkable part of the web platform. You don't get a Lighthouse category for "uses HTTPS" either. Nobody writes think-pieces asking if HTTPS is dead. The absence of a score is the signature of a technology that graduated into infrastructure.

The audit was a time capsule

Which brings me back to the six-year-old app on my desk. Built around 2019–2020, it's a perfect fossil of the PWA hype era — the years when everyone was chasing that Lighthouse badge and the "Add to Home Screen" prompt like it was the whole point.

Auditing it, I found two very different kinds of code.

The first kind was the stuff that was built to pass the checklist. Some of it is now pointless — the app bends over backwards to satisfy installability rules that Chrome has since relaxed. It optimized for a test that no longer runs.

The second kind was the stuff that was built as plain infrastructure: the caching layer, the offline handling, the manifest. And that code still works. It's doing its job today, quietly, six years later. More to the point, it's exactly what the client came to me for. They didn't actually want a score of 90. They wanted reliable offline access — which is the oldest, most boring, most durable part of the entire PWA idea.

Then there was the detail I keep thinking about. The manifest was missing an id.

If you've built PWAs recently, you know the id property — it gives an installed app a stable identity that's decoupled from its start_url. But it only landed in Chrome 96, at the end of 2021. This app predates it. The missing id isn't a bug the original developer made. It's a field that didn't exist yet when they shipped.

And the consequence is subtle and real: without an explicit id, the browser derives the app's identity from start_url. Change that URL later and the browser treats it as a brand-new app — a "ghost install" — and the existing users silently stop receiving updates.

Sit with that for a second. A "finished," shipped, six-year-old PWA is quietly out of spec today. Not because it broke. Not because PWA died. But because PWA kept maturing the entire time nobody was looking at it. The spec moved on underneath a static app. That, right there, is the opposite of a dead technology.

Checking all of this by hand — is the manifest complete, is there an id, do the icons actually resolve, does the service worker really control the page, which Fugu APIs does the site touch — got tedious fast. So I built a small tool for it: PWA & Installability Inspector, a Chrome extension that gives any site an installability verdict and flags exactly which manifest properties are missing, id included. It runs entirely locally, it's open source (MIT), and I shipped the first version this week.

Consider it my own small attempt to replace the checklist Lighthouse retired — not with a vanity score, but with actionable fixes.

The frontier moved

So if installability and offline are solved, boring, and done — where did the actual frontier go?

It moved to the hard part: closing the gap between what a web app can do and what a native app can do. That's the whole mission of Project Fugu, the cross-company effort (Google, Microsoft, Intel, Samsung, and others) to bring native-grade capabilities to the web while keeping the web's security and privacy model. File System Access, Web Share, Contact Picker, and a long tail of hardware APIs all came out of that work.

And in 2026 the edge is somewhere the 2020 hype crowd never imagined: on-device AI and the agentic web. WebGPU brings GPU compute to the browser, WebNN handles neural-network inference, and an on-device Prompt API runs models locally. At Google I/O 2026, Chrome unveiled WebMCP — a proposed open standard, developed with Microsoft through the W3C, that lets a site expose structured tools to browser-based AI agents instead of making them scrape the DOM. It's already in an origin trial from Chrome 149, and it can even be driven by that same on-device Prompt API. The conversation has completely shifted. In 2019 the exciting question was "can a web app be installed and work offline?" In 2026 it's "can a web app run a model on-device and drive an agent?"

That's not a technology in decline. That's a technology whose easy problems got solved so thoroughly they became invisible, freeing everyone to fight over the hard ones.

The one wall that didn't move — and it's now a legal story

There's exactly one place where PWA's progress has been genuinely stuck, and you already know its name: Apple and WebKit.

To be fair, iOS has crept forward. Web Push finally arrived in iOS 16.4 in 2023, and the Badging API works. But a whole class of Fugu capabilities — Web Bluetooth, Web NFC, WebUSB, and a set of sensor APIs Apple declined back in 2020 — still don't exist on iOS. On Android a PWA is a first-class citizen; on iOS it's a curated subset, and Apple draws the boundary.

What's genuinely new is where that fight is happening. It's no longer a developer-advocacy fight — it's a regulatory one.

In February 2024, developers discovered that a beta of iOS 17.4 had quietly stripped standalone mode from Home Screen web apps in the EU — installed PWAs would just open as Safari tabs. After roughly three weeks of pressure from developers, Open Web Advocacy, and the European Commission, Apple reversed course and restored the behavior. Since then, iOS technically allows third-party browser engines in the EU through BrowserEngineKit — but the friction is high enough that, as of early 2026, essentially no browser has actually shipped on it. And in October 2025, the UK's Competition and Markets Authority designated Apple with Strategic Market Status over its mobile platform — browsers and browser engines included — and flagged removing the WebKit restriction as a priority for intervention.

Think about how strange that is. The future capabilities of a web technology now partly run through regulators, commissions, and courts, rather than through spec editors and browser release notes. For a piece of the open web, that is a very unusual place to live.

So, is PWA dead?

No. But "alive" is the wrong frame too. What's really happening is two stories braided together.

One is a story about maturity: the term is fading precisely because it won the battles it could win on its own. Offline, installable, push — the boring parts became the web, and boring is what durable infrastructure looks like.

The other is a story about power: the battles PWA couldn't win technically have turned into a legal and regulatory fight over who controls what the web is allowed to do on the device in your pocket.

Which takes me back to that client. I can't give them a PWA score of 90 — the number is gone, and honestly it was always a vanity metric. But I can give them what they actually asked for: a genuinely reliable offline experience, a manifest that won't orphan their users on the next URL change, and an honest picture of what the platform can and can't do on each OS. The score is dead. The work is very much alive.

Maybe that's the real answer to "is PWA dead in 2026." The badge died. The idea just stopped needing a badge.

Auditing an old PWA of your own? Check your manifest for an id first — if it's missing, you're one start_url change away from orphaning every installed user. If you'd rather not check by hand, that's exactly what I built the PWA & Installability Inspector for. Feedback and bug reports welcome — in the comments or on the repo.

Electron vs PWA in 2026: The Trade-offs Nobody Puts in the Comparison Table

Oleksandr Trukhnii — Wed, 01 Jul 2026 08:30:00 +0000

Almost every "Electron vs PWA" article ends up at the same tidy verdict: PWAs are lightweight, Electron is heavy, choose accordingly. It's true enough to be useless. If you've actually shipped either one, you know the decision is never about a bundle-size number. It's about which set of long-term trade-offs you're willing to own for the next few years — runtime control, security maintenance, hardware access, distribution, and the quiet platform politics that decide what your code can do on someone else's device.

So let's skip the table you've already seen and talk about the parts that actually bite. I'll assume you know HTML, CSS, and JavaScript, that you've heard of service workers and BrowserWindow, and that you want to make a real architectural call rather than win an internet argument.

The one mental model worth keeping

Both Electron and PWAs are the web platform wearing different clothes. The difference is who owns the runtime and how the app reaches the user.

A PWA is your web app, enhanced with a service worker and a web app manifest, installed straight from the browser. It runs inside whatever engine the user already has — Chromium on most desktops and Android, WebKit on every iPhone. You ship a URL; the platform supplies the runtime.
An Electron app is your web app plus its own private copy of Chromium and Node.js, packaged into a desktop binary you sign and distribute yourself. You ship the runtime too. Picture a spectrum of trust and capability. On the left, the "drive-by web" — maximum reach, minimum privilege. In the middle, installed PWAs — a bit more trust, a bit deeper OS integration. On the right, Electron — full Node.js, the local filesystem, native modules, the works, at the cost of reach and weight. Most of the real decision is just figuring out how far right on that spectrum your app genuinely needs to sit. Everything below is detail in service of that one question.

The dimensions that actually decide it

1. Who controls the runtime — and who pays for it

This is the single most underrated factor, and it cuts both ways.

Electron pins Chromium. Every user runs the exact engine version you bundled. That's a gift: no "works in Chrome, breaks in Safari," no feature-detection roulette, no waiting for a vendor to ship the API you need. You test against one engine and ship it to all three desktop OSes. For complex apps with heavy canvas, WebGL, audio, or custom rendering, that determinism is worth a lot.

The bill comes later. Pinning Chromium means you are now responsible for shipping its security patches. Electron releases a new major every 8 weeks tracking Chromium, and only the latest three majors get fixes — so a supported version ages out in roughly half a year. Fall four versions behind and you're shipping a browser engine with publicly documented CVEs baked into your installer. The practical consequence: budget a recurring Electron-upgrade sprint, not a "we'll get to it" ticket. Teams that treat the upgrade as optional discover the hard way that their desktop app has quietly become the least-patched browser on the user's machine.

A PWA flips this completely. You never ship an engine, so you never ship an engine CVE — the browser vendor patches it overnight and your users get it for free. The cost is the mirror image: you now inherit engine fragmentation, and you don't get to choose. Your offline logic has to survive Chrome's behavior and Safari's, and on iOS "Safari" means WebKit no matter what browser icon the user tapped (more on that below). You trade a maintenance treadmill for a compatibility matrix.

The honest framing: Electron lets you control the runtime and bill yourself for the privilege. A PWA hands runtime control to the browser vendor — which is liberating right up until the vendor's roadmap and yours disagree.

2. The maintenance cost most comparisons omit entirely

Two Electron-specific tax bills rarely make it into comparison articles, and both have ruined release days:

The Node ABI rebuild treadmill. Every Electron major bump can change the Node ABI, which means every native module you depend on — a SQLite binding, a keychain integration, a PTY for a terminal, an image processor — has to be recompiled against the new ABI. Miss one and you ship a binary that crashes on launch, on the user's machine, where you can't see it. The fix is process discipline (automate rebuilds in CI, gate releases on them), but it's ongoing work that a PWA simply never has.

Memory you have to actively manage. Each BrowserWindow is a full renderer process; forget to destroy one and you'll watch RAM creep upward over a long session. An empty Electron shell already sits around 150–200 MB resident; a real production app with a modern UI lands in the 300–500 MB range; a large workspace in something like a code editor can sail past a gigabyte. None of this is disqualifying — it's the price of carrying your own Chromium — but it means soak-testing a long-running session belongs on your release checklist. A PWA borrows the browser's already-running process and inherits its memory management for free.

A PWA's equivalent "maintenance" is mostly your service-worker caching strategy and remembering that a stale service worker is the most common reason "I deployed but users see the old version." Real, but an order of magnitude cheaper than an engine-upgrade program.

3. Hardware and deep APIs: how far can the web actually reach now?

The "PWAs can't talk to hardware" cliché is years out of date on the right platform. Through Project Fugu — the cross-vendor effort (Google, Microsoft, Intel, Samsung) to close the web's capability gaps — a PWA in a Chromium browser can today do things that used to be Electron's whole reason to exist:

Web Serial, WebHID, WebUSB — talk to microcontrollers, configure keyboards, drive lab instruments and point-of-sale peripherals straight from a web app. (A real one: keyboard-configurator PWAs flash firmware over WebHID; firmware tools talk to dev boards over WebUSB.)
File System Access API — open a real file with a real handle, edit it, and save back to the same file on disk, the way a desktop editor does.
File Handling — register your installed PWA as the OS handler for a file type, so double-clicking a .foo opens your app.
Plus the Async Clipboard, Web Share / Share Target, Badging, Screen Wake Lock, and Background Sync APIs that make an installed PWA feel native. Here's the catch the showcase pages gloss over: almost all of this is Chromium-only, by design and by politics. The full File System Access API with genuine local handles is Chromium-only; Safari and Firefox expose only the sandboxed Origin Private File System (OPFS) — great for an app's own private database, useless for "let the user edit their Documents folder." And the powerful hardware APIs (Bluetooth, NFC, USB, Serial, MIDI, several sensors) are on a list Apple publicly declined to implement back in 2020, citing fingerprinting and privacy — a position that hasn't moved in 2026.

So the rule of thumb is sharper than "PWAs can't do hardware":

Need deep hardware/filesystem access and your users are on Chromium desktop/Android? A PWA can very likely do it now.
Need it with iPhone users in the room? The web can't reach there, and an Electron desktop app (or a native iOS app) is your honest answer.
Need it guaranteed across every browser, forever? Electron, because you ship the only engine that matters — yours.

4. The iOS reality check (this is where dreams go to die)

If your audience includes iPhones, read this section twice, because it's the part that quietly invalidates half of the "just build a PWA" advice online.

Every browser on iOS is WebKit underneath — Chrome, Firefox, Edge, all of them. Apple's BrowserEngineKit technically allows alternative engines in the EU since iOS 17.4/18.2, but as of early 2026 no browser has actually shipped one, so in practice there's no competitive pressure and Apple alone sets the PWA roadmap. That roadmap has genuinely improved:

iOS 16.4 (2023) brought Web Push — but only to PWAs the user has explicitly added to the Home Screen, never to a normal Safari tab.
Safari 18.4 added Declarative Web Push and the Screen Wake Lock API.
iOS 26 made Home-Screen-added sites default to standalone web-app behavior, smoothing a long-standing rough edge.
And yet the gotchas that wreck offline-first assumptions are still here, and you will not find them in most comparisons:
The disappearing push subscription. On iOS, push subscriptions for installed PWAs have a long history of going silently dead after a week or two of inactivity — the endpoint stops delivering and the user effectively has to re-subscribe. If push re-engagement is core to your product, treat iOS push as best-effort, not load-bearing.
The 7-day storage eviction. iOS will evict a site's storage (including cached assets behind your service worker) after about a week of non-use. "Offline-first" on iOS means "offline-first until the user ignores us for a week." Test the cold-start-after-inactivity path explicitly; a desktop Electron app never faces this.
No automatic install prompt. Android Chrome can surface an install banner; iOS makes the user find Share → Add to Home Screen by hand, and it silently fails inside in-app browsers (the Instagram/Facebook web view). Your activation funnel pays for this.
The DMA whiplash, for the record. In early 2024 Apple briefly stripped Home-Screen web apps for EU users under a DMA-compliance rationale, then reversed within weeks after developer and regulatory pushback. The lesson isn't the outcome — it's that on iOS, your PWA's core capabilities exist at one vendor's discretion and can shift with the regulatory weather. Plan with that fragility in mind.
None of this makes iOS PWAs a bad idea — for content, commerce, and dashboards they're often the right call. It makes "build one PWA, reach everyone equally" a myth. You'll build one codebase and accept that the iOS edition is a capability-reduced edition.

5. Distribution, updates, and footprint

This is where the day-to-day economics live.

Getting it onto the machine. A PWA installs from a URL in two taps, with zero store review, zero 15–30% platform commission, and instant global availability. That's a real business advantage — and the flip side is real too: no store listing means no store discoverability, no store trust signals, and no store ratings doing your credibility work for you. Electron ships installers you distribute yourself (or through the Microsoft Store, or — with effort and entitlements — the Mac App Store), which buys you presence and enterprise-friendly packaging at the cost of review, signing, and bytes.

Updates. A PWA updates the instant you deploy; the service worker fetches the new assets and your only real job is a sane cache-busting strategy so users don't get stranded on yesterday's build. Electron updates are infrastructure you build: an update server or feed, code-signed artifacts, a framework like Squirrel/electron-updater, and a tested rollback story. It works well once wired up, but "ship a fix in 30 seconds" is a PWA superpower that's easy to undervalue until you're hotfixing a production bug.

Code signing is its own project. This rarely appears in comparisons and routinely surprises first-time desktop shippers: macOS wants notarization (and the Gatekeeper dance), Windows SmartScreen punishes unsigned or low-reputation binaries until you've built trust (often via an EV certificate). Budget real calendar time for it. A PWA needs only HTTPS, which you already have.

Footprint. A typical Electron installer is ~150–200 MB before your own assets, because Chromium + Node + V8 + ffmpeg travel with every copy. A PWA adds essentially nothing beyond the page the user already loaded. If you're distributing to bandwidth- or storage-constrained users, this isn't a footnote.

6. The middle path most articles haven't caught up to: Isolated Web Apps

Here's the genuinely fresh part of the 2026 landscape, and the one that earns its place in a "what's changed" discussion.

Isolated Web Apps (IWAs) are Chromium's attempt to give web tech an Electron-grade trust model without the Electron runtime. Instead of being served live over HTTPS, an IWA is packaged into a Signed Web Bundle (.swbn), signed with a developer key kept offline, and served from a dedicated isolated-app:// scheme. Its identity is the public key, not a domain — so a hijacked DNS record or compromised CDN can't impersonate it, and it can be installed and verified entirely offline.

That stronger guarantee unlocks APIs the open web can't safely offer — most notably Direct Sockets (raw TCP/UDP), which lets a web app do things like speak to legacy hardware protocols or act as a local network client, territory that historically forced you into Electron or native.

Why it matters for this comparison, and the caveats that keep it honest:

It's a real "third option" for the enterprise/kiosk/managed-device case: ship a signed, versioned, web-tech app that an admin force-installs via policy, with deeper capabilities than a normal PWA — and none of Electron's bundled-Chromium weight or CVE-maintenance burden.
But it's Chromium desktop / ChromeOS only. There's no IWA support on Android, and Apple and Mozilla have publicly signalled disinterest, so it is not a cross-platform answer. It's a powerful tool for the "we control the fleet" scenario, not a way to reach the open internet.
You also give up two things people love about PWAs: ephemerality and seamless server-side updates. You're back to building and signing versioned bundles — closer to a desktop release process than a git push. Think of IWAs as the option to reach for when you'd otherwise choose Electron purely for capabilities and trust, your users are on managed Chromium/ChromeOS, and you'd rather not babysit a bundled browser.

Five real decision cases (not "it depends")

Comparison tables are abstract. Here's how the trade-offs resolve in concrete situations I'd actually stand behind.

Case A — A team dashboard / internal tool, users on modern browsers.
Ship a PWA. Installable, instant updates, zero distribution friction, and Fugu APIs cover almost anything you'll want. Reaching for Electron here is paying a Chromium-maintenance tax to solve problems you don't have.

Case B — A hardware-configuration utility (flash a device, read a sensor, drive a peripheral).
If your users are on Chromium desktop/Android, build it as a PWA on WebHID/WebSerial/WebUSB — it'll genuinely work and install from a link. The moment iPhone support becomes a requirement, that path dead-ends at WebKit, and your honest options become Electron (desktop) or native (mobile). Don't promise iOS hardware access you can't deliver.

Case C — A pro creative/coding app with heavy custom rendering and native libraries.
Electron. You want a pinned engine so your WebGL/canvas/audio behaves identically everywhere, and you likely depend on native modules and full filesystem access. Accept the footprint and the upgrade sprints as the cost of determinism.

Case D — A consumer app where iPhone re-engagement via push is the growth engine.
Be very careful with a PWA-only plan. iOS push only works for Home-Screen-installed PWAs, the install flow is manual and easy to lose users in, and subscriptions can decay after inactivity. A PWA can be a fine secondary surface, but if push-driven retention is the business model, a native iOS app (or a hybrid wrapper) is the safer bet, with the PWA serving Android and desktop.

Case E — Locked-down enterprise / kiosk fleet on managed Chromebooks needing raw socket or device access.
This is the new IWA sweet spot. A signed, admin-force-installed Isolated Web App gives you near-native capability (including Direct Sockets) on a controlled platform, without shipping or maintaining a private Chromium the way Electron would. Just don't mistake it for a path to the open web.

A decision framework you can actually use

Walk these in order and stop at the first decisive answer:

Are iPhones a first-class target with push or hardware needs? If yes, the web alone won't cover it — plan for native or a wrapper, with a PWA as the broad-reach companion.
Do you need raw sockets, native modules, or a guaranteed-identical engine across all desktops? If yes, Electron — or an IWA if your fleet is managed Chromium/ChromeOS and you'd rather skip the bundled-browser maintenance.
Do your capability needs fit within Fugu APIs on Chromium/Android, and is broad, frictionless reach valuable? If yes, PWA. You get instant updates, tiny footprint, no store cut, and no engine-CVE program.
Still torn? Default to a PWA and treat Electron as the thing you graduate into when a concrete capability or distribution requirement forces it. It's far cheaper to outgrow a PWA than to discover you've been carrying Electron's weight for capabilities you never used. And a pragmatic note that resolves a lot of "either/or" anxiety: these aren't mutually exclusive. A clean web codebase can ship as a PWA and be wrapped in Electron for the desktop edition that needs more, with most of your UI and logic shared. You're often choosing a primary delivery vehicle, not marrying one forever.

The takeaway

The real question was never "which is lighter." It's which trade-offs do you want to own. Electron buys you a controlled, capable runtime and hands you the bill for maintaining it — security upgrades, native rebuilds, signing, footprint. A PWA buys you reach, instant updates, and near-zero distribution friction, and hands you the platform's constraints in return — engine fragmentation and, on iOS, a capability ceiling you don't control. Isolated Web Apps are the emerging middle for managed Chromium fleets that want Electron-grade power without the Electron-grade upkeep.

Pick the trade-off you can live with for years, not the bundle size you can live with today. That's the decision — everything else is implementation.

Testing macOS Notifications in Electron 42 During Local Development

Oleksandr Trukhnii — Wed, 24 Jun 2026 14:52:50 +0000

Electron migrated to `UNNotification`, and now your notifications silently fail unless the app is code-signed. Here's why — and how to fix it on your dev machine without packaging and signing on every run.

If you upgraded to Electron 42 and your macOS notifications suddenly stopped showing up, you're not doing anything wrong. The framework changed under your feet.

This is a hands-on guide. By the end you'll have:

A tiny Electron app that sends notifications and shows a live history of every notification and the lifecycle events it emitted (show, click, close, failed).
An understanding of why notifications fail with UNErrorDomain error 1.
A free, one-time local code-signing setup so notifications work during npm start — no packaging, no paid Apple Developer account.

The breaking change

From the Electron 42 release notes:

Behavior Changed: macOS notifications now use UNNotification API
Electron has migrated from the deprecated NSUserNotification API to the UNNotification API on macOS. The new API requires that an application be code-signed in order for notifications to be displayed. If an application is not code-signed, notifications will emit a failed event on the Notification object. (#47817)

Two consequences matter for everyday development:

Code signing is now mandatory for a notification banner to appear on macOS.
Failures are silent unless you listen for them. When the app isn't properly signed, the Notification object emits a failed event instead of throwing. If you don't subscribe to it, nothing happens and nothing tells you why.

During local development you typically run npm start, which launches the unsigned Electron.app from node_modules. So every notification fails — quietly.

A test harness: notifications + history

Let's build the smallest possible app that makes the behavior visible. The Notification API lives in the main process, so the renderer drives it over IPC, and the main process records a history of every attempt and its events.

`main.js`

// Modules to control application life and create native browser window
const { app, BrowserWindow, Notification, ipcMain } = require('electron')
const path = require('node:path')

// In-memory log of every notification we've attempted, plus the lifecycle
// events each one emitted. On Electron 42+, macOS uses the UNNotification API
// which requires the app to be code-signed; unsigned builds emit a `failed`
// event instead of showing the banner. We record that here so it's visible.
const notificationHistory = []

let mainWindow = null

function pushHistoryEvent (id, type, detail) {
  const entry = notificationHistory.find((n) => n.id === id)
  if (!entry) return
  entry.events.push({ type, detail: detail ?? null, at: new Date().toISOString() })
  // Keep the renderer's history view in sync as events arrive.
  if (mainWindow && !mainWindow.isDestroyed()) {
    mainWindow.webContents.send('notification-history-updated', notificationHistory)
  }
}

function showNotification (options = {}) {
  const id = `${Date.now()}-${notificationHistory.length}`
  const opts = {
    title: options.title || 'Electron 42 notification',
    body: options.body || 'Testing the UNNotification API on macOS.',
    silent: Boolean(options.silent)
  }

  const entry = {
    id,
    options: opts,
    supported: Notification.isSupported(),
    createdAt: new Date().toISOString(),
    events: []
  }
  notificationHistory.unshift(entry)

  if (!entry.supported) {
    pushHistoryEvent(id, 'unsupported', 'Notification.isSupported() returned false')
    return { id, supported: false }
  }

  const notification = new Notification(opts)

  notification.on('show', () => pushHistoryEvent(id, 'show'))
  notification.on('click', () => pushHistoryEvent(id, 'click'))
  notification.on('close', () => pushHistoryEvent(id, 'close'))
  // The key Electron 42 macOS behavior: unsigned apps can't display
  // notifications via UNNotification and emit `failed` with an error string.
  notification.on('failed', (_event, error) => pushHistoryEvent(id, 'failed', String(error)))

  notification.show()
  return { id, supported: true }
}

function createWindow () {
  mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js')
    }
  })

  mainWindow.loadFile('index.html')
}

app.whenReady().then(() => {
  // IPC: send a notification and report whether it was supported.
  ipcMain.handle('show-notification', (_event, options) => showNotification(options))
  // IPC: hand the full attempt-and-event log back to the renderer.
  ipcMain.handle('get-notification-history', () => notificationHistory)

  createWindow()

  app.on('activate', function () {
    if (BrowserWindow.getAllWindows().length === 0) createWindow()
  })
})

app.on('window-all-closed', function () {
  if (process.platform !== 'darwin') app.quit()
})

A note on the word history: Electron does not expose the macOS Notification Center's system-wide history. What we track here is the app's own log of attempts and their events — which is exactly what you need to debug the signing problem, because the failed event shows up right in the list.

`preload.js`

The renderer has no direct access to the Notification module, so we expose a small, safe bridge over contextBridge:

const { contextBridge, ipcRenderer } = require('electron')

// Expose a minimal, safe notification API to the renderer. The Notification
// module lives in the main process, so the renderer drives it over IPC.
contextBridge.exposeInMainWorld('notifications', {
  show: (options) => ipcRenderer.invoke('show-notification', options),
  getHistory: () => ipcRenderer.invoke('get-notification-history'),
  onHistoryUpdated: (callback) =>
    ipcRenderer.on('notification-history-updated', (_event, history) => callback(history))
})

`index.html`

A simple form plus a history list:

<section id="notification-tester">
  <h2>Notification tester</h2>
  <label>Title <input id="notif-title" type="text" value="Electron 42 notification"></label>
  <label>Body <input id="notif-body" type="text" value="Testing the UNNotification API on macOS."></label>
  <label><input id="notif-silent" type="checkbox"> Silent</label>
  <button id="send-notification" type="button">Send notification</button>

  <h3>History</h3>
  <ul id="notification-history"></ul>
</section>
<script src="./renderer.js"></script>

`renderer.js`

Wire the button and render the history, updating live as events arrive:

const historyList = document.getElementById('notification-history')

function renderHistory (history) {
  if (!history || history.length === 0) {
    historyList.innerHTML = '<li class="empty">No notifications sent yet.</li>'
    return
  }

  historyList.innerHTML = ''
  for (const entry of history) {
    const item = document.createElement('li')

    const title = document.createElement('div')
    title.className = 'notif-title'
    title.textContent = entry.options.title
    item.appendChild(title)

    const meta = document.createElement('div')
    meta.className = 'notif-meta'
    const events = entry.events.length
      ? entry.events.map((e) => (e.detail ? `${e.type} (${e.detail})` : e.type)).join(' → ')
      : 'no events yet'
    meta.textContent = `supported: ${entry.supported} · ${events}`
    item.appendChild(meta)

    historyList.appendChild(item)
  }
}

async function refreshHistory () {
  renderHistory(await window.notifications.getHistory())
}

document.getElementById('send-notification').addEventListener('click', async () => {
  await window.notifications.show({
    title: document.getElementById('notif-title').value,
    body: document.getElementById('notif-body').value,
    silent: document.getElementById('notif-silent').checked
  })
  refreshHistory()
})

// Live updates as the main process records show/click/close/failed events.
window.notifications.onHistoryUpdated(renderHistory)

document.addEventListener('DOMContentLoaded', refreshHistory)

Reproducing the failure

Run the unsigned dev app:

npm start

Click Send notification. No banner appears, and the history shows something like:

Electron 42 notification
supported: true · failed (The operation couldn't be completed. (UNErrorDomain error 1.))

Notice supported: true. Notification.isSupported() returns true because the API is available — but the actual display fails. That's the whole trap: support and delivery are now two different things.

UNErrorDomain error 1 is UNErrorCodeNotificationsNotAllowed. The UNNotification API refused to display the notification because the running app isn't code-signed.

Why ad-hoc signing isn't enough

You might reach for the quickest fix:

codesign --force --deep --sign - node_modules/electron/dist/Electron.app

If you inspect the bundle Electron ships with, you'll see it already carries a signature:

codesign -dv node_modules/electron/dist/Electron.app
# ... flags=0x20002(adhoc,linker-signed) ...

That linker-signed flag is the catch. It's an automatic signature the linker applies — UNNotification does not accept it. A real ad-hoc signature (codesign --sign -) drops the linker-signed flag:

codesign -dv node_modules/electron/dist/Electron.app
# ... flags=0x2(adhoc) ...

This does make notifications work. But ad-hoc signing has a serious drawback for daily development, which leads to the next problem.

The Keychain prompt: why a stable identity matters

After re-signing, the next launch pops up a dialog:

Electron wants to use your confidential information stored in "Electron Safe Storage" in your keychain.

This isn't from our notification code. Under the hood, Electron is Chromium, and Chromium stores an encryption key (for cookies and the safeStorage API) in the macOS Keychain under "Electron Safe Storage". Access to a Keychain item is gated by the app's code signature. When you re-sign the app, macOS sees a different identity and asks for permission again.

Here's the trap with ad-hoc signatures: they have no stable identity. Every codesign --sign - produces a new cdhash. So even if you click Always Allow, the next re-sign (say, after npm install) invalidates the Keychain ACL and the prompt returns.

The fix is to sign with a stable identity — a real certificate. Then Always Allow sticks forever, and notifications keep working across reinstalls.

You don't need a paid Apple Developer account for this. A free, self-signed code-signing certificate is enough for local development.

The fix: a free self-signed code-signing certificate

Option A — Keychain Access (GUI)

Open Keychain Access.
Menu: Keychain Access → Certificate Assistant → Create a Certificate…
Name: Electron Dev. Identity Type: Self-Signed Root. Certificate Type: Code Signing.
Create it. It lands in your login keychain, ready to use.

Option B — Command line

If you prefer to script it, generate the key and certificate with OpenSSL, import it, and trust it for code signing:

# 1. Generate a self-signed code-signing certificate
cat > /tmp/electron-dev-cert.conf <<'EOF'
[ req ]
distinguished_name = dn
x509_extensions = ext
prompt = no
[ dn ]
CN = Electron Dev
[ ext ]
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, codeSigning
basicConstraints = critical, CA:false
EOF

openssl req -x509 -newkey rsa:2048 \
  -keyout /tmp/electron-dev-key.pem -out /tmp/electron-dev-cert.pem \
  -days 3650 -nodes -config /tmp/electron-dev-cert.conf

# 2. Bundle into a .p12. Use legacy algorithms + a non-empty password,
#    otherwise macOS `security` fails with "MAC verification failed".
openssl pkcs12 -export -legacy -macalg sha1 \
  -inkey /tmp/electron-dev-key.pem -in /tmp/electron-dev-cert.pem \
  -out /tmp/electron-dev.p12 -passout pass:electron -name "Electron Dev"

# 3. Import into the login keychain, allowing codesign to use the key
security import /tmp/electron-dev.p12 \
  -k ~/Library/Keychains/login.keychain-db \
  -P "electron" -T /usr/bin/codesign

# 4. Trust the certificate for code signing
#    (macOS will prompt for your login password — approve it)
security add-trusted-cert -r trustRoot -p codeSign \
  -k ~/Library/Keychains/login.keychain-db /tmp/electron-dev-cert.pem

# 5. Clean up the private key material on disk — it lives safely in the keychain now
rm -f /tmp/electron-dev-key.pem /tmp/electron-dev.p12 \
      /tmp/electron-dev-cert.pem /tmp/electron-dev-cert.conf

⚠️ Two gotchas the recipe above already handles:

Empty p12 passwords fail to import on recent macOS. Use a non-empty -passout/-P pair.

OpenSSL 3 defaults are incompatible with the macOS security tool. Add -legacy -macalg sha1 when exporting the p12, or you'll hit MAC verification failed during PKCS12 import (wrong password?).

Verify the identity is now valid:

security find-identity -v -p codesigning
#   1) 7495...CB11 "Electron Dev"

Sign the dev binary and automate it

Sign the Electron.app that npm start actually runs:

codesign --force --deep --sign "Electron Dev" node_modules/electron/dist/Electron.app

Confirm the result — note Authority=Electron Dev and flags=0x0(none) (no more linker-signed):

codesign -dvv node_modules/electron/dist/Electron.app
# Authority=Electron Dev
# flags=0x0(none)

The signature is lost every time Electron is reinstalled, so wire it into package.json so it re-applies automatically:

{
  "scripts": {
    "start": "electron .",
    "sign:dev": "codesign --force --deep --sign \"Electron Dev\" node_modules/electron/dist/Electron.app",
    "postinstall": "node -e \"process.platform==='darwin' && require('child_process').execSync('npm run sign:dev', {stdio: 'inherit'})\""
  }
}

npm run sign:dev — re-sign on demand.
postinstall — re-sign automatically after every npm install, and only on macOS (it's a no-op elsewhere, so it won't break Linux/Windows teammates).

Verify

npm start

Click Send notification. This time:

A notification banner appears.
The history shows supported: true · show (and click / close as you interact).

The Keychain prompt appears once more (because the signature changed from the previous run). Click Always Allow — and because the Electron Dev identity is now stable, it's remembered for good, surviving future npm install and npm run sign:dev runs.

You can find the complete code on GitHub.

Good luck and have fun!

DEV Community: Oleksandr Trukhnii

Make your PWA installable — the manifest, the prompt, and the iOS catch (FieldKit #2)

Why bother making a web app installable?

The web app manifest: your install contract

The install criteria browsers actually check

Taking control of the install prompt

Don't show "Install" to someone who already installed

The iOS catch

Honest support picture

How this compares to Electron

Try it

Can a web app really work with zero network? Let's build one (FieldKit #1)

Why "offline-first" is the foundation, not a feature

Piece 1: caching the app shell with a service worker

The gotcha everyone hits: stale caches

Piece 2: persisting user data with IndexedDB

Piece 3: reconciling with Background Sync

The honest browser-support picture

How this compares to Electron

Try it

A Client Asked Me for a PWA Score of 90. It Doesn't Exist Anymore

PWA was never a technology. It was a checklist.

The audit was a time capsule

The frontier moved

The one wall that didn't move — and it's now a legal story

So, is PWA dead?

Electron vs PWA in 2026: The Trade-offs Nobody Puts in the Comparison Table

The one mental model worth keeping

The dimensions that actually decide it

1. Who controls the runtime — and who pays for it

2. The maintenance cost most comparisons omit entirely

3. Hardware and deep APIs: how far can the web actually reach now?

4. The iOS reality check (this is where dreams go to die)

5. Distribution, updates, and footprint

6. The middle path most articles haven't caught up to: Isolated Web Apps

Five real decision cases (not "it depends")

A decision framework you can actually use

The takeaway

Testing macOS Notifications in Electron 42 During Local Development

Electron migrated to UNNotification, and now your notifications silently fail unless the app is code-signed. Here's why — and how to fix it on your dev machine without packaging and signing on every run.

The breaking change

A test harness: notifications + history

main.js

preload.js

index.html

renderer.js

Reproducing the failure

Why ad-hoc signing isn't enough

The Keychain prompt: why a stable identity matters

The fix: a free self-signed code-signing certificate

Option A — Keychain Access (GUI)

Option B — Command line

Sign the dev binary and automate it

Verify

Electron migrated to `UNNotification`, and now your notifications silently fail unless the app is code-signed. Here's why — and how to fix it on your dev machine without packaging and signing on every run.

`main.js`

`preload.js`

`index.html`

`renderer.js`