This answer may be helpful: https://forums.developer.apple.com/forums/thread/763246

The release version of SF Symbols 6 is now available, but it is still not possible to export rotatable symbols. The export file misses the 'Can Rotate' property and the anchor point. For me it is totally unclear why the app contains fancy controls to set the anchor point, mark layers as rotatable, but without the possibility to export this.

This problem seems to be solved in macOS 15.1 beta

I managed to add a resizeable NSTextField to NSToolbar with the following code: let item = NSToolbarItem(itemIdentifier: .titleItem) /* Or any other identifier */ let field = NSTextField() /* Do not use one of the new initialisers! */ field.isBordered = false /* This is essential */ field.lineBreakMode = .byTruncatingTail item.view = field

You can create max 1000 custom record zones in a private CloudKit database. This limit is active since 2016, before that you could create an unlimited number of record zones. The number of records within a record zone is unlimited.

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.

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 fixed in the current release versions of iOS and macOS

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

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 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.

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 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.

Mac apps installed by TestFlight do also have a receipt.

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.