Release Systems Map
Every release path has the same shape: build an artifact, bind it to an identity, submit or host it, roll it out, then watch health signals.
flowchart LR
source[Source app] --> build[Release build]
build --> identity[Package and signing identity]
identity --> channel{Distribution channel}
channel --> play[Google Play]
channel --> msstore[Microsoft Store]
channel --> apple[Apple App Store]
channel --> direct[Direct desktop download]
channel --> pwa[PWA wrapper]
play --> playupdate[Play managed updates]
msstore --> msupdate[Store managed updates]
apple --> appleupdate[App Store updates]
direct --> updater[App updater or installer replacement]
pwa --> webupdate[Web deploy plus wrapper update]
playupdate --> telemetry[Crashes, reviews, installs]
msupdate --> telemetry
appleupdate --> telemetry
updater --> telemetry
webupdate --> telemetry
The useful mental model is not “which framework builds this app?” It is “who owns install trust and updates after the user gets it?”
| Channel | Package identity | Signing owner | Updates | Main failure mode |
|---|---|---|---|---|
| Google Play | Application ID plus Play app record | Play App Signing signs generated APKs; you protect the upload key | Play tracks and staged rollout | Policy, target SDK, Data safety, listing, or key mismatch |
| Microsoft Store/MSIX | Store app reservation and package identity | Store signs published MSIX/AppX packages | Store updates | Certification, package identity, listing assets, policy |
| Apple App Store | Bundle ID plus App Store Connect app record | Apple signing/provisioning flow, App Store review | App Store release options and phased release | Account prerequisite, privacy labels, screenshots, review |
| Direct Windows download | Installer/app identity and publisher cert | You buy and protect code-signing certs | Your updater or replacement installer | SmartScreen/Defender warnings, updater trust, support burden |
| Tauri updater | App config plus updater public key | OS signing plus separate Tauri updater signature | Tauri updater metadata endpoint | Lost updater private key or bad metadata |
| Electron updater | Electron Builder target and publish provider | OS signing where configured | electron-updater for supported targets | Wrong target, unsigned updates, broken publish metadata |
| PWA wrapper | Web origin plus wrapper package identity | Store or wrapper signing path | Web deploy, sometimes wrapper resubmission | Manifest, asset links, store metadata, stale wrapper package |
What Changes Per App
The account may already exist, but these are app-specific every time:
- Package name, application ID, bundle ID, or Store package identity.
- Signing key, upload key, certificate, or updater key ownership.
- Store listing title, descriptions, screenshots, icons, and feature graphics.
- Privacy policy URL and data collection/sharing declarations.
- Release tracks, tester groups, country availability, and rollout percentage.
- Clean install, update, rollback, and telemetry evidence.
Gotcha: Store accounts do not make an app release-ready. They only let you enter the release system. The app still has to satisfy package, policy, privacy, review, and asset gates.