Unfortunately Expo offers much better developer experience when attached, so detaching can hurt the productivity of the whole team just to add Intercom.
Particularly: we have team members whose role is only to create React render functions and some styles, and it would be painful if such members had to install XCode just to be able to update a text color of the app.
I’d like to know if it’s a good idea to keep 2 git branches:
one attached, using Expo client, where most developers can work on
one detached, which will be handled for app store submissions by only the most experienced native developer of our team
We would only merge attached branch to detached and not the opposite
Has anyone already done something similar?
Also, with such strategy, would we be able to publish Expo app from attached branch directly to update apps in the stores (that are detached standalone apps?). Obviously it means we succeeded to put the Intercom JS integration in the attached branch in a failsafe way so that it does not crash Expo client by requiring unavailable lib.
Interesting strategy, I was thinking about doing something similar (I have to detach the app to support inApp…)
Have you tried? if yes, are you happy with this workflow and/or do you think there are still some room for improvements ? :slight smile:
I can’t predict exactly whether this would work or not, but there’s no obvious blocker that I can think of.
Besides a couple keys in app.json, the only difference in a detached project is that it contains ios and android directories. As long as people on the attached branch don’t try to do anything under those paths, this might be sustainable. You would need to write the intercom JS in a failsafe way, as you already mentioned, so that it doesn’t crash the app when the native module is not present. And you may occasionally need to resolve conflicts in app.json.
This post isn’t a guarantee that it will work, because I haven’t tried it myself, but I don’t see anything completely impossible about the idea.
I’m evaluating a somewhat similar solution that only requires a single branch. In short: only ever check in a regular Expo project, and make detaching a build step that only produces artifacts that are never checked in.
So the process would be like:
Check out regular Expo project
Run script that: detaches project, runs pod install, runs react-native link, etc.
Build projects in XCode and Android Studio.
When you make a change, check in your code - but your .gitignore is set to ignore anything detaching does (so no ios/ android folders are checked in).
Then, people who want to work on parts that don’t require detaching just check out the project and run in the Expo app.
The key here is that nobody ever checks in code that isn’t compatible with a non-detached app. So that means you need failsafes in there for native dependencies, and you’re not making manual changes to XCode projects. OR, if you are making changes to the XCode / Android projects, you’ve made them scriptable - perhaps you add a step to #2 above that overwrites a file in the native project to reflect your changes.
To be fair, you probably could do something similar where the XCode and Android projects are checked in, but the detached settings are never checked in, so Expo will ignore the detached stuff for non-detached developers.
The only cumbersome thing I’ve seen so far is that detaching changes some values in app.json. It’s possible to work around that by, say, putting your “real” app.json in another folder and requiring a step as part of your run/ build process to copy it to the root, but it’d be really nice if detaching would only add files, not change existing files.
@llamaluvr have you checked the link I provided? I’ve been able to get a nice dev workflow by using a single branch and checking in the changes.
Making your full detach process completely automated is too complicated for me.
About the changes in app.json, they are only a few changes and don’t prevent you from running inside Expo client as long as your app is “failsafe” regarding native libraries.
Basically the only thing that prevent by default to keep the same attached workflow is just that no QRCode will be shawn by default for detached projects. I’ve made a PR to give an option to still provide a QRCode: https://github.com/expo/exp/pull/89