What OTA Updates Changed About How I Design React Native Apps
The biggest shift in four years of design work wasn’t a Figma feature. It was a release-pipeline change.
I’ve been designing React Native apps for four years. The single biggest change to my workflow in that time wasn’t a Figma feature or a new prototyping tool.
It was our team wiring EAS Update into our production release pipeline.
That one infrastructure change reshaped what design decisions I could make quickly, which ones I had to commit to for months, and how I structured every design review after it.
Here’s what shifted.
The old workflow, and its hidden cost
Before OTA updates, every design change lived on the same release train regardless of size.
A new screen layout, a copy tweak, a color adjustment, a whole new flow — they all shipped together on whatever cadence the release calendar allowed. Usually every two to four weeks.
The hidden cost: every design decision felt heavier than it should have. If I picked wrong on a button placement, I couldn’t just fix it. The fix would sit in a queue with a dozen unrelated changes, and I’d watch users interact with the wrong version for weeks.
That pressure changes what you design.
You over-research small decisions to avoid rework. You under-experiment because the cost of a bad experiment is a month of stale UX. You default to safe over great.
Sorting screens into OTA-safe and native-only
Once EAS Update landed on our project, the first thing I had to learn was the taxonomy: which of my designs could ship via OTA, and which needed a full binary release.
The line is roughly this. Anything that lives in the JavaScript layer — screen layouts, copy, colors, animations, most component behavior — is OTA-safe. Anything that touches a new native module, a new permission, a new deep-link scheme, or app-store metadata needs a full release.
Get Chrisfa’s stories in your inbox
Join Medium for free to get updates from this writer.
This is a distinction designers should learn as fluently as we know iOS versus Android platform conventions. It genuinely changes what you can iterate on, and how fast.
Iterating on real user data instead of guesses
The best change to my workflow: I stopped optimizing screens on Figma prototypes and started shipping the safest version, watching real usage, and iterating.
A copy revision that used to require a stakeholder review and a full release cycle now happens like this. I write two variants. We ship one to 50% and one to 50% via OTA channels. Forty-eight hours later we know which one drives more conversion. Next week we iterate again.
This is closer to the web design workflow than mobile design ever used to be. And it rewards designers who can think experimentally rather than just craft-obsessively.
Empty states, error states, and the OTA advantage
The parts of an app most likely to be under-designed at launch are empty states, error states, permission-request screens, and the edges of every flow.
These are also, conveniently, all pure JavaScript. Every one of them is OTA-updateable.
So here’s the pattern I use now: launch with functional-but-basic versions of every edge state, monitor which ones users actually hit and stumble on, then design the polished version for whichever ones matter most in the first two weeks post-launch. Ship those via OTA on week three.
That’s a much better use of design time than pre-polishing every empty state, most of which nobody will ever see.
One tradeoff worth watching for
OTA doesn’t fix the parts of design work that require native capabilities.
Push-notification design, biometric-auth flows, deep-linking hooks, in-app-purchase sheets — those all involve native config. If your design work needs any of them, you’re back on the release-train cadence.
Which means your design system needs to track which components have native dependencies and which don’t. “Purely JS” is a meaningful component-library property in a React Native codebase, and it should be documented.
The teams I’ve worked on that get the most out of OTA updates are the ones where designers understand the JS-versus-native line intuitively and design accordingly.
That’s a skill worth building. And it’s paying off more every year.
If you’re starting a React Native project and want the OTA pipeline wired from day one, RapidNative generates Expo apps with EAS Update already configured.
If this changed how you think about design cadence, a clap helps it reach other designers on React Native teams. And I’m curious — where does the JS-versus-native line trip up your team most?
