chore: automate example app publishing to app stores - #5118
Draft
KisaneNeko wants to merge 1 commit into
Draft
KisaneNeko wants to merge 1 commit into
KisaneNeko wants to merge 1 commit into
Conversation
KisaneNeko
marked this pull request as draft
September 14, 2026 06:46
The example app in the stores drifts away from the library: it was released eighteen times in nine years against eighty-three library releases, all by hand, and the last one was twenty months ago. Publish it from the release that prompts it instead. Publishing runs after a release already exists, so it cannot fail, revoke or roll back one. A run that does not succeed says so on its own run page, where the mail GitHub already sends the publisher leads, and says the release is unaffected: a red cross beside a fresh release should not read as a broken release. It also says to check EAS and the stores before re-running, because a build may already have been submitted and cancelling the workflow does not cancel a build running on EAS. Where a release lands is decided by the tag rather than by the release's prerelease flag, because .release-it.json pins every release to `preRelease: true` for the 6.0 alpha cycle. Reading that flag would route a stable 6.0.0 to the internal track until somebody remembered to revert the pin. A prerelease goes to the Play internal track, a stable release to production; both upload to App Store Connect, where promoting a build to the App Store stays manual. The example app keeps its own version line rather than adopting the library's, which App Store Connect would reject while the library is on a prerelease version. Its minor version is bumped and recorded through a pull request. Build numbers move to EAS, which assigns them remotely, so a retry cannot collide with a build that has already been submitted. Store credentials live in EAS rather than here, so EXPO_TOKEN is the only secret this needs. Setup, retrying, and the known limitations are in .github/PUBLISHING_EXAMPLE_APP.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
KisaneNeko
force-pushed
the
feat/automate-example-app-release
branch
from
September 14, 2026 19:36
8da1cee to
d1f8f7a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The example app in the stores is 20 months out of date. It's only ever been updated by hand (18 times in nine years, against 83 library releases), so it drifts. This ships it with each library release instead.
Related issue
Resolves #4993
How it works
Triggers on
release: published, bumps the example app's minor version, then runseas build --platform allwith auto-submit. Prereleases go to the Play internal track and TestFlight, stable releases to Play production. iOS still needs promoting from App Store Connect by hand. Build numbers are assigned remotely by EAS, and the version bump comes back as a small PR.It runs after the release already exists, so it can't affect it. If it fails, the run page says so, and says the release itself is fine.
Before it can run
EXPO_TOKENsecreteas credentialsfromexample/: App Store Connect API key, Play service accounteas build:version:setto seed build numbers (android ≥ 38, ios ≥ 26.0.5)Setup, retrying and known limitations are in
.github/PUBLISHING_EXAMPLE_APP.md.Test plan
yarn testcovers the version bump script. I ran the workflow's shell locally for each tag shape, and checked profile resolution against@expo/eas-json(prerelease → internal, stable → production).Nothing has run against real EAS yet, so the first release is the real test. If it goes wrong it costs a demo app update, not a release.