What I believe works best is setting up a fresh project and incrementally add the necessary dependencies, testing to see when something breaks. Did so on a project recently and it really saved me a lot of headache.
I think most of the issues you might face is if you are using the old unimodules system for packages that need native code access. Also there’s been a lot of changes to the expo platform itself. You can check their blogs for those.
You can try out upgrading manually if you’d prefer though. The only suggestion I would make is to do this incrementally from version to version - i.e instead of from 44 → 48, you can do 44 → 45 → 46 → 47 → 48
Expo SDK 44 is not that old. Personally I would upgrade to Expo SDK 45, read through the release notes/breaking changes and get it working there. Then do the same for Expo SDK 46, etc. until you get to Expo SDK 48.
But it depends a lot on how many dependencies you have and what those dependencies are. Also how many of the breaking changes affect your app.
Maybe have a go at upgrading step by step and if you get stuck you can always try creating a new app and porting the code across piece by piece.
While EAS Build is huge, it should not really have much to do with how you go about upgrading the app. It mainly just allows you to make use of a lot more dependencies that in the past would have required you to eject to the Bare workflow.
Well, as I said, it is a very small app.
I’m sure there are no issues moving the code/project features.
What do you think about merging into a new project?
I have these issues in my mind:
It is enough to keep the old file app.json(with additional changes regarding new Expo SDKS)
Will be there any issues for the building phase and deployment to the Stores?
The most important: I’m not sure if Expo platform keeps record of the SDKS upgrades.
What I mean by this: The current Expo project is SDK 44, then suddenly receives the 48 SDK… this sounds kinda weird, or not?
Keeping the old app.json should be fine. If you start with a new one, make sure you keep the same ios.bundleId and android.package. You should also keep the same slug. If you already have a projectId, make sure you keep that the same too.
As long as use keep the bundleId and package as they were, and use the same keys for signing there should be no problem. Maybe try building the original app with EAS first so that it creates the project ID and migrates the keys from the classic build system if necessary.
No, Expo doesn’t care if you skip SDK versions or even if you revert to an older SDK version.
Hello recently I tried upgrading one by one, or straight into SDK48 and also doing it from scratch, and for me, was much better to create a new project from scratch with the SDK 48 and add the old code to new screens one by one, including the app.json file.
Expo Go has a bunch of dependencies built in. This is required so that it can load any app that depends only on the Expo SDK.
If you run into issues in a preview/production version of the app that you don’t get when running in the development version or in Expo Go:
If it runs fine in Expo Go it means you are not using third party dependencies with native code, so you should remove the android and ios directories from your app if you have them.
Run npx expo-doctor to see if you have any dependencies with the wrong version for your version of the Expo SDK.
If the above doesn’t fix it you can check the device logs while reproducing the problem with the production app.
If all else fails you might need to start commenting out half your code to narrow down where the problem is coming from. (Roughly: Comment out one half. Check if the problem still happens. Uncomment the first half and comment out the other half. Check if the problem still happens. Hopefully this will show you which half the problem is coming from and you can then repeat the process on just that section of the code.)