Hi Expo team, I am new to development in expo client environment and have met a troubling issue many times.
I have succesfuly builded an iOS app using expo and published it to App Store through App Store connect ( Happ Core ).
Now I want to manually update my app and send new updates to my testing team through test flight(through App Store connect), but each time I try to build ipa file using expo client, all the users of my app automatically receive the update (I guess its a feature called OTA updates, but I have set updates.enabled to false in my app.json in accordance with https://docs.expo.io/versions/latest/guides/configuring-ota-updates/ and it didn’t help at all). I am trying to figure out how to build ipa file on my local machine and send it to Test Flight, without anyone else getting it beforehand.
I really enjoy your product though
Thanks you for your time and consideration!
This may or may not be helpful for your situation, but my team uses a system of including the minimum build number that the JS is compatible with in the release channel in order to prevent production builds from getting the JS update too early. I describe it here: How to check compatibility of OTA updates with custom native modules. This is useful if you don’t want anyone to get that JS until they’ve upgraded the binary.
If you just want to put out a new TestFlight build pointing to new JS (for testing purposes only) that you will later send out as an OTA update to everyone (and then you just let the build expire without ever pushing it live in the store), the above technique wouldn’t really work. You may be able to work something out with the “promote” feature of release channels (https://docs.expo.io/versions/latest/distribution/advanced-release-channels/#promoting-a-release-to-a-new-channel). Another option is to create a separate app that’s just for TestFlight testing and always points to a “test” or “staging” bundle (this is what we do). You just need to make sure this app has a different slug and bundle ID when compared to the production version (you could hot swap an alternate app.json to accomplish this). An advantage of the latter technique is that testers can have both the test and prod versions of your app installed side-by-side. This is actually a pretty common thing to do in native development even apart from Expo.
