Provisioning profile missing entitlement

Question

Created 2w

Replies 5

Boosts 0

Participants 2

My iOS app uses CloudKit key-value storage. I have not updated the app in a few years but it works fine. Since it was last updated, I transferred the app from an old organization to my personal developer account. Now that I'm working on the app again I get an error: Provisioning profile "iOS Team Provisioning Profile: com.company.app" doesn't match the entitlements file's value for the com.apple.developer.ubiquity-kvstore-identifier entitlement.

In the entitlement file, it has $(TeamIdentifierPrefix)$(CFBundleIdentifier) as the value for iCloud Key-Value Store. I've verified the variables resolve as expected. When I parse the provisioning profile there is no entitlement value for key-value storage. What am I getting wrong?

Boost

Answer 1

DTS Engineer OP

Apple

6d

I want to start by understanding your goals. The com.apple.developer.ubiquity-kvstore-identifier value starts with your Team ID, and the app’s Team ID changed as part of the app transfer. That means that your new version of the app won’t be able to access settings created by the old version. Is that OK?

If so, we can dig into why Xcode is being snarky. But if it’s not OK — if, for example, you’ve stored critical user data in the iCloud key-value store [1] — then things get more complex.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] This is something I strongly recommend against. The UserDefaults subsystem, and thus the key-value store, is intended for preferences, not critical user data.

0

Answer 2

roanutil OP

5d

It's just preferences stored in the key-value store. So yes, it is acceptable for that data to be lost.

To clarify, I have updated the entitlement value with the correct Team ID.

0

Answer 3

DTS Engineer OP

Apple

4d

It's just preferences stored in the key-value store.

Cool.

I have updated the entitlement value with the correct Team ID.

OK. But you shouldn’t need to do that because Xcode should pick up the correct Team ID via the $(TeamIdentifierPrefix) syntax.

As to your main issue, I suspect that Xcode has cached something that’s causing this. In situations like this I generally approach the problem in two ways:

First, I create a new dummy test app, with a new bundle ID and thence a new App ID, to check whether this is working in general.
Once I’ve confirmed that, I then start trying to resolve the issue with my real project.

With regards that second step:

In Signing & Capabilities, make sure that “Automatically manage signing” is enabled, the new team is selected in the Team popup, and that Signing Certificate is set to Development.
Choose Product > Clean Build Folder.
Quit Xcode.
In Finder, navigate to ~/Library/Developer/Xcode/UserData/Provisioning Profiles.
And trash everything in that folder.
Relaunch Xcode and let automatic code signing do its magic.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

roanutil OP

2d

I've created a dummy test app with the same setup as the real one and signing works. However, after deleting derived data and all provisioning profiles, the real app still cannot sign.

0

Answer 5

DTS Engineer OP

Apple

21h

I've created a dummy test app with the same setup as the real one and signing works.

Cool.

after deleting derived data and all provisioning profiles, the real app still cannot sign.

Bummer.

So my next suggestion is that you create a new test project but this time choose the same bundle ID as your main app. If that works, there’s something about your main app’s project setup that’s causing the problem. OTOH, if it fails in the same way, it confirms that this is specific to the code signing setup.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0