Pinning Policy: What to Pin and What to Leave to Expo

If you leave the package.json that Rork emits untouched, your library versions drift away from what the SDK expects. The guiding axis here is: leave what Expo guarantees to Expo, and explicitly pin everything else.

Concretely, install Expo-managed packages through expo install so they snap to the range the SDK requires. Conversely, pin third-party packages you added yourself (analytics SDKs, billing SDKs) to exact versions.

{
  "dependencies": {
    "expo": "~52.0.0",
    "expo-notifications": "~0.29.0",
    "react-native": "0.76.5",
    "react-native-reanimated": "~3.16.0",
    "react-native-purchases": "8.2.1",
    "@sentry/react-native": "6.3.0"
  }
}

Two points. First, let Expo-managed expo-* packages and companions like react-native-reanimated follow the SDK's recommended range with a tilde. Second, lock packages that hit revenue or incident detection when they break — billing and monitoring — to exact versions, so you control when they move.

Verify alignment mechanically every time.

# Detect drift from versions the SDK requires (no changes)
npx expo install --check
 
# Auto-fix detected drift to SDK recommendations
npx expo install --fix

Wiring --check into CI lets you catch the moment someone (or an AI) carelessly adds a non-recommended version, before it merges.

Triaging Breaking Changes: Read Only What Bites

Major-upgrade changelogs are often enormous. Reading all of it equally burns time, so I read only the APIs my app actually touches.

My steps:

1. Mechanically extract the list of modules the current code actually imports
2. From the SDK upgrade guide, pull only the breaking changes that match that list
3. Sort the pulled changes into "fix now," "verify behavior," and "ignorable"

Extracting imports fits in a one-liner.

# List actually-used expo-* and react-native-* modules
grep -rhoE "from '(expo[-/][^']+|react-native[-/][^']+)'" src/ \
  | sed "s/from '//;s/'//" | sort -u

Cross-referencing only these modules against the changelog roughly halves what you read. Since switching to this "read only the APIs you use" habit, my survey week has felt noticeably lighter.

Regression Safety Net: So You Don't Learn It Broke in Production

The notification trouble above is exactly the danger: the build passes while behavior quietly breaks. Stopping that requires a smoke test that exercises the launch path and core features every time.

You do not need a heavy suite. The app launches, the main screens render, and billing restore and notification registration do not throw. Confirming this minimum every time stops most fatal injuries in advance.

// __tests__/smoke.test.ts — always run right after an upgrade
import { render, screen } from '@testing-library/react-native';
import App from '../App';
 
describe('upgrade smoke', () => {
  it('renders the app root without throwing', () => {
    render(<App />);
    expect(screen.getByTestId('app-root')).toBeTruthy();
  });
 
  it('billing module does not throw on init', async () => {
    const Purchases = require('react-native-purchases').default;
    await expect(
      Purchases.configure({ apiKey: 'test_key' })
    ).resolves.not.toThrow();
  });
});

Bugs that only appear on real hardware (notifications, camera, real billing flows) go onto a manual checklist run against an internal build. As an indie developer, I make a point of physically exercising notification delivery, purchase restore, and deep links on a device for every upgrade departure.

Splitting OTA from Store Delivery: Ship SDK Updates Through the Store

Get this wrong and you cause a production incident. EAS Update (OTA) can only deliver JavaScript and assets; a major SDK upgrade that includes the native layer must never go out over OTA. The runtime mismatches, and you scatter launch crashes.

Split by runtime version.

In eas.json, separate channels and cut a new runtime version on SDK updates.

{
  "build": {
    "production": {
      "channel": "production",
      "autoIncrement": true
    }
  }
}

Deliver OTA only within "the same runtime as the native build already on the store." When you raise the SDK, always ship through the store. Holding that single line dramatically reduces upgrade-induced crashes.

Upgrade-Day Safety Net and Rollback Conditions

Finally, the safety net to hold on departure day. I do not push the upgraded version to 100% at once; I release it small via the store's staged rollout and watch crash rates per release in Sentry.

Decide rollback conditions as numbers in advance. A vague "let's watch it" is the most dangerous setting.

// Tie per-release crash tracking to Sentry
import * as Sentry from '@sentry/react-native';
 
Sentry.init({
  dsn: 'YOUR_SENTRY_DSN',
  release: 'app@2.4.0+sdk52',   // include the SDK version in the release name
  tracesSampleRate: 0.2,
});

The rollback conditions I use:

1. If the staged rollout's crash-free rate drops one point or more versus the previous version, halt distribution immediately
2. If real users hit errors in notifications or billing, roll back via OTA when the cause is logic
3. When isolated to a native cause, request a store rollback to the previous build

Embedding the SDK version in the release name lets you see at a glance, in Sentry, "which SDK increased what." As someone with limited monitoring time on indie apps, this is one of the highest-leverage habits I have. Because revenue paths like AdMob impressions and purchase restore matter most, that mechanical threshold pays off there first.

A First Step You Can Take Now

If your SDK is currently stuck several generations behind, do not leap straight to the latest. Cut a branch that raises just one major on the next departure, and start by making the current drift visible with npx expo install --check.

Once an upgrade becomes a mechanism, each round costs surprisingly little. Since switching to a release train, I no longer burn half a day batching everything at year's end. I hope this serves as a blueprint for the regular inspection of anyone else running an app solo over the long haul.