documentDir when migrating from ExpoKit to react-native init app

I’ve been trying to migrate from ExpoKit to a project created using react-native init.

The issue I’m having is that using the iOS simulator, the original data is stored in

FileSystem.documentDirectory +
    'ExponentExperienceData/' +
    encodeURIComponent('%40name%2Fapp-slug')

and migration using a script similar to the one linked here (Migrate AsyncStorage to ReactNative (iOS), losing old data · Issue #5651 · expo/expo · GitHub) works fine.

However, in TestFlight, that location is showing manifest.json as empty. Reinstalling the ExpoKit version of the app in TestFlight still displays the old data so it’s clearly there somewhere, just not in that location.

I suspect (though I may be wrong) this may be because the app uuid for the documentDir (data/Containers/Data/Application/APP_UUID/Documents/) is different for the react-native init app.

  1. Is there a way to ensure the app uuid when moving from expo/expokit to plain react-native remains the same so that data in the documentDir is accessible in the new version?

OR

  1. What would be the best approach to migrate data when leaving the expo framework?

I am not against doing a staged migration (ie. new version of app in ExpoKit) to get the data somewhere else so I can eventually get to it with the new version of the app. I just need pointers on a way forward.

Thanks

How about logging the full path in both versions?

Working on it.

Additional information. The app is currently at SDK 32 and I am using redux-persist as well as straight AsyncStorage. It appears the APP_ID changes with, if not each update, with an increase of SDK version. Which is perplexing, because if that’s really the case, how does AsyncStorage persist between updates? I must be missing something.

As soon as I move up to SDK 33 the data which is retained on the simulator seems to disappear on TestFlight. And of course, the app currently crashes out on iOS 13. I have managed to source a device running an older version of iOS, but I’m currently trapped on 32 which doesn’t work on iOS 13, and I can’t upgrade SDK or leave the Expo/ExpoKit environment without users losing data.

Still trying things out, but would appreciate pointers if anything comes to mind.

Hi

I’m a little in the dark about this stuff, but I wouldn’t expect the APP_ID to change because of an SDK update. Is that not based on the team ID (linked to the development account) and the bundle ID? Isn’t the bundle ID provided by you?

In a managed app, I believe the bundle ID comes from app.json, but presumably this gets copied to a file in the ios directory when you eject?

I have barely any experience with ejected apps, but I suspect that migrating to the Expo bare workflow is going to be simpler than switching completely to a react-native init-based one.

I’ve just found this document which might explain what’s going on with the paths, but I’m not entirely sure:

In particular this part:

The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. The value can also change when installing test builds using Xcode or when installing an app on a device using ad-hoc distribution. Therefore, if your app stores the value of this property anywhere, you should gracefully handle situations where the identifier changes.

If the above document is relevant then it might explain why the APP_UUID is changing for you, but doesn’t entirely answer all the questions. Based on that article it seems like an app upgrade would not cause the UUID to change, so as long as Apple considers the new app to be an upgrade (rather than a completely new app) it seems it should not change. But even if Apple considers it to be a new app then as long as it’s installed alongside the original app and has the same vendor the UUID should also still match. Again, I don’t really know and am just going based on my interpretation of the stuff I’ve found online which I might be misinterpreting.

Hi,

Thanks! That snippet does seem to explain what I’m observing. And yes, I’m controlling the bundle ID so it doesn’t make sense that it would seem to be identified as a separate app entirely.

But it could be something to do with not properly migrating/preserving the values in project.pbxproj or somewhere else in the Xcode project file as well. I have no idea.

Will give switching to bare instead a go instead.

It might help to create a new project with expo init and eject to the bare workflow after setting up app.json the way you want it. Then you can check if the new app is working as expected. If it does you can compare your current app with the new one to see where the problem is.

So, the APP_UUID thing was a red herring.

The key to my problem was that the data wasn’t stored in manifest.json, it was stored in a different file in the same directory because AsyncStorage separates the data out for a key if it’s greater than 1024 bytes (Migrate AsyncStorage to ReactNative (iOS), losing old data · Issue #5651 · expo/expo · GitHub) which would end up happening for redux-persist.

So all good now. Thanks for your help.

1 Like

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.