Tauri, Electron, and PWA Release

Framework release commands are the easy part. The hard part is deciding who signs updates, where metadata lives, and how users recover from a bad build.

Tauri Release Checklist

  1. Set stable app identity in Tauri config.
  2. Choose bundle targets per platform.
  3. Configure OS code signing for macOS and Windows where distributing outside dev machines.
  4. Generate Tauri updater keys if using the updater.
  5. Put the updater public key in app config.
  6. Store the updater private key outside the repo.
  7. Build release artifacts.
  8. Sign updater artifacts.
  9. Publish update metadata over TLS.
  10. Test install, update, restart, and rollback on clean machines.

Updater configuration shape:

{
  "bundle": {
    "createUpdaterArtifacts": true
  },
  "plugins": {
    "updater": {
      "pubkey": "PUBLIC_KEY_CONTENTS",
      "endpoints": [
        "https://releases.example.com/{{target}}/{{arch}}/{{current_version}}"
      ]
    }
  }
}

Tauri signer command shape:

npm run tauri signer generate -- -w ~/.tauri/myapp.key

Warning: Do not generate the updater key casually on a laptop and forget where it lives. The private key is part of your installed-client trust chain.

Electron Release Checklist

  1. Choose Electron Builder targets before wiring update code.
  2. Use NSIS if you need electron-updater on Windows.
  3. Use AppX/MSIX when Microsoft Store distribution is the release path.
  4. Avoid MSI for electron-updater workflows.
  5. Configure macOS signing and notarization for macOS distribution.
  6. Configure Windows code signing for direct Windows downloads.
  7. Publish artifacts and update metadata atomically.
  8. Test update from the previous public version, not just fresh install.

Target trade-off:

TargetStore fitUpdater fitNotes
AppX/MSIXGoodStore updatesBest when Microsoft Store owns delivery
NSISNot StoreGood with electron-updaterCommon for direct desktop downloads
MSIEnterprisePoor for electron-updaterUse for enterprise deployment, not consumer auto-update

PWA Wrapper Checklist

PWA wrappers reduce native code, not release obligations.

For Microsoft Store PWA:

  1. Confirm the web app has a valid manifest and service worker where needed.
  2. Reserve the app in Partner Center.
  3. Use PWABuilder or equivalent packaging.
  4. Use Partner Center Package ID, Publisher ID, and Publisher display name.
  5. Submit Store listing assets and privacy information.
  6. Resubmit a package when wrapper-level metadata changes.

For Android Trusted Web Activity:

  1. Confirm the web origin is production-ready and HTTPS.
  2. Create the Android wrapper package.
  3. Sign the Android package.
  4. Configure Digital Asset Links for the signing key that users receive.
  5. Test full-screen launch, offline behavior, and fallback browser behavior.
  6. Submit to Play with the same privacy/listing discipline as a native app.

Gotcha: Play App Signing can change the certificate fingerprint users receive compared with a local upload key. Verify Digital Asset Links against the right signing identity.