Re-downloading won't fix this one. A provisioning profile only trusts the specific certificate(s) it was generated against at the time — if the certificate got regenerated (or is new) after the profile was created, downloading the same old profile file again just gets you the same stale trust list, no matter how many times you do it. The fix is to regenerate the profile itself, not redownload it: go to the profile in the Developer portal, open it, and hit regenerate (this re-links it to whichever certificate is currently active on your account), then download that new file. Worth confirming first which certificate is actually current with security find-identity -v -p codesigning so you know what the profile should be pointing at. I ran into this building the CI pipeline behind macless.dev and ended up writing a free script that checks whether a cert's fingerprint actually matches what's embedded in a profile, so you can catch this before a build fails on it: github.com/jackson26-source/macless-signing-doctor.

This usually isn't actually about the profile being missing, it's about Xcode's headless build not looking at it the way you'd expect. Two things to check: The profile has to be installed under its UUID filename, not its display name. Run security cms -D -i YourProfile.mobileprovision | plutil -extract UUID xml1 -o - - to get the real UUID, then confirm the file at ~/Library/MobileDevice/Provisioning Profiles/.mobileprovision actually exists on the runner. A file named after the profile's display name gets silently ignored. "Automatic signing is disabled and unable to generate a profile" is the telling part. If your target's CODE_SIGN_STYLE is set to Manual, -allowProvisioningUpdates won't help since that flag only kicks in for automatic signing, and automatic signing in CI needs an App Store Connect API key passed via -authenticationKeyPath/-authenticationKeyIssuerID/-authenticationKeyID, not just having the file sitting there. If you want manual signing (the normal CI setup), skip -allowProvisioningUpdates entirely and pass CODE_SIGN_STYLE=Manual PROVISIONING_PROFILE_SPECIFIER="Your Profile Name" CODE_SIGN_IDENTITY="Apple Distribution: ..." directly on the xcodebuild command line, or set them in your export options plist. Full disclosure, I build a CI pipeline for exactly this (macless.dev) and hit this same error building it. I also put together a free script that decodes a profile/cert pair and tells you if they actually match before you burn a CI run finding out: github.com/jackson26-source/macless-signing-doctor.

Yes, it's possible. You'll need a paid Apple Developer Program account regardless of platform, that part is unavoidable, but the build, code signing, and App Store upload can all run in GitHub Actions using Apple's own macOS cloud runners, triggered straight from your Windows device. You never need to own or rent a Mac yourself. I built a $99 one time pipeline that sets this up for you if you'd rather not configure the GitHub Actions workflow yourself: https://macless.dev/?utm_source=appledevforums&utm_medium=referral&utm_campaign=outreach

Late addition for anyone finding this thread now: the rent a Mac by the hour advice above (MacinCloud, MacStadium) is outdated for the build/sign/upload step specifically. GitHub Actions gives you real macOS with Xcode as a CI runner, so you can trigger a fully automated build, code sign, and App Store/TestFlight upload from Windows without renting or owning a Mac at all. It's usually cheaper than hourly Mac rental too if you're not developing full time, since you only pay for CI minutes rather than a monthly seat. You still need a paid Apple Developer Program account regardless, that part hasn't changed. I built a $99 one time pipeline for this if you don't want to configure the GitHub Actions workflow yourself: https://macless.dev/?utm_source=appledevforums&utm_medium=referral&utm_campaign=outreach

This has a solid answer now that didn't really exist a few years ago: CI, not cloud Mac rental. GitHub Actions provides real macOS runners with Xcode preinstalled, so you can trigger a fully automated build, code sign, and TestFlight/App Store upload from a workflow file, kicked off from any OS. That's more production stable than a MacinCloud/AWS Mac remote desktop session since there's nothing to babysit, it just runs like any other CI job and reports pass or fail. You'll still need a paid Apple Developer Program account for the certificates either way, that part doesn't change. I built a $99 one time pipeline that sets this exact GitHub Actions workflow up for you (React Native included) if you'd rather not hand roll the config yourself: https://macless.dev/?utm_source=appledevforums&utm_medium=referral&utm_campaign=outreach