Rork × EAS Update Runtime Version Strategy — Upgrading Expo SDK Across 6 Apps Without Breaking Existing Users

Migrating Six Apps from SDK 50 to 51

Here's the actual sequence I ran from April to May 2026 across six apps. The full migration took three weeks; zero user-visible incidents.

Step 1. Pin every app's runtimeVersion before doing anything else

Walk through all six app.json files. Any app using "appVersion" gets switched to a hard string like "50.0.0". During an SDK migration you want to force the "native and JS are on the same runtime" invariant.

// app.json
{
  "expo": {
    "name": "Wallpaper Pro",
    "version": "3.4.0",
    "runtimeVersion": "50.0.0",
    "updates": {
      "url": "https://u.expo.dev/PROJECT_ID",
      "fallbackToCacheTimeout": 0
    }
  }
}

Step 2. Split build profiles and channels by SDK in eas.json

This is the core of the safety design. SDK 50 and SDK 51 get separate channels, so the wrong JS literally cannot be received by the wrong native.

// eas.json
{
  "cli": { "version": ">= 12.0.0", "appVersionSource": "remote" },
  "build": {
    "production-sdk50": {
      "channel": "prod-sdk50",
      "env": { "EXPO_PUBLIC_SDK_LINE": "50" },
      "ios": { "simulator": false },
      "android": { "buildType": "app-bundle" }
    },
    "production-sdk51": {
      "channel": "prod-sdk51",
      "env": { "EXPO_PUBLIC_SDK_LINE": "51" },
      "ios": { "simulator": false },
      "android": { "buildType": "app-bundle" }
    }
  },
  "submit": {
    "production-sdk50": { "ios": { "appleId": "YOUR_APPLE_ID" } },
    "production-sdk51": { "ios": { "appleId": "YOUR_APPLE_ID" } }
  }
}

Even if I accidentally run eas update --channel prod-sdk51 on an SDK 50 build, the device's channel binding rejects the update. That's the point.

Step 3. Mirror the split at the Git branch level, and add publish-time safety gates

I split the repo into main-sdk50 and main-sdk51 branches. The publish script's first job is to confirm the currently-checked-out branch matches the target channel.

#!/usr/bin/env bash
# scripts/publish-update.sh
set -euo pipefail
 
CHANNEL="${1:?usage: publish-update.sh <channel>}"
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
 
# 1. Enforce branch <-> channel correspondence
case "$CHANNEL" in
  prod-sdk50) [[ "$BRANCH" == "main-sdk50" ]] || { echo "❌ branch mismatch: $BRANCH on $CHANNEL"; exit 1; } ;;
  prod-sdk51) [[ "$BRANCH" == "main-sdk51" ]] || { echo "❌ branch mismatch: $BRANCH on $CHANNEL"; exit 1; } ;;
  *) echo "❌ unknown channel: $CHANNEL"; exit 1 ;;
esac
 
# 2. Refuse if native or dependency changes slipped into the diff
if ! git diff --quiet HEAD~10..HEAD -- ios android Podfile package.json; then
  echo "⚠️  Native or dependency changes detected. OTA will not work safely."
  echo "    Promote via a store release instead."
  exit 2
fi
 
# 3. Halt if the last 24h crash-free rate is below threshold (see below)
node scripts/check-crash-free.mjs "$CHANNEL" || { echo "❌ crash-free below threshold"; exit 3; }
 
# 4. Ship it
npx eas update --branch "$CHANNEL" --message "release $(date -u +%FT%TZ)"

The "refuse if native changes are present" gate has saved me multiple times. Sometimes a Rork-generated fix touches ios/Podfile or package.json dependencies, and shipping that via OTA is how production breaks.

Step 4. Auto-halt on crash-free regression

Fetch the last 24 hours of crash-free rate from Sentry. If it drops below 99.5%, don't publish. Dolice Labs treats 99.5% as the upper bound for "what a solo operator can sustain."

// scripts/check-crash-free.mjs
import https from "node:https";
const SENTRY_TOKEN = process.env.SENTRY_AUTH_TOKEN;
const ORG = process.env.SENTRY_ORG;
const PROJECT = process.env.SENTRY_PROJECT;
const channel = process.argv[2];
 
