iOS/OSX App Group Ids, start them with "group." or "team-id."?

Question

When creating a App Group id in the Provisioning Portal (or whatever its called now), it says to "Enter a unique identifier for your App Group, starting with the string 'group'" and seems to enforce that in the entry field. Also, lots of sample code uses app group id strings like "group.com.company.blah".

However, the definitive sections I've seen to linked throughout the documentation, App Sandbox Design Guide > App Sandbox In Depth > Container Directories and File System Access > The Application Group Container Directory and Entitlements Key Rerefence > Enabling App Sandbox > Adding an App to an App Group, directly contradict this, clearly stating "must begin with your development team ID, followed by a period".

The examples given in those section are like "Z123456789.com.example.app-group" and "DG29478A379Q6483R9214.HolstFirstAppSuite" respectively. (whah, is that last one a super weird team id or what?)

So with this inconsistency, what do I do to get a App Group ID to work? Should I enter in the Provisioning Portal "group.TEAM-ID.com.example.blah"? And should I use this same string in my source code strings, or omit the "group." part to be like the many code examples? Or is the documentation wrong and the team id is never needed?

Context ... I've been trying to update an iOS cocoapod's test app so I can see extension <-> app communication in action. After updating the app ids and group id to one's in my control, and when using a group id similar to the project's original one, like "group.com.mycompany.thingie", I see containerURLForSecurityApplicationGroupIdentifier: do nothing but return nil and nothing else has fixed it.

UPDATE: (added this for clarity seeing how SO informs me that this Q is getting many hits) It turns out this stuff is more forgiving than I originally thought, as the nil result turns out to have been (mostly?) my doing. See the answer & its comment thread. I haven't checked to see if the documentation & examples are any clearer yet.

Tapping

How to share app group UserDefaults in macOS github.com/onmyway133/blog/issues/201 – Rosio

Answer 1

On https://developer.apple.com inside "Certificates, Identifiers & Profiles" when you go to the "App Groups" section and first generate your App Group, all that is required is the enforced group.com.companyname.appname

As long as com.companyname.appname matches what you have setup as the bundle identifier for your target underneath general, you should be able to then go to "Capabilities" tab, turn on "App Groups" click the refresh symbol and the group you just created in Provisioning Portal should appear there, as "group.com.companyname.appname" you'll have the option to check it off, and then will have an error with entitlements. Clicking "fix issue" should automatically resolve it.

Now if you navigate to you entitlements file you'll notice that "com.apple.security.applications-groups" will have an item and it will be set to the exact same "group.com.companyname.appname" value.

I've tested on devices and have no issues yet. This doesn't account for the inconsistency in documentation, but I can guarantee that this works.

Showily

"As long as com.companyname.appname matches what you have setup as the bundle identifier" .. can't be true for both app and extension, or for a collection of multiple apps. So is there is there a restriction on the group id value following the "group." part or not? – Tapping

For an extension I saw in Apple's sample code from "WatchKit Catalog Watchkit App" that the bundle identifier picked up an additional section, like this "com.example.apple-samplecode.WatchKit-Catalog.watchkitextension" and then for the WatchKit App it also picked up an additional section "com.example.apple-samplecode.WatchKit-Catalog.watchkitapp" So then maybe the only restriction is the first part of the bundle identifier. – Showily

"maybe".. yup that mirrors my own confidence in all this. I was hoping to get definitive answers and all I've found is "this seems to work based on the sample code". Thanks for chiming in though, and as this seems to be there best anyone can say given the currently state of the documentation, will award your answer. – Tapping

Note: I just changed the bundle id of my app & extension, recreated a group id matching the app's bundle id, updating capabilities, info plists, strings in the app. All signing issues are fixed, all entitlements checkmarks are checked, everything builds without warnings, but was still seeing containerURLForSecurityApplicationGroupIdentifier: returning nil when called in the app --- which turned out to be a stupid programmer error: was sending that msg to a nil file manager instance. Perhaps it was working all along :^/ – Tapping

That's the beauty and irony of programming in complex IDE's like Xcode. Happy to chime in, glad you got it working! – Showily

For the record: The above should really work, but only for iOS targets. For OSX you need the $(TeamIdentifierPrefix)$(CFBundleIdentifier) format where the $(TeamIdentifierPrefix) is required and $(CFBundleIdentifier) is optional (can be anything unique you choose), if the $(TeamIdentifierPrefix) is not used as group id prefix you will get an error during validation of upload to the app store – Relent

The error would be something like this : Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on Mac OS X. Specifically, value for key 'com.apple.security.application-groups' is not supported. This value should be a string or an array of strings, each starting with your TEAMID followed by a dot '.' . – Relent

I confirm what @Relent said. The above only works for iOS. On macOSX, you CANNOT set App Group without it being prepended with your TeamID, and even if you add the App Group to a Developer ID Provisioning Profile, the profile DOES NOT include it. Also, in XCode, it does not include the App Group by default, and if you force it, you get an error when you execute the app. – Alyce

