App Store, EAS Builds, OTA Updates — Explained
Over the Air Update - Concept
OTA allows us to update our app without rebuilding and resubmitting a new version to the App Store or Play Store.
- The app fetches updated code/content from a server
- The update will be applied on launch (or in the background)
- Users won't need to click "Update".
Questions & Answers
❓ “Why can’t I just deploy the updates like Vercel?”
Because mobile apps don’t run on the servers.
On the web:
- Code lives on the server
- Users always get the latest version
On mobile:
- Code is compiled into a binary
- It lives on the user’s phone
- Users may stay on old versions forever
❓ “Why does Apple/Google need to review my app?”
Because an app runs on the user’s device and can access: camera, photos, contacts & payments. Apple/Google isn’t reviewing the code like a PR. They’re reviewing:
“Is this app safe and trustworthy for users?”
❓ “Why not just review the code like GitHub?”
Because code doesn’t fully represent behaviour. An app can:
- Fetch remote data
- Enable features dynamically
- Change UI based on config
👉 Apple/Google reviews what users experience, not just static code.
❓ “Why is mobile deployment so slow?”
Because mistakes are expensive.
On web:
- Bug → redeploy → fixed instantly
On mobile:
- Bug → shipped to thousands of devices
- Some users never update
👉 Bugs are persistent, not temporary
❓ “So what problem does OTA (Over-The-Air updates) solve?”
OTA lets us update parts of our app without resubmitting to the App Store.
Instead of:
- rebuild → resubmit → wait
We can:
- push update → users get it on next app open
👉 It brings mobile a bit closer to web-like iteration speed
❓ “What is the limitation of OTA?”
OTA updates cannot change the native layer. If we add a new native library (e.g., a new camera plugin or a Bluetooth library), we must submit a new build to the App Store.
❓ “Does OTA bypass App Review?”
No.
OTA works within the boundaries of what Apple already approved.
✅ Allowed:
- Bug fixes
- UI tweaks
- Text/content changes
❌ Not allowed:
- New core features
- Changing app purpose
❓ “So Apple/Google still controls everything?”
Yes — but selectively. Think of it like:
- App Store = initial approval of your app’s behavior
- OTA = small adjustments within that approved scope
❓ “Why does OTA feel limited?”
Because it was added after the original design. Mobile was only supposed to be:
“build → review → install”
OTA is a layer on top trying to make it more flexible — but the App Store still enforces control.
❓ “Why is Expo so popular for OTA?”
Because it makes OTA simple. Instead of building our own system, Expo gives us:
- Hosting
- Version control
- Compatibility checks
- Rollback
👉 Using eas update
❓ “How is this different from Flutter?”
Flutter apps are compiled ahead of time. So instead of OTA:
- They rely more on app store updates
- and use remote config / feature flags
👉 Less “code updates”, more “data-driven updates”
Note:
While true that Flutter doesn't have an official, first-party OTA solution like Expo Updates, third-party tools (like Shorebird) now exist to bring OTA-style patching to Flutter by modifying the underlying engine.
Comparison with Web's "React Server Component (RSC)"
RSC in web is trying to solve a similar problem, i.e. let server has more control over the code, not the client.
🌐 Web (Next.js)
→ React Server Components
- UI generated on server
- streamed to browser
📱 Mobile (React Native / Flutter)
→ Server-driven UI + Feature Flags + OTA
- sends configs that the app maps to pre-built native components
- OTA for small fixes
💡 One-line takeaway
Mobile isn’t slower than web —
it’s optimized for trust and stability, not instant change.
Curious about how Expo OTA Works?
Please watch a short demo below where I added a small paragraph to my entry screen, pushed it the App Store, and confirmed it on a relaunch on my phone.
Step by step notes from the video here.
Top comments (0)