const url = `https://sentry.io/api/0/organizations/${ORG}/sessions/?project=${PROJECT}&statsPeriod=24h&field=sum(session)&field=count_unique(user)&field=crash_free_rate(session)`;
 
const res = await fetch(url, { headers: { Authorization: `Bearer ${SENTRY_TOKEN}` } });
const data = await res.json();
const rate = data.groups?.[0]?.totals?.["crash_free_rate(session)"] ?? 1;
 
console.log(`channel=${channel} crash_free_rate=${(rate * 100).toFixed(2)}%`);
if (rate < 0.995) process.exit(1);

Wiring this into Step 3's script means I don't have to manually check the Sentry dashboard — risky moments automatically halt the OTA. The same script is shared across all six Dolice Labs apps. During the April SDK 51 migration, one app momentarily dipped to 99.2% crash-free, and the publish step refused to ship, preventing the regression from widening.

Step 5. Commit to "support the old SDK for three months" and stagger store submissions

Don't jump six apps onto SDK 51 the same week. I migrated one app per week, in store-submission order. SDK 50 OTAs stayed alive until the last app had been accepted by the store — at minimum three months of overlap. Roughly 8% of my AdMob revenue still came from users opening with old native binaries, and cutting them off without warning is a poor business call.

A 30-Minute Recovery Playbook for "I Shipped a Native Change via OTA"

Even with all the gates above, accidents happen. In May 2026 I let a SwiftUI bridge change slip into an OTA channel. I noticed when Sentry started reporting JSI: method does not exist 40 times per minute. Here's how I contained the blast radius in under 30 minutes.

1. Run eas update --branch prod-sdk51 --republish --group <PREVIOUS_GROUP_ID> to roll back to the last known-good update. Find the previous Update Group ID in the EAS dashboard and paste it in.
2. Tag a Sentry release like 5.4.0+ota-rollback and measure impact (active sessions, unique users) at 5 min, 15 min, and 60 min post-rollback.
3. Submit an Expedited Review request via App Store Connect. In the notes field, write something like: "JSI bridge incompatibility caused by OTA update; reverted via EAS Update; submitting native fix for parity." In my experience, framed this way, expedited review approves within 4–8 hours.
4. Apply the native fix to the SDK 51 branch, build, submit, and start the Phased Release at 1%. Then 5% / 20% / 50% / 100% every 24 hours.

Between the rollback and the native fix landing, switch the affected feature off via Remote Config. Once native parity is back, flip it on again. For SwiftUI ↔ React Native bridge code, this "OTA rollback → Remote Config off → calm → Remote Config on" two-step minimizes user-visible churn.

Practical Pitfalls the Official Docs Don't Quite Cover

• Bumping runtimeVersion in app.json doesn't change the runtimeVersion of already-built binaries. If you raise it without splitting channels, your eligible audience for new OTAs drops to zero overnight.
• Hermes bytecode is pinned to the Expo SDK. SDK 51-built JS is literally unreadable by SDK 50's native. Hermes mismatch errors often don't reach Sentry — they crash at the JSI layer.
• If expo-updates is built with enabled: false, OTAs will never arrive — ever. Use eas.json env to flip EXPO_UPDATES_ENABLED per profile.
• On iOS, the OTA fetch path during Background Fetch is highly device-dependent. Combining a synchronous fetch at AppDelegate startup with fallbackToCacheTimeout: 0 — "try for one second, then give up" — gave me the lowest incident rate across the six apps.

Where to Start Tomorrow

Everything above is the result of two years of polish across our wallpaper, ambient, and law-of-attraction apps at Dolice Labs. If I were starting from scratch tomorrow, this is the order I'd tackle it:

1. Pin every app's app.json to runtimeVersion: "<sdk number>". Roughly five minutes per app to enforce the "no drift" baseline.
2. Split eas.json into per-SDK channels and add the safety gates from scripts/publish-update.sh. About one hour.
3. Wire up the Sentry crash-free check and document the Update Group rollback flow in the README. Another hour.

Even steps 1 and 2 alone make the next SDK bump dramatically less stressful. Personally, the moment I shifted from "never let an incident happen" to "if one happens, contain it inside 30 minutes," my ability to keep operating six apps as a solo developer extended significantly. If this lets you skip the rougher version of that lesson, that's the best outcome I could ask for.