can I use an app group capability with a wild card app ID?

Question

Created Apr ’21

Replies 8

Boosts 0

Views 3.7k

Participants 3

Hi,

We're an app-vendor that uses a wild card app ID for our development and beta builds. We're working on a feature that requires app groups but seems like that isn't supported with a wild card app ID? Is there a way to do this?

I understand wildcard app IDs are meant for apps that don't require specific capabilities, but I'd like to roll this feature across *all* the apps that have that wild card app ID, so is there a way to do this or do I need to figure out how to support all those apps with individualized app IDs and a profile for each??

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’21

What platform are you targeting? This matters because App Groups behave very differently on macOS than they do on iOS and its descendents.

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

0

Answer 2

abushnaq-work OP

Apr ’21

iOS and iPadOS.

0

Answer 3

DTS Engineer OP

Apple

May ’21

In that case the answer is “No.” On iOS and friends access to App Groups is controlled by the com.apple.security.application-groups entitlement and that must be allowlisted by a non-wildcard profile.

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

0

Answer 4

texas_dev OP

Apr ’23

@eskimo: are entitlements like Hotspot and Access WiFi Information also disallowed with wildcard profiles?

0

Answer 5

DTS Engineer OP

Apple

Apr ’23

are entitlements … also disallowed with wildcard profiles?

You can work this out for yourself:

In Developer > Account > Identifiers, create a wildcard App ID.
Edit the App ID to see what capabilities you can set.

It’s a very short list.

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

0

Answer 6

texas_dev OP

Apr ’23

Appreciate the quick turn around! That seems like a different thing though (granted, the end result may be the same?). I asked about a wildcard (provisioning) profile and what you outlined is for a wildcard app. My situation is about a wildcard distribution profile being used with (multiple) explicit app ids.

Is your response valid for all situations involving either wildcard profiles and/or wildcard app ids?

0

Answer 7

DTS Engineer OP

Apple

Apr ’23

That seems like a different thing though

Not really. Every provisioning profile is bound to a specific App ID [1]. A wildcard profile is simply a profile bound to a wildcard App ID. The entitlement allowlist in the profile is generated from:

The capabilities of the App ID
Plus any additional entitlements you apply when creating the profile [2]
Modified by any platform or distribution method restrictions

My situation is about a wildcard distribution profile being used with (multiple) explicit app ids.

That an unusual setup. I can see how you might get into this situation with manual signing but, if you use automatic signing, Xcode will see the explicit App ID and create a profile based on that.

Regardless, my general advice is that you steer clear of wildcard profiles. They’re fine when you’re creating tiny test projects — something I do about a bazillion times a day — but for a real product it’s best to make everything explicit.

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

[1] If you’re curious how this works, see TN3125 Inside Code Signing: Provisioning Profiles.

[2] See the Old Process section of Using the Multicast Networking Additional Capability.

0

Answer 8

texas_dev OP

Apr ’23

Roger roger, thanks!

I can see how you might get into this situation with manual signing

Precisely, yep :/ Once upon a time the automatic signing (and associated certificate/profile resolution) wasn't playing nicely with our build machines for enterprise apps so we switched to manual. Will allocate some time soon to explore deeper. As always, your insights are appreciated!

0