The S4A IDE Mac app store app used to use a group container to communicate between the main app and the XPC service that did the build, so it could share files for the build. It's time to hand over the app to a friend but I was blocked from transfer because the App Store says I was using a shared group container. I rewrote the main app and XPC service to pass a security-scoped URL via bookmark from the main app to the XPC and removed all entitlements for the group container. Cleaning out all containers and restarting the app, it still works but I can see no group container is created in ~/Library/Group Containers (it used to be with the old app). However, when I uploaded this app, after it passed app review I was still unable to transfer it, with the same error message. I then looked at the app id on developer.apple.com and realised the app id still had group containers even though I'd removed the entitlement from all entitlement files being used in the Xcode project. So I removed it from the app id on the developer portal too, and recreated the provisioning profile the app was using, then rebuild the app again and did another app submission. That's approved and on the App Store but I'm still seeing the message that I can't transfer the app due to a group container. Getting a bit confused now why the App Store still thinks I'm using group containers and is blocking this? edit: I scoured the code and found this code still in an obscure part of the app... let container = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: sharedGroupContainer) { ...although I think this probably returns a nil and just does nothing with it, the App Store might be seeing this API being used and think I'm still using group containers? Carl footnote: unfortunately I've also got locked out of my account temporarily due to a billing issue, so I can't try much until I resolve that, but it would be great to get some ideas what to try once I get back in.

Hi, I'm trying to upgrade my app ready for the mac app store. After a lot of battles with fitting command line tools into the code signing frameworks required (inside out code signing, etc.) I finally found a way forward. It has literally taken me two years. Now I'm trying to get the app to run in sandbox. I'm having trouble accessing shared memory. The architecture is this: a mac app, with a bundled XPC service (the "build engine") and that has bundled (signed) command line tools it runs. The tools are in <XPC bundle>/Contents/MacOS as they should be and are code signed manually by a script I wrote with the hardened runtime option and with entitlements like this: <?xml version="1.0" encoding="UTF-8"?> <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>DELETED FOR PRIVACY</string> </array> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> <key>com.apple.security.device.serial</key> <true/> <key>com.apple.security.device.usb</key> <true/> <key>com.apple.security.get-task-allow</key> <true/> <key>com.apple.security.inherit</key> <true/> </dict> </plist> The same entitlements for both the XPC and it's bundled command line tools. The XPC service passes data to the command line tools using shared memory. This should be possible in a sandboxed app with the use of application groups? The error in the log is like this...

Hi, We are developing an Enterprise SSO extension for use by our customers. It is working well for username/password. We would like to use external security tokens such as Yubikey, via NFC. This works well inside the container app. However, it looks like NFC might not be available to the SSO extension? The container app is signed with an NFC entitlement, and has the relevant key in the plist for a prompt to show the user. We use a 3rd party package called Yubikit to communicate with the Yubikey in the container app... all good. In the trial I did, I had the SSO appex configured as a Credential extension. I have a demo/sample host app that uses this service, that mirrors what our customer's apps will do. Currently, due to limitations in the server we are connecting to, instead of relying on a 401 authentication challenge, I am "manually" activating the enterprise SSO credential appex using ASAuthorizationSingleSignOnProvider, then our customer's host app will use the token the SSO appex returns for authenticating its API calls. This is working perfectly for the username/password scenario. However some of our customers are very security conscious and require hardware tokens. When I drive the same code in the contained SSO Enterprise app extension, and attempt to activate the NFC reader the same way, it seems like it doesn't have access to NFC? I attempted to add the entitlement to the appex as well but it wasn't even available on the list of entitlements! This leads me to suspect that iOS doesn't allow the SSO appex process to have access to the NFC reader, and there's no way to do what I'm attempting? Note: it is easy for us to move to using a Redirect extension instead if this is the answer, but it doesn't seem that it's likely to help? What is the recommended approach here? Regards, Carl

Hi, a short question really, which boils down to... How do I make sure I have removed all usage of app groups in my Mac app store app, such that the Mac app store agrees I have! Fundamentally, what I'm trying to do is transfer my app to another developer. In previous releases of this app on the App Store, I used a shared app group container to communicate between the main app and it's (embedded) XPC service, but this blocks App Store transfer of the app to another developer. So I came up with another approach for the App and XPC service to communicate (using a URL bookmark for security scoped files to be passed to the XPC service). And then tried various things to get the app store to accept that I'm no longer using app groups. So far with no luck... removed the app groups entitlements by hand from the entitlements files used to sign the main app and the XPC service, respectively. when that didn't work, go into the Developer Portal, find the app ids for the main app and the XPC service, make sure those app ids had the app groups entitlement removed too, created a new provisioning profile for the app, based on this updated app id, downloaded it, rebuilt an app archive using this updated provisioning profile and used it to create another new release on the app store when that didn't work, found and deleted all app app groups in my developer account in the developer portal itself None of the above worked. When I try to transfer the app in App Store Connect, I still see the same message, "You can't transfer this app because of the following reasons: Sandboxed Group Container You can only transfer sandboxed apps that are not sharing a group container." I'm now pretty far from using a shared group container, so I'm puzzled why it still thinks I am? There is one last thing I can try... I noticed over the weekend that even though the entitlement is gone, there's one place in code that may or may not be run on rare occasions (hard to tell) that attempts to open the app group shared container with the code... let container = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: ...which I think is just returning nil and doing nothing. Potentially the App Store sees that attempted API access for shared group containers and assumes I'm still using app groups (even though there's no entitlement so that call will always be failing)? I can do yet another App Store update and just remove that code. But I want to get to the bottom of why it has been failing all this time. What is App Store Connect / the Mac App Store looking at that makes it think I'm still using app groups? I've tried so many things and don't want to mess users around with another App Store update unless this code above is the actual cause! Cheers p.s. It's a teamID based app group of the form... MY_TEAM_ID.s4a e.g. SWDC5K54B7.s4a