Releasing is a process, not a button. Builds are signed, uploaded, reviewed and rolled out, and mistakes are visible to users. A repeatable pipeline makes launches boring, which is the goal.
Core concepts
- EAS Build: Expo's cloud service builds iOS and Android binaries with managed signing credentials. Profiles in
eas.jsondefine development, preview and production builds. — EAS Build - EAS Submit: Uploads production builds to App Store Connect and Google Play from the command line or CI. — EAS Submit
- Internal and beta testing: Use TestFlight and Google Play internal or closed testing so real people try the build before the public does. — TestFlight
- Store requirements: Prepare icons, screenshots, a privacy policy URL, data-safety and privacy declarations, permission reason strings, age rating, support contact and account deletion. — App Store Review Guidelines
- OTA updates: EAS Update ships JavaScript and asset changes without a store review, within the limits of your runtime version. Native changes still need a new build. — EAS Update
- Versioning and channels: Use semantic versions, auto-increment build numbers, and channels (staging, production) so updates reach the right audience. — EAS Update
- CI/CD: Run typecheck, lint and tests on every pull request and build previews on merge, so releases start from a green main branch. — GitHub Actions
Concept videos
YouTube channels and searches for these topics. On a large screen they open in the reading panel next to the roadmap.
- EAS Build and Submit — Expo channel
- Publish an Expo app — YouTube search: publish Expo app App Store Google Play EAS
- App Store review tips — YouTube search: App Store review rejection reasons
Explanation
The release checklist
Version bump, green CI, QA checklist on devices, release notes, screenshots up to date, privacy forms match what the app does, build, submit, staged rollout, monitor crashes.
What OTA can and cannot change
OTA can change JavaScript and images. It cannot change native modules or permissions. Stores also expect OTA updates not to change an app's core purpose after review.
Staged rollouts
Release to a small percentage first and watch Sentry. A fix shipped quickly through OTA beats a store review wait for JS bugs.
What Is It?
Release is the process of producing a signed build, getting it approved by the stores and delivering updates to users.
Why Should I Care?
A smooth pipeline lets you ship small changes often, and a rejection or crash on launch day costs weeks.
Real World Analogy
Releasing an app is like opening a restaurant branch: inspections (review), a soft opening (beta), the grand opening (rollout) and daily menu tweaks (OTA).
Visual Mental Model
PR checks -> EAS build -> TestFlight / Play testing -> store review -> staged rollout -> OTA fixesBeginner Explanation
Configure eas.json, build a preview, install it on friends' phones through TestFlight and Play internal testing, fix what they find, then submit for review.
Smallest Possible Example
npm install -g eas-cli
eas build:configure
eas build --platform all --profile production
eas submit --platform ios --latest
eas update --branch production --message "Fix login crash"Common Mistakes
❌ Submitting without a privacy policy or account deletion.
A common rejection reason; prepare before you build.
❌ Expecting OTA to ship native changes.
Adding a native module requires a new store build.
❌ Skipping beta testing.
Real devices expose problems you will not see locally.
Real Project Example
Most Expo teams build with EAS, ship JS fixes through EAS Update and keep native changes to scheduled store releases.
Build This Mini Project
Create eas.json profiles, build a preview for both platforms, distribute to two testers, and ship one OTA fix to a staging channel.
Interview Question
What can an over-the-air update change and what can it not?
It can ship new JavaScript and assets for the same native runtime; changes to native code or configuration such as permissions require a new binary through the stores.
Key Takeaways
- Use EAS Build and Submit.
- Always beta test before public release.
- Prepare store assets, privacy policy and account deletion early.
- OTA fixes JS, not native code.
Stack for this step
| Layer | Pick | Why |
|---|---|---|
| Build | EAS Build | Cloud builds with managed signing. |
| Submit | EAS Submit | Upload to both stores. |
| Updates | EAS Update | OTA JavaScript updates. |
| CI | GitHub Actions | Checks on every PR. |
Prompts for Cursor, Claude Code & Codex
Paste these into Cursor, Claude Code, Codex, or any coding agent. Replace the bracketed parts with your app details, and keep the agent in plan mode first so you review the approach before it edits files.
Release readiness audit
Audit the repo for store readiness: app name and bundle IDs, icons and splash, permission reason strings, privacy policy URL, account deletion flow, data collected vs declared, and versioning. Output a checklist with pass or fail and what to fix.EAS configuration
Create eas.json with development, preview and production profiles, channels for staging and production, auto-increment on production, and explain each command to build, submit and update.Store listing copy
Write App Store and Google Play listing copy for [app]: title (30 chars), subtitle, short and long description, keywords, and five screenshot captions. Keep claims honest and avoid unverified superlatives.Claude Code skill for this step
Save this as .claude/skills/release-checklist/SKILL.md in your project so Claude Code loads it automatically when the task matches. The same text works as a Cursor rule or an AGENTS.md section.
---
name: release-checklist
description: Use when preparing a build for TestFlight, Google Play or production release.
---
1. Confirm CI is green and the QA checklist passed on two devices.
2. Bump version, update release notes and screenshots.
3. Verify privacy policy, data declarations and account deletion.
4. Build with EAS, submit, and plan a staged rollout with crash monitoring.Rules, databases & blogs to use
- SaaS directories to launch your product: list your app on 390+ directories
- SaaS directory launch playbook: launch and backlink strategy
- Top mobile apps: study what ranks
- DevOps rules: CI and deployment rules
- Hosting cost lessons: keep infrastructure cheap
Resources
The 60-second story
Opening a restaurant branch happens in stages. The inspector checks the kitchen. You invite friends for a soft opening to find problems. Then comes the grand opening, and after that you tweak the daily menu without rebuilding the kitchen.
An app release is the same ladder. EAS Build is constructing the kitchen, TestFlight and Play testing are the soft opening, store review is the inspector, staged rollout is opening the doors slowly, and EAS Update is changing the menu. New appliances (native modules) still need the kitchen rebuilt.
Mental model: inspect, soft open, open slowly, tweak the menu.
