My CloudKit enabled macOS apps are suffering from exact the same error message when running macOS 12 beta 4. This happens on 2 different Macs running the same beta. As if developing for Apple is not already challenging enough.

I'm currently seeing similar errors "Account Temporarily Unavailable" (1028/2011); "Account temporarily unavailable due to bad or missing auth token" in Xcode 13 when running a macOS CloudKit app. This happens on two different Macs with macOS 12 beta 4. CloudKit account is 'available', but all syncing operations fails with this error. The same app downloaded from the Mac App Store runs and syncs without errors. Update: I'm also sometimes seeing this error: "Not Authenticated" (2011); "User rejected a prompt to enter their iCloud account password".

See also https://developer.apple.com/forums/thread/685918

I actually see the authentication prompts mentioned by cyclic, just before executing a CloudKit operation on beta 4. When I reject these prompts, I see error message "User rejected a prompt to enter their iCloud account password". When I enter my credentials, I see the error message where this whole thread is about. I'm not sure if it's relevant, but I only see the authentication prompt on devices without two factor authentication, every time when I start a new CloutKit operation. It seems that Apple is experimenting in a very buggy way with new errors messages, while in the meantime we (third party app developers) can't proceed with our normal work.

The Resolution status of the feedback report I made for Apple is now "Potential fix identified - In iOS 15".

I think that Apple wants to prevent at any cost that a production container gets deleted due to a software bug. And if I must choose between being able to delete containers (not deployed in production, that must be the main criterium), or a very small chance that I loose one of my production containers due to a software bug (by Apple or any other party), I would always choose to not being able to delete containers, and continue living with all those unused (incorrectly named, test or temporary) containers.

Mac apps installed by TestFlight do also have a receipt.

I have currently the same problem with all my Mac apps, on all my Macs, on macOS versions from 10.14 to 12.1. How is it possible that this isn't solved yet? Or are a lot of Mac developers simply skipping the receipt validation? The workaround to use SKReceiptRefreshRequest only seems to work on macOS 11 and 12, with some drawbacks. On 10.14 and 10.15 I get the same error as using "exit 173". The only thing we can and must do is file a Feedback report. I have read that contacting DTS about this will only result in a template answer, with a request to file a Feedback report.

It seems that receipt refresh in the sandbox environment has been fixed by Apple since the release of macOS 12.2. It also works on macOS 10.15.

I think this is just a pesky bug. To encourage Apple to fix, it's best to file a Feedback report, especially when you already have a test project that demonstrates the bug.

A super weird workaround for this problem is to add an UIButton (I selected the "Filled Button") to the LaunchScreen.storyboard, and then to add horizontal and vertical alignment constraints to this button. After this I enabled the Hidden property of the button. Since then the launch screen is being resized as expected on my new iPad Pro.

I got his error when I checked the "Undefined Behavior Sanitizer" option in the Target Run Scheme. Disabling the option solved the problem.

This seems to be fixed in the current release versions of iOS and macOS

The original question is not about opening apps in general but about opening the container app. Countless apps use 'openURL' for this, because 'completeRequest' does not open the container app.

This seems to be improved or fixed in macOS 15 beta 4. Hopefully some other SF Symbol 6 bugs will be solved too, so I can fully use and test the new rotation feature.