Xcode 8: different entitlements for each scheme causing errors

Question

I found an issue with Xcode 8 where .entitlements files are not being referenced properly for each scheme. Basically, my Debug .entitlements file is being referenced for my Release scheme. This is causing an issue because we implemented the new Rich push notification logic and that requires the use of App groups.

I am using two different teams (Development and Production), so there will be two specific App Groups.

Flasket

I'm also having this issue. Our QA scheme is attempting to use our production value for the aps-environment entitlement, despite being properly configured in CODE_SIGN_ENTITLEMENTS Build Setting. – Headrest

@AlbertBori check my answer...it will help you. – Flasket

Answer 1

I found a solution. Make one .entitlements file add this:

<key>aps-environment</key>
<string>$(APS_ENVIRONMENT)</string>
<key>com.apple.security.application-groups</key>
<array>
    <string>$(APP_GROUP)</string>
</array>

Then in Target > Build settings Set the same .entitlements file in Signing > Code Signing Entitlements Add User-Defined Setting for APS_ENVIRONMENT and APP_GROUP setting the correct group for each target.

So, based on the target Xcode will use what you set for APS_ENVIRONMENT and APP_GROUP.

You can do this in plist too...did some amazing clean up today.

Flasket

I have used this solution for the past year or so but have found that occasionally the Apple dev center will show that a couple of the bundle IDs are associated with the wrong group, which can break manual codesigning. Quite often I will have to go in there and correct the association (only to have it change again later). Very hard to understand why/how that can happen and may depend on my setup, but the hunch is that Xcode is doing automatic things and doesn't like the variable. – Aten

@Tim Walsh. I think you might have defined $(APP_GROUP) and $(APS_ENVIRNMENT) somewhere. Can you help where are they? Or are they available by default – Cholon

@TejasSherdiwala Did you find answer? I'm also interested. – Dear

@Dear You need to set the variables APS_ENVIRONMENT and APP_GROUP as a User Defined Setting in Build Settings of you app – Flasket

Answer 2

Though Tim's solution mostly worked for me, Xcode got all upset and said automatic provisioning couldn't resolve issues with the entitlements file. I don't think it liked the variable.

Our solution was to:

1. Enable all app groups on every target that needed access.

2. Define a project-level user-defined setting called PROJECT_APP_GROUP for the app group name by going to Project -> Build Settings, clicking the "+" button, and selecting "Add User-Defined Setting."

3. Set a variable in the info.plist file for each target that needs access to your app group.

4. Then access the correct app group at runtime by getting the APP_GROUP variable from your target's info.plist file.

   + (NSString *)appGroupIdentifier
   {
       // this method returns the app group identifier by fetching it from the info.plist file.
       // this string is dynamic based on build scheme. for instance group.ourApp vs. group.ourApp-dev
       return [[[NSBundle mainBundle] infoDictionary] valueForKey:@"APP_GROUP"];
   }
   

OR

Now that I think of it, if you have preprocessor macros set up for each build, it might be easier to do something like:

+ (NSString *)appGroupIdentifier
{
#ifdef BUILD_DEV
    return @"group.myApp-dev";
#elif BUILD_STAGING
    return @"group.myApp-staging";
#else
    return @"group.myApp";
#endif
}

Splenomegaly

The downside with this approach is that your app is "using" all 3 groups at the same time. Sure you're controlling which one your code is looking at, but iOS thinks all are in use in some way. What that means is when you delete your dev app to test something from fresh install it won't empty the app group - you'll have to delete staging and prod apps as well. – Aten

@KieranHarper you're right, we found this out after some testing and ended up going with an approach more like Tim's. – Splenomegaly