Building macOS with App Groups using external CI/CD

Question

rookuuu OP

Created Jun ’23

Replies 5

Boosts 0

Views 2.4k

Participants 3

Howdy,

My macOS application uses app groups, using an entitlement file similar to the one below.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.application-groups</key>
	<array>
		<string>$(TeamIdentifierPrefix)com.example.test</string>
	</array>
</dict>
</plist>

This all works when using my local Xcode. However, when I push the job to our CI/CD server I get an error.

error: Provisioning profile doesn't include the com.apple.security.application-groups entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update.

Searching around, namely macOS Unsatisfied entitlements com.apple.security.application-groups and System Extension app-group entitlement issue tells me that I do not need to have the app group contained within my provisioning profile, due to how macOS handles App Groups differently to iOS.

Is there a way to tell xcodebuild on my CI box to ignore this and continue building?

Answered by rookuuu in 756076022

The exact problem rookuuu has happens when I attempt to build in my CI pipeline with the exact same provisioning profile and key. Specifically GitHub Actions + GitHub-Hosted Runners using GitHub instructions for installing profiles.

Sounds like we're in the same boat. However, I think I've found the solution.

When you run xcodebuild, if it picks up a provisioning profile with the extension ".mobileprovision", even though the target is macOS it runs the provisioning profile validation steps as if it was iOS. Raising the iOS specific errors about App Groups.

I followed the same document which similarly mislead me into changing the file extension away from ".provisionprofile", simply renaming them back in the example workflow did the trick for me. Hopefully it does for you also.

I've had the GitHub docs updated to include a note that reflects this, but this is probably also an Xcode bug that it's trusting the extension of the profile over the build target?

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’23

Searching around … tells me that I do not need to have the app group contained within my provisioning profile, due to how macOS handles App Groups differently to iOS.

That’s correct. I eventually distilled this down into a locked post: App Groups: macOS vs iOS: Fight!.

Is there a way to tell xcodebuild on my CI box to ignore this and continue building?

This check is platform-specific. I suspect that xcodebuild is confused as what actual platform you’re building for.

If you use xcodebuild locally, does that work?

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

0

Answer 2

rookuuu OP

Jun ’23

Thanks for the quick reply!

xcodebuild locally works perfectly fine.

In the build logs it does appear on the surface that the target is being correctly set to macOS.

--- xcodebuild: WARNING: Using the first of multiple matching destinations:
{ platform:macOS, arch:x86_64, id:4203018E-580F-C1B5-9525-B745CECA79EB }
{ platform:macOS, name:Any Mac }
Prepare packages

Computing target dependency graph and provisioning inputs

0

Answer 3

DTS Engineer OP

Apple

Jun ’23

Is this Xcode Server? Or Xcode Cloud? Or something else?

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

0

Answer 4

ffernandez-zorus OP

Jun ’23

I'm also experiencing this issue so I figured I'd throw my own details on here in case they help.

I am building a macOS System / Network Extension. I can build locally with both Development and Developer ID keys using XCode. As soon as I move towards xcodebuild (locally), I need to have the provisioning profile installed by downloading it from the Developer Portal and double-clicking it, etc.

xcodebuild -scheme Extension -configuration Release -destination "generic/platform=macOS"

The exact problem rookuuu has happens when I attempt to build in my CI pipeline with the exact same provisioning profile and key. Specifically GitHub Actions + GitHub-Hosted Runners using GitHub instructions for installing profiles.

If I remove the profiles locally on my machine and attempt to install the provisioning profile using GitHub instructions (rename {ProfileName}.provisionprofile to {ProfileGuid}.mobileprovision and add to ~/Library/MobileDevice/Provisioning Profiles) it has the same error.

If I instead just ask xcodebuild to allow for provisioning updates by including -allowProvisioningUpdates -authenticationKeyPath {KeyPath} -authenticationKeyID {KeyId} -authenticationKeyIssuerID {IssuerId}, it does work and I can see a blip for a second as it adds the profile to the same location with the same name and then removes it.

On my CI pipeline, as long as I only keep the portions of the GitHub instructions for installing profiles that involve deploying the Developer ID certificate and instead just add secrets for my authentication key and add the same parameters to xcodebuild, everything is green and good.

Is there anything we can do to avoid having to add an Authentication Key to our CI pipeline?

0

Answer 5

rookuuu OP

Jun ’23

Accepted Answer

The exact problem rookuuu has happens when I attempt to build in my CI pipeline with the exact same provisioning profile and key. Specifically GitHub Actions + GitHub-Hosted Runners using GitHub instructions for installing profiles.

Sounds like we're in the same boat. However, I think I've found the solution.

When you run xcodebuild, if it picks up a provisioning profile with the extension ".mobileprovision", even though the target is macOS it runs the provisioning profile validation steps as if it was iOS. Raising the iOS specific errors about App Groups.

I followed the same document which similarly mislead me into changing the file extension away from ".provisionprofile", simply renaming them back in the example workflow did the trick for me. Hopefully it does for you also.

I've had the GitHub docs updated to include a note that reflects this, but this is probably also an Xcode bug that it's trusting the extension of the profile over the build target?

2