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
- Set stable app identity in Tauri config.
- Choose bundle targets per platform.
- Configure OS code signing for macOS and Windows where distributing outside dev machines.
- Generate Tauri updater keys if using the updater.
- Put the updater public key in app config.
- Store the updater private key outside the repo.
- Build release artifacts.
- Sign updater artifacts.
- Publish update metadata over TLS.
- 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
- Choose Electron Builder targets before wiring update code.
- Use NSIS if you need
electron-updateron Windows. - Use AppX/MSIX when Microsoft Store distribution is the release path.
- Avoid MSI for
electron-updaterworkflows. - Configure macOS signing and notarization for macOS distribution.
- Configure Windows code signing for direct Windows downloads.
- Publish artifacts and update metadata atomically.
- Test update from the previous public version, not just fresh install.
Target trade-off:
| Target | Store fit | Updater fit | Notes |
|---|---|---|---|
| AppX/MSIX | Good | Store updates | Best when Microsoft Store owns delivery |
| NSIS | Not Store | Good with electron-updater | Common for direct desktop downloads |
| MSI | Enterprise | Poor for electron-updater | Use for enterprise deployment, not consumer auto-update |
PWA Wrapper Checklist
PWA wrappers reduce native code, not release obligations.
For Microsoft Store PWA:
- Confirm the web app has a valid manifest and service worker where needed.
- Reserve the app in Partner Center.
- Use PWABuilder or equivalent packaging.
- Use Partner Center Package ID, Publisher ID, and Publisher display name.
- Submit Store listing assets and privacy information.
- Resubmit a package when wrapper-level metadata changes.
For Android Trusted Web Activity:
- Confirm the web origin is production-ready and HTTPS.
- Create the Android wrapper package.
- Sign the Android package.
- Configure Digital Asset Links for the signing key that users receive.
- Test full-screen launch, offline behavior, and fallback browser behavior.
- 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.