How to solve "entitlement 'keychain-access-groups' has value not permitted by a provisioning profile"

Question

I am using keychain in my app and I get this error when run app as AdHoc. It doesn't appear when I run it with debugger (with developer provisioning profile). If app has already been installed on the device and I install it again on top of it from Xcode then I notice that app doesn't have access to keychain. It happens certainly because of those error.

I have spent much time googling that error and some recommends to add entitlements file with keychain-access-group in it. But I could not find any Apple doc or any reasonable explanation what entitlements file needed for.

Can someone help me to solve it?

Bridegroom

Answer 1

There is a pretty old post here you need the entitlements to say which Bundle Identifier you App's Bundle seed is under since that is the way KeyChain allows your application to access it by.

Once two Applications have the same Bundle identifier in their bundle seed, they can share KeyChain access..

So if Application A has a Common Bundle Id: com.yourcompany.AAAAAA And application B as a Common Bundle Id com.yourcompany.BBBBBB

And if they both have an entitlements file in their .ipa (plist containing an array keyed "keychain-access-groups" with a string ".com.yourcompany.AAAAA" and .com.yourcompany.BBBBB")

They can share KeyChain access..

• Regarding your Debug/AdHoc issue. in the project settings, check under "Code Signing"->"Code Signing Entitlements" that both are empty..

Pneumatograph

Nowadays, the prefix referred to as "App's Bundle seed" is automatically added by Xcode via variable. The entitlements file will look like this within the keychain access group: $(AppIdentifierPrefix)com.your.entry – Foretopgallant

Answer 2

I found a solution. The appID prefix seems to be different for adHoc and Debug profiles.

Let's assume we have the following AppIds:

• a.com.mycompany.A (ad hoc builds)
• b.* (debug/development builds)

The second id was created by Xcode and its prefix is used to sign the debug version of the app. The first id is used to sign the AdHoc version of the app.

If you now try to use the keychain with the accessgroup a.com.mycompany you get keychain access for the AdHoc version. If you use the accessgroup b.com.mycompany you get access in the debug version. None of them work for both.

I solved the Problem by creating an new wildcard id: a.* and using it for the "iOS Team Provisioning Profile: *". It seems that this provisioning profile is somehow used to sign a debug build of the app. I actually thought it uses the Development Provisioning Profiles to sign it ?!

However, with this change I was able to access the keychain in debug and adHoc mode with the same access group.

It seems like new registered users don't run into this problem, now Xcode automatically creates an id with the right prefix.

Xylotomy

Answer 3

In addition to the solutions mentioned above, I ran into a different variant of this issue.

My organization identifier changed (may be related to accepting the latest agreement update on developer.apple.com) and so the prefix for my app changed. So whereas before it was maybe ABCCYZ0U812.com.whatever.app now it was 90210SUXX11.com.whatever.app

When I went to go submit and you get the screen that says "Sends (app name) to Apple" and there's a listing called "Binary and Entitlements", when I would expand the listing under my app (twice, since I guess Xcode has a bug the first time) I would see something like

AppName.app (5 entitlements)          (provisioning profile) (arrow)

application-identifier
90210SUXX11.com.whatever.app

...

keychain-access-groups
ABCCYZ0U812.com.whatever.app

com.apple.developer.team-identifier
90210SUXX11

So for some reason it was still using the old team identifier for the keychain-access-groups bit but that now didn't match the new team identifier

I did the following

1. Clicked the arrow next to the provisioning profile to open Finder to the place where the profiles are held
2. Deleted all the .mobileprovision files in that directory
3. Closed out of submission dialog
4. In Xcode, Click Xcode -> Preferences -> Accounts and had my account re-download the provisioning profiles
5. Tried to submit the archive again

Now everything matched and it worked

AppName.app (5 entitlements)          (provisioning profile) (arrow)

application-identifier
90210SUXX11.com.whatever.app

...

keychain-access-groups
90210SUXX11.com.whatever.app

com.apple.developer.team-identifier
90210SUXX11

There may be a more delicate way to fix it without deleting everything but that should put you on the right track.

Oscillation

Answer 4

As mentioned in the other answers, this is due to the wrong provisioning profile being used.

I had this problem in Xcode 6. I had two targets in my project, and one of them always built with the wrong profile, no matter what I did (including changing the Provisioning Profile setting in Build Settings).

After hours of playing around with it, I noticed the following:

1. The good target was using a provisioning profile called "XC: com.mycompanyname.mytargetname1"
2. The broken target was using a profile called "XC: ". This profile is the "Xcode: Wildcard AppID ()" profile.

I don't know where either of these came from, but what I did to fix my problem was this:

1. Log into developers.apple.com
2. Go to Certificates, Identifiers & Profiles
3. Clicked on "All" under Provisioning Profiles on the left bar
4. Clicked on "+"
5. Created a new profile called "XC: com.mycompanyname.mytargetname2" (NOTE: the settings will be specific to you. The com.mycompanyname.mytargetname2 should be replaced by your app's bundle ID.

After that it worked.

Stumpy

That may have caused it, but I have this error with only a single provisioning profile (and have only ever had one). – Sevier

Answer 5

In ran into this same issue and several variations therein (error ITMS-90164, among others). After fiddling with various settings for hours, to no avail, I finally, reluctantly, followed Apple's Technical Q&A QA1814: Setting up Xcode to automatically manage your provisioning profiles. The steps are very simple and straightforward, complete with screenshots and the ever-important note to recycle Xcode after you're done making the changes. Most importantly, it resolved my issue(s) and allowed me finally to upload my archive to the App Store.

Specular