{"slug":"production-release","title":"Production release","summary":"Approve an exact build for production, attest compliance, set the production target, then submit for review in App Store Connect or roll out in Play Console.","body":"A release in **Publish**, **Releases** is one build on its way to a store. It records the binary checksum, source revision, version and build number, listing revision, and track, so everyone can see exactly what is being shipped.\n\n## Release statuses\n\n| Status | Meaning |\n| --- | --- |\n| draft | Created, not yet approved |\n| awaiting approval | Waiting for someone to approve the current snapshot |\n| uploading | Sending the file to the store |\n| processing | The store is processing the upload |\n| available for testing | Testers can install it |\n| submitted for review, in review | With Apple or Google review |\n| approved, released | Approved by the store, then live |\n| rejected, failed | Stopped. **Retry** keeps the same store release instead of creating another |\n\n## Approvals\n\nApprovals are tied to a snapshot: the binary, source revision, listing revision, screenshots, and track. If any of these change, the approval is cleared automatically. Nobody can ship something different from what was approved.\n\n1. **Approve testing** covers the testing track. **Send to TestFlight** and **Send to Play** record it for you.\n2. **Attest compliance** confirms that privacy, data safety, and content declarations are complete and true. Production requires it.\n3. **Approve production** is a second, separate approval. Production requires it too.\n4. **Promote to production** moves the release's target to production. If the snapshot changed, it asks for production approval again.\n\n## Production targets\n\n| | iOS | Android |\n| --- | --- | --- |\n| Target | App Store | Production track |\n| Default release | Manual: you release after Apple approves | Staged rollout starting at 10% of users |\n\n## Submit in the store\n\nProduction submission is completed in the store consoles, using the build FluxNative uploaded.\n\n**iOS, in App Store Connect:**\n\n1. Open the app, then the version under **App Store**. Create the version if needed, matching the project version.\n2. Add screenshots and paste the listing text from FluxNative.\n3. Under **Build**, select the TestFlight build with the approved build number.\n4. Complete App Privacy, age rating, and review information, then **Add for Review** and submit.\n5. After approval, release it manually or automatically, as you chose.\n\n**Android, in Play Console:**\n\n1. Open **Test and release**, **Production**, and create a release.\n2. Add the bundle from the library: the one with the approved version code.\n3. Paste the release notes, set the rollout percentage (10% is a safe start), and send it for review.\n4. After review, increase the rollout as reports look healthy.\n\n> [!TIP]\n> Keep the release record in FluxNative in step with the store. It is your team's audit trail of who approved which binary and when.","sectionSlug":"publish","sectionTitle":"Publish to stores","updatedAt":"2026-09-23T22:51:25.250Z","previous":{"slug":"store-listing","title":"Store listing"},"next":{"slug":"organizations","title":"Organizations and roles"}}