skip to content

A React Native bank app's redesigned home screen is at 10% on Google Play and mid phased release on iOS when crashes spike; what do you do?

level: seniorimportance: should knowfreq 40%

answer

  1. stop exposure before diagnosing
  2. halt on Play, pause on iOS
  3. manual iOS updaters still get it
  4. no rollback, only fix forward
  5. a remote flag decouples feature from binary

basics

~20 s

Stop exposure first: halt the Play rollout and pause the iOS phased release. Then switch the redesign off via a remote flag if one exists, diagnose by version, and fix forward with a higher build, since neither store rolls back.

solid answer

~40 s

First **limit the blast radius**: halt the Google Play staged rollout and pause the App Store phased release. Pausing only stops automatic updates, so iOS users who update manually still receive the bad version. If the redesign is behind a **server-side flag**, turn it off; that protects users who already updated, which no store control can do. Then **diagnose** using crash rates filtered to the new version: native or JS, one OS or device family, one code path. **Fix forward**: neither store downgrades users, so ship a corrected build, or the previous code rebuilt, with a higher version code and build number, test it on the internal and beta tracks quickly, and restart the rollout from a small percentage. Keep stakeholders updated; for a bank app, support and compliance need to know.

code

tsx · 10 lines
tsx
import { View } from 'react-native';
import { useRemoteFlag } from './flags';
import { HomeScreenV1 } from './HomeScreenV1';
import { HomeScreenV2 } from './HomeScreenV2';

export function HomeScreen() {
  // Flag served by the bank's backend; defaults to the old screen if unknown
  const redesignOn = useRemoteFlag('home-redesign', false);
  return <View style={{ flex: 1 }}>{redesignOn ? <HomeScreenV2 /> : <HomeScreenV1 />}</View>;
}

go deeper

for a junior

Remember that a bad rollout is stopped with halt on Google Play and pause on iOS, and that the fix ships as a new, higher build.

for a middle

Explain what halt and pause each leave uncovered, and why neither store can move users back to an older version.

for a senior

Lead the incident: stop exposure at once, protect updated users with a remote flag, diagnose by version on Release builds, fix forward and restart the rollout in small steps.

for a principal

Make kill switches, rollout gates and incident communication a precondition for risky releases, so a spike becomes a contained event rather than an outage.

## First principle: stop the spread, then diagnose When a release goes bad mid-rollout, the most valuable minutes are the first ones. Every hour the rollout keeps advancing, more users receive the broken build. The order is: **stop exposure, protect already-updated users, diagnose, fix forward, restart carefully.** ## Step 1: stop further exposure | Store | Control | What it does | What it does not do | |---|---|---|---| | Google Play | Halt the staged rollout | No new users receive the release | Updated users keep it | | App Store | Pause phased release | Automatic updates stop advancing | Manual updaters and new downloads still get it | The iOS gap matters: a paused phased release still lets anyone who taps Update, and any new customer, install the broken version. That is why the next step exists. ## Step 2: protect users who already updated No store feature takes a version away from a device. The tools that can help are inside your app: - **A server-side feature flag** around the redesigned home screen lets you switch users back to the old screen without any release. For a risky redesign in a bank app, this should have been in place before the rollout started. - **A JavaScript fix delivered over the air** may be possible if the crash is in JS and the app already has an OTA mechanism; that has its own rules and rollout controls, covered separately. ## Step 3: diagnose by version 1. Filter crash and error reports to the **new version** only, on each platform. 2. Decide whether frames are **native** or **JavaScript**; each needs its own symbols to read. 3. Look for a pattern: one OS version, one device family, a particular account state such as users with several cards. 4. Reproduce on a **Release** build, since release-only behaviour, such as optimized native code and production JS, is a common source of crashes that Debug never shows. ## Step 4: fix forward Neither store can roll users back, and devices refuse to install a lower version over a higher one. The way back to working code is **forward**: - Build the fix, or the previous release's code, with a **higher Android version code** and a **new iOS build number**. - Push it through **internal testing** and a quick **beta** check on both platforms, using real devices. - On iOS, if the fix is urgent, Apple offers a way to request an **expedited review**; there is no guarantee it is granted. ## Step 5: restart the rollout carefully - On Play, release the fixed build to a **small percentage** again, then raise it in steps with crash-free rates as the gate. - On iOS, use **phased release** again for the fixed version. - Keep the old broken version halted or superseded, so no new user can pick it up. ## Communication for a bank app A crash in a banking app is a customer-trust and possibly a regulatory issue: - Tell support what users see and the workaround, such as updating once the fix is out. - Tell whoever owns incident reporting what was affected and for how long. - Write down the timeline, so the post-incident review can ask why the redesign shipped without a kill switch. ## Preparing before the next risky rollout The incident is easier when the groundwork exists before release day: - Wrap risky screens in a **remote flag** with a safe default, so the feature can be switched off per platform. - Agree **halt criteria** in advance, such as a crash-free rate threshold for the new version, so halting is a rule rather than a debate. - Keep the **previous release's commit tagged**, so rebuilding it with a higher build number takes minutes. - Rehearse the **internal and beta track** path for an urgent build, so a fix is not slowed by an untested pipeline. ## What interviewers listen for A strong answer halts and pauses immediately, knows that iOS pause does not cover manual updates, reaches for a remote flag to protect updated users, says clearly that stores cannot roll back, fixes forward with higher build numbers, and restarts the rollout gradually. Weak answers try to "roll back in the console" or wait for full diagnosis before stopping the rollout.

  • Why is pausing the App Store phased release not enough to stop a bad React Native update reaching iOS users?
    Phased release only controls automatic updates. Users who update manually from the App Store, and new users who download the app, still get the paused version. Only a new build, or an in-app mechanism such as a remote flag, changes what those users run.
  • How do you return Android users to the previous React Native release after a bad staged rollout?
    Rebuild the previous code, or the fix, with a higher version code and release it. Play will not install a lower version code over a higher one, and halting leaves updated users on the bad version. Fixing forward is the only store-side path back.

saying these in an interview costs you the question

  • You can roll users back to the previous version from the store console.
  • Pausing the iOS phased release stops every iOS user getting the update.
  • Wait for a full diagnosis before halting the rollout.
  • Re-uploading the previous build with its old version code restores it.
  • Halting on Play removes the bad version from devices that installed it.