Building iOS app invalidates provisioning profile when using document picker

[seba9999]

Build/Submit details page URL

No response

Summary

I've migrated to EAS build and in the same time I've used iCloud service with expo DocumentPicker.

So I'm no sur which is causing this issue...

But each time I launch a new build I'm facing Provisioning profile (id: *******979) is no longer valid

If I answer Yes to Generate a new Provisionning Profile it generate a new one correctly and it works ... But if I run the command again (like 10 sc later) the previous (freshly generated) provisionning profil is now invalid ...

It may be linked to iCloud. I've added "usesicloudstorage": true in my app.json I also have this configured in my app identifier :

With an container named iCloud.<your_bundle_identifier> as mentionned in the documentPicker docs

$ eas --version
eas-cli/0.50.0 win32-x64 node-v16.13.1

Managed or bare?

Managed

Environment

npx expo-env-info

``` expo-env-info 1.0.2 environment info: System: OS: Windows 10 10.0.19041 Binaries: Node: 16.13.1 - C:\Program Files\nodejs\node.EXE npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD SDKs: Android SDK: API Levels: 30 Build Tools: 30.0.3 System Images: android-30 | Google APIs Intel x86 Atom IDEs: Android Studio: Version 4.2.0.0 AI-202.7660.26.42.7351085 npmPackages: expo: ^43.0.0 => 43.0.5 react: 17.0.1 => 17.0.1 react-dom: 17.0.1 => 17.0.1 react-native: 0.64.3 => 0.64.3 react-native-web: 0.17.1 => 0.17.1 Expo Workflow: managed ```

Error output

No response

Reproducible demo or steps to reproduce from a blank project

I think it happens with any blank project

[marcfrankel]

I've been having basically the exact same issue, but do not use iCloud in our app

[wkozyra95]

This sth we are aware of, We don't have any plans to fix it in the near future, as far as I understand the only problem here is that profile is regenerated every time which is not a problem (you do not need to login to apple for every build)

[seba9999]

Well as far as I know I DO have to login for each build I want to send to testflight :/

And btw the certificat page will be a huge mess in a while ...

[wkozyra95]

Well as far as I know I DO have to login for each build I want to send to testflight :/

You don't need to login when building for appstore(for ad-hoc builds you do) if your have credentials already configured. For submitting you need to login only if you don't have ascAppId specified in eas.json.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.

[rafatrace]

Can we reopen this? This problem still happens to me with latest CLI versions.

[billinghamj]

@wkozyra95 Could you reopen this please? It's still an issue

[gbonventre]

Can you please reopen this issue. It does not appear to be solved yet.

[robertwe]

👍 same issue here. Any news on that?

[expo-bot]

Thank you for filing this issue! This comment acknowledges we believe this may be a bug and there’s enough information to investigate it. However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[brentvatne]

thanks, we'll investigate. you can work around this with EXPO_NO_CAPABILITY_SYNC=1 eas build for now, or re-generated the profile every build automatically. more info

[pkreipke]

This same thing started happening to us after following OneSignal's instructions for enabling Push Notifications when doing our next TestFlight build.

Note: I built for the simulator and for the dev-client without running into this issue and both builds correctly include the OneSignal packages - and the dev-client receives notifications from OneS correctly.

Now it's a bit unclear whether the workaround (EXPO_NOCAPABILITY_SYNC=1) should be used immediately or after the first capability sync. E.g. will I have our new push capability in a new build without doing the sync.

And if I get asked again, is Y or n the correct answer for the workaround?

[wkozyra95]

Now it's a bit unclear whether the workaround (EXPO_NOCAPABILITY_SYNC=1) should be used immediately or after the first capability sync. E.g. will I have our new push capability in a new build without doing the sync.

No workaround is strictly necessary, the only problem with the current state is that it regenerates a new profile even if it's not necessary. You should set EXPO_NO_CAPABILITY_SYNC when you know that there is nothing new to sync, so you need to run without that env only when changing entitlements in app.json or if are changing/adding/removing config-plugin that might modify entitlements.

And if I get asked again, is Y or n the correct answer for the workaround?

Answering no to login to apple prompt will also stop syncing profile, but e.g. internal distribution build requires login to apple, so it will not work in every case.

[kennethlynne]

Every time I run EXPO_DEBUG=true eas build --platform ios --profile profilename it figures out (incorrectly) that Provisioning profile (id: 6BJB75X655) is no longer valid, however it was created just seconds earlier using the same command and is listed as valid in the expo GUI until next year. This breaks our CI builds. I guess we'll have to resort to EXPO_NOCAPABILITY_SYNC=1 for now

[rafatrace]

Will this work properly if we update expo-document-picker?

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[billinghamj]

Still an issue, not stale

[arjendevos]

I'm not using expo-document-picker but i am using with-rn-image-crop-picker.

[edi]

Same issue here every single time.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[mguyard]

Issue is still here

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[alexbchr]

This is definitely an issue. Every time I have to change/select a certificate using the eas-cli, Certificates on Apple Developers get disabled.

[rajatbarman]

Are we getting a fix? :)

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[billinghamj]

Still a problem, not stale

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[billinghamj]

still not stale :|

[ChromeQ]

Same problem as @pkreipke once adding OneSignal to the mix, now every build incorrectly says provisioning file is invalid and generates a new one, next build the exact same thing. We need a fix as it is very annoying and adding the env var is likely to cause issues for some when changing entitlements as https://github.com/expo/eas-cli/issues/1069#issuecomment-1277391690 mentions and not knowing/remembering this is the "fix"

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[ChromeQ]

Not stale

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[ChromeQ]

Not stale

[ddehghan]

same here.

[rickithadi]

very fresh and not stale

[kuldip-simform]

I am getting this same issue. If anyone have solution for this please let me know.

[imwexpex]

Same with OneSignal extension

[brentvatne]

we'll certainly investigate this at some point, however because this doesn't actually cause any issues that we were aware of, it's not a top priority. you can do one of the following options:

• re-generate the profile as prompted to do, and there will be no negative side effects
• set EXPO_NO_CAPABILITY_SYNC=1 to opt out of automatic capability syncing
• run eas build -p ios --non-interactive to skip validating profiles until you need to re-generate one (eg: to add a new device uuid)

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[pehagg]

Still an issue, as far as I'm aware.

[thespacemanatee]

@brentvatne this is a huge issue if we manage our own certificates with Fastlane that we share across the team. This bug basically makes the whole system useless unless we run it with --non-interactive which means we can't take advantage of some of the interactive features.

[therealpurplemana]

I'm seeing this also

[kuldip-simform]

Getting this same error after adding push notification capabilities.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[kuldip-simform]

Not stale. Still facing this issue.

[alexbchr]

Same here, definitely still an issue

[timmyjose]

This is extremely annoying and error-prone - CI builds are failing due to this. Is there any plan to fix this at all?

[kuldip-simform]

I had to delete my provisional profiles and certificates and create a new one while creating the build. Only then did this issue get resolved, but for that build only, in the new build again I am having the same issue. Expo needs to address this right now.

[timmyjose]

I had to delete my provisional profiles and certificates and create a new one while creating the build. Only then did this issue get resolved, but for that build only, in the new build again I am having the same issue. Expo needs to address this right now.

Yes, it's rather confusing how it works with different combinations of actions as well. I wish the expo team would prioritise this. Right now, I'm using EXPO_NO_CAPABILITY_SYNC=1 for CI, and hoping that it all works consistently. That's not a solution though.