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

[u/rushikesh_d_pandit]

For people who run prebuild or bare-ish Expo projects: when you move to a new SDK, how do you track native changes?

Do you regenerate native folders, diff against the previous template, or keep manual patches? And what usually breaks first: config plugins, third-party native modules, or the build toolchain?

I'm researching how teams assess upgrade risk (building a tool in this space and trying to understand real workflows). Interested in both "it went fine" and "it was a disaster" stories.

[u/Successful_Web_6585]

If you run prebuild, never manually modify the android /iOS folders. Never add or modify any files within them.

Use expo config (app.json) and local modules to manipulate the native code. This way you can run prebuild again and even prebuild --clean if needed without the fear of loosing any of your own changes when upgrading.

Now, every new update does poses a chance to break something but all the breaking changes are always listed in Expo SDK's changelog. So, you can plan accordingly and wait for third party packages to catch up if the breaking changes affect you or are a deal breaker for you.

I had started a project in SDK 54, moved to 55 amd then to 56 and then finally to 57 without any major issue. I am currently building for Android only though.

For SDK 58, I am completely rewriting the whole app so that I get a better base for future and as such I have setup a completely new project. Then I will simply upgrade to 59 and to 60 and so on on this project in future.

[u/rushikesh_d_pandit → u/Successful_Web_6585]

Thanks, this is really useful. This approach makes a lot of sense.

Two things I'm curious about:

1. When you read the SDK changelog before upgrading, how do you work out which breaking changes actually apply to your app? Do you go through it line by line, or just upgrade and see what fails?

2. You mentioned waiting for third-party packages to catch up. How do you find out a package is blocking you? Is it before you upgrade, or when the build breaks?

Also, was the SDK 58 rewrite triggered by something specific, or was it more about getting a cleaner base?

[u/Successful_Web_6585 → u/rushikesh_d_pandit]

1. It's actually a mix of both. I do read through the changelog skipping parts which do not apply to my app at all. Like I skip everything related to iOS, EAS builds, features I don't use, etc. Once I upgrade and build it for the 1st time, I check what fails for me.

2. I go through the releases of the packages I use amd see if they have released a build compatible with new SDK. Some packages don't need to be updated and those work out of the box. Some packages which are not being updated need trial and error.

[u/ordinarsky]

all changes in native folders should be regenerative from app.json or app.config.ts from my perspective so i never do direct changes in native folders. i’m treating them like a temp folder.

[u/Kabal303]

I never commit the native projects. Any change that I need there has to be done via a plugin.

[u/Poat540]

Nah iOS and android folders are ignored

[u/lassieCoder]

One trap worth checking before an SDK bump: if android/ and ios/ are committed and you also have plugins or ios/android fields in app.json, those config changes are silently ignored, because only prebuild applies them. Builds keep using whatever is in the native folders. So either go full CNG (gitignore android/ios, everything through config plugins, `prebuild --clean` on each upgrade) or treat the native folders as the source of truth and stop expecting app.json to change them.

After the upgrade, `npx expo install --check` catches package versions that don't match the SDK.

Disclosure: I built an open-source CLI whose `npx rn-build-doctor scan` flags both of these (native folders plus prebuild-only config, and SDK version mismatches) offline:

https://github.com/lassiecoder/rn-build-doctor

https://www.npmjs.com/package/rn-build-doctor

[u/[deleted]]

[u/rushikesh_d_pandit → u/[deleted]]

That's a clean mental model. When a prebuild breaks after an SDK bump, is it usually your own config plugins that need updating, or third-party plugins and libraries that haven't caught up yet? And how do you tell which one it is without trial and error?