Right -- think I've had a breakthrough: the entitlements file for the appex shows its app ID as follows: [Key] com.apple.application-identifier [Value] [String] $(AppIdentifierPrefix)$(PRODUCT_BUNDLE_IDENTIFIER) while the main app shows a proper value: [Key] com.apple.application-identifier [Value] [String] XXXXXXXXXX.com.mydomain.MyApp For some reason, the Xcode variables weren't being substituted in the FileProvider! The surprise here is simply that the app worked for so long without the entitlements being validated... Anyway. I've confirmed that the app now presents the "entitlements validated" flag correctly on our older machines; once I hear back from the employee running this on Sequoia that it works now, I'll accept the answer here. Thanks!

Right. I've done a clean build (with only the one, new app group), the entitlements file is correct, and it runs with the correct entitlements on both my dev machine and a Ventura one. Curiously, though, the "entitlements validated" flag is still not showing as set. I'm waiting to hear back on the results from the Sequoia machine, but I expect that means it's still going to fail. So in the meantime -- could this be an issue with notarization rather than signing? I've just discovered that because we're distributing the app in-house rather than through the App Store, the installer package for these internal releases hasn't been going through notarytool. Is that a deal-breaker under the newer OS versions?

Thanks, Quinn! The first problem is that the "entitlements validated" flag is not set -- here's the relevant text: code signing info = valid refuse invalid pages kill on invalid pages require enforcement allowed mach-o platform dyld And the codesign result shows that the new app group is not present, just the old one: Executable=/Applications/MyApp.app/Contents/PlugIns/EMPFileProvider.appex/Contents/MacOS/EMPFileProvider [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] keychain-access-groups [Value] [Array] [String] XXXXXXXXXX.com.mydomain.MyApp.Shared [Key] com.apple.security.application-groups [Value] [Array] [String] group.com.mydomain.MyApp [Key] com.apple.application-identifier [Value] [String] $(AppIdentifierPrefix)$(PRODUCT_BUNDLE_IDENTIFIER) ...which is odd because the embedded.provisionprofile inside the .appex lists all three: <key>com.apple.security.application-groups</key> <array> <string>group.XXXXXXXXXX.com.mydomain.MyApp</string> <string>group.com.mydomain.MyApp</string> <string>XXXXXXXXXX.*</string> </array> This looks like there's something freaky going on in the signing of the app -- like it's somehow signing against an outdated version of the entitlements file somewhere? I'll try a complete rebuild and get back to you ASAP.

