DEV Community

Angel Rose
Angel Rose

Posted on

The Designer's Checklist for React Native OTA Updates

#reactnative #expo #design #mobile

TL;DR

  • OTA updates skip the App Store — and design review, unless you build a process for it
  • Every OTA touches design territory: layout, type, color, copy, or state transitions
  • Verify all 5 UI states (loading, empty, error, success, boundary) on small devices, max font size, and both themes
  • Use staged rollouts (5% → 25% → 100%) with a 20-minute design walkthrough at 5%
  • Keep an OTA changelog in your design system and require screenshots in UI PRs

React Native OTA updates ship UI changes without going through the App Store. That's great for velocity. It's also how a design system inconsistency, a broken layout on an older device, or an unreviewed empty state ends up on 100% of your users in under an hour.

Designers should have a checklist for OTA reviews. Here's what ours looks like.

Why designers need to review OTAs

The OTA release cycle in most teams is: engineer merges to main → CI publishes → done. Design gets pulled in when something breaks. That's backwards.

Every OTA changes at least one of:

  • Layout (spacing, alignment, hit targets)
  • Type (font size, weight, line-height)
  • Color/theme (especially with any theming logic)
  • Copy (microcopy edits often slip through review)
  • State transitions (loading, empty, error, success screens)

Any of the five above is design territory. The engineering CI has no way to know if a 4px padding change broke a design intent.

The five UI states an OTA can change

For every screen touched by the OTA, verify each state renders correctly:

  1. Loading — skeleton or spinner state before data arrives
  2. Empty — the 'you have no orders yet' screen; often the least-tested state
  3. Error — network failure, permission denied, backend 500
  4. Success/normal — the happy path
  5. Boundary — very long content, tiny screens (SE), very large text (Dynamic Type at max)

An OTA that fixes a bug in the Success state but breaks the Empty state is a shipped regression.

The pre-release visual QA checklist

Before OTA publish, walk through:

  • [ ] Every screen changed in this bundle rendered on iPhone SE (2020) and Pixel 5 minimum. Small screens catch layout bugs first.
  • [ ] Dynamic Type at max (iOS) / Font size at max (Android) doesn't clip or overflow.
  • [ ] Dark mode + light mode both look correct. (Most teams design for one and hope the other works.)
  • [ ] Any new copy went through review (proofread + tone check against the voice guide).
  • [ ] Screenshots of before/after in the PR description, not just 'updated the modal'.

Working with engineers on staged rollouts

OTA supports rolling out to a percentage of users first:

eas update --branch production --rollout 5
Enter fullscreen mode Exit fullscreen mode

Design should know when a staged rollout is happening and be watching the first-cohort feedback. (If you're prototyping the screens themselves, tools like RapidNative can generate React Native UI you can drop into these review flows.)

Simple protocol:

  • Engineering posts 'OTA-XXXX rolling to 5% at 2pm' in the design/eng channel.
  • Design pulls the update on their test device, walks through the changed flows for 20 min.
  • If nothing looks wrong at 5%, engineering ramps to 25% → 100% over the next two hours.

This is 20 minutes of design time per publish. It costs nothing and catches most 'shipped and broken' incidents.

Making the update log visible in the design system

We keep a running log in Figma of every OTA that touched design:

  • Date + update ID
  • Screens changed
  • Screenshot before/after
  • Link to the eng PR

This becomes the design changelog. Six months later when you're asking 'when did we change the button style on the checkout screen?', you have an answer instead of a git-blame archaeology session.

Practical: what to ask engineers to add to the OTA workflow

Two small process changes that give designers real visibility:

  1. PRs that ship UI changes require a screenshot in the description. No screenshot = engineering blocked on merge. Sounds strict; is actually how you get consistent visual QA.
  2. A shared #ota-releases channel where every publish posts (via webhook) the update ID, changed screens, and rollout stage. Designers subscribe, walk through the flows, catch things early.

OTA is a great feature. It's also the fastest way for design inconsistencies to spread across your entire user base. The engineering side is well-documented. The design side is up to us to build.

What does your team's OTA review process look like? Drop a comment — especially if you've caught (or shipped) a broken empty state.

Top comments (0)