The boilerplate ships EAS Build and Submit profiles, GitHub Actions CI, and over-the-air updates. This is the path from your laptop to a store listing.
What we could and could not test for you
Everything on the pages before this one was executed on a clean clone and the outputs are real. This page is different: submitting to the App Store needs your developer accounts, your signing certificates, and your app. The commands below come from the repository's own eas.json and docs/deploying.md, not from a run we can show you.
Before your first build
- Set your identifiers. See Make It Yours. Changing them after release means a new listing.
- Replace the placeholder JWT secret on whatever server you deploy. The backend refuses to start in production if you have not, which is deliberate. See Environment Setup.
- Get developer accounts. Apple charges 99 USD a year, Google 25 USD once.
- Install the CLI.
npm install -g eas-cli, theneas login.
Build
eas.json defines development, preview, and production profiles:
eas build --profile production --platform ios
eas build --profile production --platform androidNo Mac? EAS builds iOS in the cloud, so you do not need local macOS.
Use the development profile to get a build with the native modules included. That is what you need to test in-app purchases, push notifications, camera, and maps, none of which work in a browser.
Submit
eas submit --platform ios
eas submit --platform androidThese go to TestFlight and to Play Internal Testing, not straight to the public. Promote from there when you are happy.
Over-the-air updates
Ship JavaScript-only fixes without waiting for review:
eas update --branch production.github/workflows/eas-update.yml can do this on every push to a release branch.
Over-the-air updates are JavaScript only
They ship JS and assets. Anything touching native code, a new native module, a new permission, needs a fresh eas build and eas submit.
Tagged releases
git tag v0.1.0
git push origin v0.1.0That triggers .github/workflows/release.yml for a versioned, repeatable build.
Deploying the backend
Only if you kept apps/api. It ships a multi-stage Dockerfile and a compose file, so any host that runs a container works: a small VPS, Fly.io, Railway, Render.
Before you go live:
- set a real
JWT_SECRET - set
ALLOWED_ORIGINSto your actual domains - move off the SQLite file if you expect real traffic (
docs/swap-to-postgres.md) - point
EXPO_PUBLIC_API_URLat the deployed URL and rebuild the app, since that value is baked in at build time
Review checklist
The repository ships docs/privacy-manifest.md and docs/manual-test-checklist.md. Work through both before submitting. The privacy manifest in particular is a common rejection reason, and Apple will ask what every permission is for.