Title says it all.
Today, I create a standalone app in Android and iOS using Expo. Suppose sometime next year I eject from Expo and maybe even get rid of ExpoKit. I will migrate fully to Vanilla React Native. Will I face any (any!) trouble when re-deploying the new app versions?
Someone from the Expo team probably has a better way of summarizing this, but, from the perspective of this user of both the Expo managed workflow and ExpoKit…no, you will not suffer. If you choose Expo and it works for you, then you’ve saved yourself from dealing with linking native libraries, XCode, Android Studio, certs, etc. If you don’t choose Expo, then you have to deal with that right out of the gate. If you choose Expo and it doesn’t work for you, then you’ve just delayed having to deal with all those native annoyances that you would have had to deal with anyway.
We’re at the point, too, where bare workflow is erasing the one part that could be a bit awkward- going from ExpoKit to vanilla. There’s not much reason to start a new project on ExpoKit at this point. So, start with managed, stick with it until it doesn’t work (if ever), then go to bare, continue using Expo API’s while building binaries yourself. The future isn’t “am I using Expo or am I not using Expo”, but “how much Expo do I want to use?”
Hi @llamaluvr (awesome username!),
thank you for your reply.
I understand that you went through this scenario (Expo → Deploy to store → eject to ExpoKit → Deploy to store) yourself?
Glad to hear that ejecting has no troublesome parts.
I have separate apps - one on Managed, one ejected to ExpoKit. I wouldn’t have any particular concern with changing an already published app to ExpoKit/ bare, though. It’s quite possible to completely change your app’s underlying tech between releases. Our ExpoKit app was actually a Cordova app before (a much bigger transition than from Managed to ExpoKit).
To be clear, it’s not that ejecting has no troublesome parts. Software development can be hard sometimes, and bare React Native apps in general require interfacing with some tools that can be troublesome (like XCode and Android Studio). Managed workflow is just a way to avoid that pain almost entirely for a large swath of apps that conform to the limitations of the managed workflow.
It’s quite possible to completely change your app’s underlying tech between releases.
That’s good to know, thanks for your clarification!
Of course there is pain in software engineering. It wouldn’t be fun if it didn’t take effort 
Desire is the root of all sufferings. Let go of the desire to switch… and you wont suffer.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.