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]

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]

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]

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

[github-actions]

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]

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]

Still not stale

[chrysb]

Just started realizing that this is happening — why is invalidating the provisioning profile with every build? Seems egregious

[kuldip-simform]

Yep @chrysb It should not happen and they are not responding in any manner that why this is happening or when they are planning any fix.

[jwktje]

I'm having this problem too!

[PriimeTime]

I started having this problem after enabling signin with apple in firebase console (not sure if even related).

[brentvatne]

hey folks, here's where we're at on this:

• you can opt out of having EAS manage your capabilities (which is what is leading to this behavior) with EXPO_NO_CAPABILITY_SYNC=1 eas build (original comment docs).
• we are aware of the issue but aren't sure what the right approach is to fix it, and invalidating the provisioning profile doesn't have any negative side effects as far as we are aware, so we are focusing on higher priority work and will come back to this in the future when we have bandwidth to deal with it. please correct me if i am wrong and this is actively causing issues for your project.
• if you would like to investigate and suggest a solution, it'd be much appreciated!

[github-actions]

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

[breezertwo]

Having the same issue after adding document-picker

[pitbot]

Having the same after setting up expo-widgets

[statico]

Yet another team experiencing this for the first time. It ate a few days of my time, and the fix is elusive. I've spent two whole days adding debug statements to eas-cli, checking GraphQL requests with ProxyMan, the openssl CLI, fiddling with Apple Connect and certificates and capabilities, and lots more.

Capability syncing seems like a red herring at first because, why would I touch our app's capabilities if they haven't changed in years? I ignored that part of the docs for a while.

How about a breadcrumb for people in the same situation as me? Possibly change the error message after "no longer valid" to say something like, "If this seems like an error, please refer to [URL to this issue]"

<3

[kuldip-simform]

This is widespread issue, why expo team is not replying or helping us to guide in direction that can fix this issue.
I am not sure what is causing this issue and how to fix this.

[statico]

@kuldip-simform et. al,

1. Erase all (or at least all app-related) credentials and provisioning profiles from Apple Connect here and here
2. Run eas credentials and recreate all the credentials you need
3. Only run eas build with a EXPO_NO_CAPABILITY_SYNC=1 prefix so that eas-cli no longer touches and invalidates provisioning profiles

[github-actions]

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

[64bits]

I'm guessing this is about to be stale'd again: not stale.

[vonovak]

Hello and thanks for commenting,
I do plan to look into this but I'm currently dealing with other tasks and don't have a clear timeline for this.

Let me also reiterate that if someone were to investigate and suggest a solution or pinpoint where the problem is happening, it'd be much appreciated!
Another way to help would be to give step-by-step instructions on how to reproduce the problem from a clean state - I haven't found these in the discussion.
Either of these will enable a faster issue resolution.

If anyone's interested, the code is open source and has a contributor guide.

Thank you! 🙂