Lab Release Assets
This note records lab-specific assumptions so implementation plans do not re-ask the same setup questions.
Known Account Context
| Platform | Status | Planning consequence |
|---|---|---|
| Google Play | Developer account already exists | Start with app-specific package identity, Play App Signing, Data safety, listing, and test tracks |
| Microsoft Store | Developer account already exists | Start with app reservation, package identity, MSIX/Store submission, listing assets, and certification |
| Apple Developer Program | Unknown | Treat as a prerequisite before committing to iOS/macOS App Store release |
Reusable Release Assets To Create Per App
Store these in the app repo, not in this learn topic:
release/data-inventory.md- data flows, SDKs, retention, deletion, and privacy answers.release/signing.md- app signing model, key ownership, CI secret names, rotation notes.release/listing-assets.md- title, descriptions, screenshots, icons, feature graphics, and localization status.release/release-gate.md- the completed quality gate record for each release.release/review-notes.md- store review notes, test credentials, and known reviewer setup.
Solo-Dev Default
Use the smallest path that gets trusted installs:
- Android app: Play internal testing before any direct APK sharing.
- Windows app: Microsoft Store/MSIX when public install trust matters more than custom installer control.
- Tauri/Electron app: no auto-updater until signing keys, release hosting, update metadata, and rollback are documented.
- Apple app: defer until Apple account and build pipeline are real, unless the app is explicitly Apple-first.