Old untouched project - Expo SDK 44

Expo Development Tools
1

Hello everybody

I have a small app published in stores: GooglePlay and Appstore.
The app is based on Expo SDK 44, the project wasn’t updated since then.

Now I want to keep developing and updating this app: I thought of two options:

  1. Upgrading this project to the latest SDK(I’ve read that Expo has big changes like EAS build)
  2. Create a fresh new project with keeping the app.json file

What do you think is the best approach?

Thank you

2

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.

3

What do you think about building the app from the new project, there will be any issue?
I mean, the project is registered in the Expo platform, where it is developed and built.

It is enough to keep the old app.json with small additional changes?

4

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

1 Like
5

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.

1 Like
6

Fair enough. It’s a small app, with almost no dependencies.

7

Either way you will have to update the code if any of the breaking changes affect you.

I’d go step by step through the SDK versions and check the release notes at each step.

8

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:

  1. It is enough to keep the old file app.json(with additional changes regarding new Expo SDKS)
  2. Will be there any issues for the building phase and deployment to the Stores?
  3. 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?
9

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 :slight_smile: or even if you revert to an older SDK version.

1 Like
10

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.

11

Hey. You had any issues building the new app within Expo platform?
You have send the build to the Stores as well?

12

yeah I had issues. Mostly critical errors that were not showing up in expo go, but the apps failing on standalone.

After debugging the apk found this:
E Invariant Violation: requireNativeComponent: “RNGestureHandlerRootView” was not found in the UIManager.

Seems like I was missing react-native-gesture-handler and somehow expo go was ignoring it.

Are you having issues right now?

13

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.
  • You can use npx expo start --no-dev --minify to bundle the JavaScript code in production mode. This makes the JavaScript bundle the same as what is used in a preview/production app, so there’s more chance of it crashing in the same way as the production version and you can at least get some error messages to investigate.
  • 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.)

See the following for more info: