I have an Expo detached app (ExpoKit) which stayed unmaintained for some time as it was working fine in production. It is SDK 22 and now need further developments with an upgrade to SDK 28.
I see multiple paths possible for upgrading my app:
The “official way”:
read all the blog post instructions from SDK22 to SDK28
apply changes mentionned from detached apps
apply changes of the official doc for upgrading ExpoKit
The “re-eject and compare” way:
Delete /android and /ios platform folders and remove ejection related attributes from app.json
Put back react-native-scripts eject script
Compare the local files to the new ejection generated files and report changes manually
The “re-eject and reinstall native libs” way:
Re-eject, same as 2)
Reinstall your native libs like you did with previous SDK
I’m not a native developer so I don’t really understand every details of the changes that Expo may have done since SDK 22.
I’ve actually tried to check the diff and can see there are many files updated, probably not all of them being breaking changes, and only some of them being documented into release notes (like deleting [_rootViewController loadReactApplication] on AppDelegate etc…)
So I really wonder if the undocumented things that changed should be ported to my app, or should I just follow the release note instructions and make the minimal amount of changes to make my app work with SDK28?
Also, as I documented my app’s ejection procedure (ie, what have been changed to the platform files after ejection, libs added etc…), and I only have few native changes (Intercom, OneSignal and other little things) wouldn’t it be much easier to simply reject and reinstall all native stuff directly, to avoid manual migration?
Wonder if anyone already thought about these alternative solutions or what Expo team think about solutions 2) and 3) which require “re-ejecting”, which is actually not something officially supported but that works.
BTW, I think it would be great to have an #ejected chan on Slack for those like me who have an ejected apps and want to discuss about it together
#2 and #3 are fine if you haven’t made any of your own custom changes to ios and android. Since re-ejecting involves deleting those folders, you won’t be able to bring any changes back unless you reinstall them from third parties. For some people, that works fine! (But please back up your work before you do this )
Following our upgrade guides and making the minimal changes to make it work should also work fine - I actually don’t think this would be super horrible, at least not on iOS. (not sure about Android.)
It’s up to you, I actually don’t think you are looking at a huge upgrade task here.
Our platform files are already on git so I’m free to do whatever I want as long as it works in the end
My detached app is particular:
I have minimal platform changes after ejection (adding OneSignal, Intercom, and very little tweeks that I documented)
We work in “attached mode” inside Expo client (so that my colleagues don’t need XCode/Android Studio). I stubbed Intercom/OneSignal at build time so that my app does not crash when running inside Expo client (see Ability to work in Expo client after detaching | Voters | Expo)
As we want to continue to work inside Expo client as long as possible, we are forced to do a major upgrade regularly as Expo client drop support for older SDKs
Actually I was told by @daadler6 that upgrading from SDK 22 to 28 could actually be not so easy, and he experienced a difficult time to migrate Android 23 to 24 and advised me to upgrade one version at a time (we are both web developers so this path may be simpler for a real mobile developer).
So, I’m going to try to re-eject in SDK 28 first and see where it leads me. My JS code is already working fine and works in Expo client SDK 28, so I only have to re-add Intercom/OneSignal.
Edit: I can confirm re-ejecting was successful so far. Actually in my case the integration doc of the libs have changed since SDK22, so it’s worth re-installing everything from scratch, at least if you want to update the library dependencies to newer versions.
)