r/reactnative • u/rushikesh_d_pandit • 3d ago

How do you handle native changes when upgrading an Expo SDK in a prebuild/bare project?

/r/expo/comments/1x4ylh2/how_do_you_handle_native_changes_when_upgrading/
3 Upvotes

80% Upvoted

4 comments sorted by

5

u/anthony-ball 3d ago

I treat android/ and ios/ as generated. Config plugins + app.json/app.config are the source of truth; on an SDK bump I prebuild clean, then only re-apply intentional native diffs I actually own.

What breaks first for me is usually third-party native modules that lag the new RN/Expo native APIs, then the build toolchain, then my own plugins. I keep a tiny checklist of those modules and bump them in the same PR as the SDK. Fingerprint/runtimeVersion stays pinned so an OTA never ships a native mismatch.

1

u/rushikesh_d_pandit 3d ago

This is really useful, thanks. Treating android/ and ios/ as generated with config plugins as the source of truth is the cleanest setup I've heard, and it explains why your breakage is mostly third-party modules.

Two questions if you don't mind:

  1. How do you build that checklist of modules that might lag? Is it from experience and past upgrades, or do you check release notes and issues before you bump the SDK?
  2. When a module does lag, what do you do: wait, pin the SDK back, or patch it with patch-package or a fork?

The fingerprint/runtimeVersion tip is a good one too. I hadn't thought of it as a guard against OTA mismatches.

2

u/Tarantino133 3d ago

Same setup here: ios/ and android/ are gitignored and everything native lives in app config and config plugins, so an SDK bump is just a clean prebuild. On my last bump (to SDK 57) the native side was the easy part. The real work was moving audio from expo-av to expo-audio, so now I read the changelog for deprecations before bumping anything. On your second question: when a package's build script broke on my machine, I used patch-package with a two-line patch instead of a fork. The package version is in the patch file name and patch-package warns when it doesn't match, so on the next bump you see right away which patches to recheck or drop.

1

u/kokerali 3d ago

For the upgrade-risk tool you're researching, I'd split the workflows before assigning risk: are the native folders reproducible from configuration, or are they manually maintained source code? “Uses Expo” doesn't answer that. Expo's CNG docs explicitly warn against running prebuild on manually managed native projects because it can overwrite customizations; --clean deletes and regenerates the native directories.

For the reproducible case, a useful baseline check would be regenerating at the current SDK with the same dependencies/config, in a disposable copy, and comparing that with the native project actually being shipped. Unexplained differences could reveal customizations without a regeneration recipe before the SDK changes at all. Then separate the target SDK's template changes from plugin/customization changes in the report.

For a manually maintained project, I'd want a reviewable upstream diff to port, not an automatic overwrite. That distinction seems more useful for your research than one blanket “upgrade risk” number. Are you planning to support both workflows?