OK, I've successfully changed the app group to iOS style (group.com.myorg.MyApp)... and it hasn't fixed the problem. It's working on older versions, but still failing on Sequoia. To confirm: Both the main app and extension have an explicit app ID (com.myorg.MyApp and com.myorg.MyApp.EMPFileProvider, respectively). I have added an App Group identifier on the website for group.com.myorg.MyApp -- the website won't let me add one in the old macOS format (I understand this is normal). On the website, in the Identifier entry for each component, I've added group.com.myorg.MyApp to the existing App Group set. This has required me to re-generate the provisioning profiles. On the Profiles page, I regenerated the profiles (by choosing Edit and then Save rather than deleting and re-creating them). I downloaded and installed the new profiles. The resulting app works fine on a pre-Sequoia machine. But on the Sequoia one, the main app runs successfully (and can log to the Group Container), and the FileProvider also runs, but the FileProvider can not write its logs, read its prefs, or access the connecting pipe. We still get the following errors in the Console log (filtered on "fileprovider”), which indicate that even though it’s got the appropriate application-groups entitlement, it’s not able to access the prefs or create the log files: default 16:26:01.341453-0700 EMPFileProvider container_create_or_lookup_app_group_path_by_app_group_identifier: success error 16:26:01.342562-0700 EMPFileProvider Couldn't read values in CFPrefsPlistSource<0x7f83db71aab0> (Domain: group.com.mydomain.MyApp, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd error 16:26:01.344858-0700 cfprefsd rejecting read of { group.com.mydomain.MyApp, mikec, kCFPreferencesAnyHost, /Users/mikec/Library/Group Containers/group.com.mydomain.MyApp/Library/Preferences/group.com.mydomain.MyApp.plist, managed: 0 } from process 1791 (EMPFileProvider) because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access fault 16:26:01.346167-0700 EMPFileProvider Couldn't read values in CFPrefsPlistSource<0x7f83db7104d0> (Domain: group.com.mydomain.MyApp, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access error 16:26:01.347646-0700 cfprefsd rejecting read of { group.com.mydomain.MyApp, mikec, kCFPreferencesAnyHost, /Users/mikec/Library/Group Containers/group.com.mydomain.MyApp/Library/Preferences/group.com.mydomain.MyApp.plist, managed: 0 } from process 1791 (EMPFileProvider) because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access fault 16:26:01.347939-0700 EMPFileProvider Couldn't read values in CFPrefsPlistSource<0x7f83db7104d0> (Domain: group.com.mydomain.MyApp, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access error 16:26:01.349210-0700 kernel 1 duplicate report for System Policy: EMPFileProvider(1791) deny(1) file-read-data /Users/mikec/Library/Group Containers/group.com.mydomain.MyApp/Library/Preferences/group.com.mydomain.MyApp.plist error 16:26:01.351654-0700 cfprefsd rejecting read of { group.com.mydomain.MyApp, mikec, kCFPreferencesAnyHost, /Users/mikec/Library/Group Containers/group.com.mydomain.MyApp/Library/Preferences/group.com.mydomain.MyApp.plist, managed: 0 } from process 1791 (EMPFileProvider) because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access fault 16:26:01.352056-0700 EMPFileProvider Couldn't read values in CFPrefsPlistSource<0x7f83db7104d0> (Domain: group.com.mydomain.MyApp, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access error 16:26:01.357264-0700 kernel 1 duplicate report for System Policy: EMPFileProvider(1791) deny(1) file-write-create /Users/mikec/Library/Group Containers/group.com.mydomain.MyApp/Library/Logs/cloud1791_2.log error 16:26:01.357269-0700 kernel System Policy: EMPFileProvider(1791) deny(1) file-write-create /Users/mikec/Library/Group Containers/group.com.mydomain.MyApp/Library/Logs/cloud1791_3.log default 16:26:01.360168-0700 EMPFileProvider Extension `/Applications/EMPSecure.app/Contents/PlugIns/EMPFileProvider.appex/Contents/MacOS/EMPFileProvider` of type: `1` launched. For the record, here are the Entitlements in the embedded provision profile in the main app: <key>Entitlements</key> <dict> <key>com.apple.security.application-groups</key> <array> <string>group.XXXXXXXXXX.com.mydomain.MyApp</string> <string>group.com.mydomain.MyApp</string> <string>XXXXXXXXXX.*</string> </array> <key>com.apple.application-identifier</key> <string>XXXXXXXXXX.com.mydomain.MyApp</string> <key>keychain-access-groups</key> <array> <string>XXXXXXXXXX.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>XXXXXXXXXX</string> </dict> And here are the ones in the FileProvider extension: <key>Entitlements</key> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider-systemextension</string> <string>app-proxy-provider-systemextension</string> <string>content-filter-provider-systemextension</string> <string>dns-proxy-systemextension</string> <string>dns-settings</string> <string>relay</string> <string>url-filter-provider</string> <string>hotspot-provider</string> </array> <key>com.apple.security.application-groups</key> <array> <string>group.XXXXXXXXXX.com.mydomain.MyApp</string> <string>group.com.mydomain.MyApp</string> <string>XXXXXXXXXX.*</string> </array> <key>com.apple.application-identifier</key> <string>XXXXXXXXXX.com.mydomain.MyApp.EMPFileProvider</string> <key>keychain-access-groups</key> <array> <string>XXXXXXXXXX.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>XXXXXXXXXX</string> </dict> Note that there are multiple app groups present -- I didn't remove the old one in Xcode when I added the new one! Surely a failure with that one couldn't block a perfectly valid app group alongside it? Anything else I should look for in the console logs to check which app groups the extension actually has access to?

Final answer was the comment posted to Matt's response: the app group container was correct, but the bundle identifier was different between the main app and extension, and Dropbox's retrieval code was using the bundle identifier as part of its search string! I also had to patch the Dropbox Swift toolkit so that it stored the token with the kSecAttrAccessGroup attribute set to the Keychain Access Group value, and the kSecUseDataProtectionKeychain attribute set to TRUE -- the documentation at https://developer.apple.com/documentation/security/keychain_services/keychain_items/sharing_access_to_keychain_items_among_a_collection_of_apps glosses over the fact that you need to set either kSecUseDataProtectionKeychain or kSecAttrSynchronizable for kSecAttrAccessGroup to work.

Further update: this is odd. I noticed the Dropbox tokens were originally being written with a minimal set of attributes and no access control: acct = 1.....9 labl = com.orexresearch.EMPSecure.dropbox.authv2 class = genp svce = com.orexresearch.EMPSecure.dropbox.authv2 mdat = 2022-01-10 11:10:03 +0000 cdat = 2022-01-10 10:46:08 +0000 So I'm calling SecItemUpdate with the following entries in the query:             (kSecAttrAccount as String): key as AnyObject         (kSecClass as String): kSecClassGenericPassword         (kSecAttrService as String) : "(bundleId).dropbox.authv2" as AnyObject?         (kSecAttrAccessible as String) : kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly ...and the following attributes to be updated:         attributesToUpdate[kSecAttrAccessGroup as String] = "CD......7C.com.orexresearch.EMPSecure.Shared" as AnyObject?         attributesToUpdate[kSecUseDataProtectionKeychain as String] = true as AnyObject? This returns a value of 0, so it appears to succeed... but when I query the entry again, the extra attributes haven't been added. Do I need to delete and re-add the whole entry for this to work?

Update on my update: it doesn't look likely that there's a mismatch. Both the main app and the extension have identical embedded.provisionprofile files, with the same CD......7C value for ApplicationIdentifierPrefix, com.apple.developer.team-identifier, com.apple.application-identifier (with a .), and keychain-access-groups (also with a .). There's no mention of the 3R......RQ app group anywhere in either. (Should there be? It's still being used to share the Group Containers subfolder with the other app extension...)

Further info: this may relate to this issue: https://developer.apple.com/forums/thread/118773 The main app was built a few years ago in an earlier version of Xcode, and it may have a unique app identifier rather than using my Team ID. In the above example, the Team ID is CD......7C, but I have an app group which has been working all this time to allow communication with another extension, and its prefix is 3R......RQ. Do I need to swap everything to use the Team ID, and if so how would I do that?

Found the fix! The ibtool crash logs pointed to the problem being in Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib . Turned out it was this known issue: https://stackoverflow.com/questions/64817964/xcode-10-3-does-not-work-on-macos-big-sur-11-0-1-non-beta . The solution was to install a newer XCode (12.5), and copy its libMainThreadChecker.dylib into the XCode 10 package. Saved me having to start all over again with a Mojave VM!

Update: the Bus Error is also occurring when I try to run ibtool, in the Storyboard phase.