Answer 2

I got bitten by the inconsistency in this between iOS and macOS while submitting the macOS Sierra version of my app.

group.better.fyi works for iOS submissions but results in the following error during macOS submissions (runs perfectly well otherwise, with no warnings or errors):

ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '[group.better.fyi]' for key 'com.apple.security.application-groups' in 'ind.ie.Better-Mac.pkg/Payload/Better.app/Contents/PlugIns/Blocker-Mac.appex/Contents/MacOS/Blocker-Mac' is not supported. This value should be a string or an array of strings, each starting with your TEAMID followed by a dot '.' ."

Replacing that with $(TeamIdentifierPrefix)better.fyi in the Capabilities tab under App Groups fixed the issue.

This does, of course, create an inconsistency between the iOS and Mac apps.

Evasion

Right, but then you may get an error like "Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd " (#38275895) -- really weird situation. – Bookish

I didn't: AFAIK, this error message can be ignored since it is faulty and does not indicate a change in behavior. – Bookish

Answer 3

tl;dr version: https://mcmap.net/q/740818/-should-macos-app-group-name-start-with-group-or-development-team-id
But if you want to know all the details behind all this, please see below.

iOS

In the portal, all app group IDs created must start with group.; the portal will actually enforce that, so it's not even possible to register a group there without that prefix.

If the app group ID is then set on an app ID in the portal and an iOS provisioning profile is created for that app ID, the app group is embedded into the profile exactly as it has been registered. Take a look at such a profile and you will find the app group ID there.

If an iOS app has app group IDs in its codesign entitlement file, codesign will ensure that the group IDs from the entitlement are also found in the provisioning profile, otherwise it will refuse to sign the app. The provisioning profile thus whitelists the usage of these app groups.

When you configure an app group ID for an app in Xcode at the capabilities section, Xcode will put the ID into the codesign entitlements file for you. The app groups configured there for iOS apps must match exactly the app group IDs registered in the portal.

macOS

For macOS, though, things are entirely different!

If you add an app group ID to an app ID in the portal, this has no effect on macOS provisioning profiles created for that app ID. Have a look yourself; the app group ID is nowhere found in the generated profiles! Thus on macOS, a provisioning profile does not whitelist the usage of any app groups. You can put any app group ID into your entitlement files, this will always sign as codesign doesn't care. Codesign doesn't even care if your app group ID is prefixed by your team ID (or at least it didn't use to in the past, maybe it does as of today).

Unlike on iOS, the uniqueness of app group IDs on macOS is not enforced by the portal, it is enforced by the fact that Apple requires your app group IDs to start with your team ID, so uniqueness across teams is guaranteed and enforcing uniqueness within your own team is your own task.

Actually you don't need to register app group IDs for macOS apps at all in the portal. It's enough to just put your desired app group ID into your Xcode project capabilities and thus into your entitlement file. Many people think they have correctly registered their macOS app group when they register group.TEAM_ID.<whatever> in the portal and some magic makes this group work without group. prefix on the Mac, but that isn't the case. They just registered an iOS group of that name and the reason why TEAM.<whatever> works on the Mac is because that group doesn't require registration in the portal.

Now some readers will say: Wait a minute; if I can just put any app group ID into my entitlement files and it will always sign, who is actually enforcing that it is prefixed with my team ID? The Mac App Store. The Mac App Store won't allow you to publish an app with an app group ID that is not prefixed with the team ID of the publisher. If you try, the upload will fail.

App Groups and Security

You may wonder: Who is enforcing that app groups are prefixed by your team ID for apps distributed outside of the App Store? Nobody. But then apps distributed outside of the app store can claim to be a member of any app group, even one from a different developer team, so how would that be secure? It isn't. Apps distributed outside of the App Store don't even have to be sandboxed and if they are not sandboxed, they have access to your entire disk, including all app group folders of all apps, so how would that become any less secure by incorrectly claiming to be a member of an app group?

Apps distributed outside the App Store may be sandboxed if they wish to restrict themselves for security reasons but even if they opt-in to that, they are free to poke as many holes into their own sandbox as they need or desire since unlike when distributing via the App Store, there is no review that will ensure they only poke required and justified holes.

On iOS all apps are always sandboxed and distributed via the App Store, so this question doesn't even arise.

App Groups and Keychain Sharing

What about keychain item sharing? Keychain item sharing via app groups only works on iOS, not on macOS; for exactly that reason! It would be insecure on Mac. On macOS only sharing with keychain access groups works and those are in the provisioning profiles, also in macOS profiles, and for those codesign will always enforce that the profile whitelists them before it signs anything.

Reference from Apple

You'd like to have all of that confirmed directly by Apple? Sure, here is the reference provided by our most famous Apple tech support guru, Quinn:
https://developer.apple.com/forums/thread/133677?answerId=422887022#422887022

Etherege