I got the exact same issue. No changes made on our side. It just stopped working. We actually perform notarization manually in our ci_post_xcodebuild.sh script. Maybe that is interfering. We actually don't use the artifact of the notarization step, but when we remove it the CI_DEVELOPER_ID_SIGNED_APP_PATH, which we need in the post build script, won’t be set...

I have also created a very simply sample project to demonstrate this. It is basically just the template that XCode generates when you set up a new share extension. I have only adjusted the activation rule as shown above. https://github.com/greimers/sharry-share-extension-sample

I have found that the release notes of Sequoia actually state that any app group format should work, when the app is distributed through the app store or includes it in the provisioning profile (highlights by me): Specifically, the app must use FileManager to get the app group container path and meet one of the following requirements: the app is deployed through Mac App Store; the app group identifier is prefixed with the app’s Team ID; or the app group identifier is authorised by a provisioning profile embedded within the app. Also, I have discovered in the release notes of macOS 15.1 beta 4 sate that it fixes the following issue: Fixed: Users might be incorrectly prompted when an app that is distributed through TestFlight attempts to access an application group container. (131606564) (FB14288230) I understand, that the security alert should actually not be shown and is currently only shown for XCode and TestFlight builds. I can verify, that no such alert is shown when I run the App Store version of my app. I haven't tested the new 15.1 beta yet, however. So this might actually not be a big issue after all. 😮‍💨

I have the exact same issue with my app. It seems that Sequoia expects the app group to start with the team identifier. But it is not possible to create a group identifier specifically for macOS in multi-platform targets and iOS groups always need to start with group. It is not even possible to create a separate target for macOS because XCode only allows one target per app identifier. This is a serious issue because the first thing users see when they launch the app is a security warning that is incorrect. Either macOS should also accept iOS style group identifiers or XCode should allow setting different identifiers for each system. Yet, the first would be much better, because otherwise, we would need to migrate existing data to a new group folder, which again requires the user to agree to the security alert.

I have the exact same issue in one of my apps. Some apps (e.g. Microsoft Outlook, Microsoft Teams) do not expose their accessibility tree and don't react to any manually set attributes. But when using VoiceOver or the Accessibility Inspector tool, the elements are accessible. It seems there is a secret flag to tell apps that accessibility is needed.

If you have In-App Purchases or Subscriptions in your app, you can determine the purchase environment from the Transaction object, which has an environment property. There are three possible values: sandbox, xcode, and production. So you cannot distinguish between development and TestFlight builds. But you can determine when you are not in production. So the combination of !DEBUG and transaction.environment != .production can be used to identify TestFlight users. You just need to get hold of some App Store transaction at some point. https://developer.apple.com/documentation/storekit/transaction/3963920-environment

I have this too. I had 4 complete system crashes since yesterday. I am wondering if that happens because my MacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports) only has 8GB of RAM. Because "Submission on work queue 36 failed due to insufficient space!" sounds like the Metal driver could not allocate enough memory. Of course this is still a severe bug and should be fixed by Apple. But I'm curious if people with 16 GB or 32 GB have this as well. I noticed my memory pressure often goes yellow when I run the simulator. Maybe testing on the simulator of an older iPhone with less RAM might be a workaround.

I could resolve this by completely removing (i.e. deleting) the App ID from the developer account. I have singing and certificates managed by XCode and this somehow got messed up. Deleting the App ID made XCode regenerate everything and not it's fine. (For context: This was on XCode 13 with targets set to iOS 15 and macOS 12.)

Lists seems to be lazy on iOS but not on macOS 12. It would be great to see lazy lists in macOS 13. There is also a discussion about List performance on macOS on StackOverflow.