this may be a bit of a pain, but can you try deleting xcode and re-installing it? or try submitting with eas submit (but still building with expo build)
my best guess is that something is wrong with the local xcode installation on your machines. xcode is pretty opaque so “something” is the best i can do here
another question for you - are you using app signing credentials that are automatically generated and managed by expo or providing your own?
Thanks @notbrent. My machine was still on Catalina, but after the iOS 14.5 upgrade Xcode 12.5 is required–and that’s only supported in Big Sur. So I upgraded to Big Sur and installed Xcode 12.5. The problem unfortunately still persists 
As for the signing credentials: I had let Expo create them originally and explicitly got Expo to (re-)create a new iOS Distribution certificate and Provisioning Profile. That did not help either.
expo41 branch, ran yarn, changed the bundleIdentifier in app.json and the name, then built it using expo build:ios.eas submit -p ios --url path-to-binary-produced-by-expo-build
this is further evidence that the issue seems to somehow be related to the environment. i’d encourage you to sign up for the free one month of eas priority in order to try using eas submit, so you can verify for yourself that it does indeed seem related to the environment. as we can see above, where transporter was inexplicably failing for me, it’s certainly not usual for this to happen.
@notbrent thank you for trying to reproduce the problem. I just tried the following: rm -r node-modules, npm install, expo build:ios, and then submitted with eas submit. No difference, I still get the error
What parts and components are built locally and what parts are built in the Expo cloud? I’m trying to understand what could be different/broken in my local setup.
the only thing built locally is your javascript bundle that we embed in the prebuilt app binary later on our servers. i think this has to be a bug on apple’s side. maybe apple support could lend more guidance on how to proceed
@notbrent: I figured out how to make it work–and I’m pretty sure I must have run into some odd corner case on Expo’s end. Anyway, I decided to start from first principles and created a new app that’s pretty much just an expo init and got the same problem. What was odd was that Expo did not ask for or create a provisioning profile for the new app ID! I then decided to delete all profiles through the Expo UI. In doing so, I realized that I had the original app in two places in Expo: I had started building it under my personal account but then later created an organization and added an owner property for it in app.json.
I suspected that might be a problem and at least worth a shot, so I deleted the project under the personal account. Rebuilding the app, it asked to create the provisioning profile and that new build was accepted by TestFlight. Similar, when I then rebuilt the new test app, it asked to create a provisioning profile and that app successfully test-flights too. So it looks like having an app as project under the account and in an organization messes something up in Expo’s back end.
this is based off of two things:
if username and slug and bundle identifier in two different projects on your machine are identical, we will assume they refer to the same project on expo’s side and our credentials will be the same.
if you use an organization account, then you specify the owner field, which effectively changes the username.
Hello. I also encountered this problem.
After trying many things, I deleted the existing provisioning profile and recreated it again with eas build and it worked.
If you are facing the same problem, please give it a try.
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.
