any update on this? It works the first time for me, the second time I enter PiP with an AVSampleBufferDisplayLayer, it fails. (iOS 15, b8)

Update: It's a macOS Monterey issue, not an Apple silicon / Intel issue. Also, I found out it has to do with having set NSApp activationPolicy to .accessory or .prohibited - if those are set, the app is terminated prematurely on shutdown / restart (-applicationWillTerminate: is never called). If it's .regular, it works like it should.

same here, any insight into what's going on?

also interested in this.

after a lengthy conversation with an Apple Engineer, this is desired behavior on macOS Monterey and newer, so that .accessory and .prohibited apps are more or less killed outright when restarting, logging out of or shutting down the Mac, in order to reduce shutdown times. Too bad, imho.

have you ever found a solution to this?

Thank you, eskimo. As always, you've brought clarity into this situation. I just want to turn a folder of files into a single "binary data" file, so that I can upload it to iCloud and create a shareable link for it, and have it be openable on all sorts of operating systems, so I'll give [2] a shot, perhaps it's enough. I understand now that using the Apple Archive framework to create an archive of a folder (compressed or not) will only produce "Apple (Encrypted) Archive" files, openable only on Apple platforms. If I need something else, I'd have to go a level deeper and use a (zip) compression based on the Compression framework. I see now that the documentation for AppleArchive.Algorithm.zlib is more or less just a reflection of the Compression framework's equivalent, "COMPRESSION_ZLIB", and does not actually mean that using it will render the file created by the Apple Archive framework openable on other operating systems. That may be true for the Compression framework, but not the Apple Archive framework. There is a great Swift zip library out there (ZIPFoundation), actually based on the Compression framework, in case anyone needs it: https://github.com/weichsel/ZIPFoundation (I might default to it as well for this, but I like to use as little external libraries as possible in my code, so I'll try eskimo's [2] first). Thank you for clarifying, Matthias

well, I found out what's wrong. It was my doing after all. CPU usage was way too high for some reason or another, and of course watchOS would terminate my app because of that. Deservedly so. So if you're from the future and reading this, this was the reason why WKExtendedRuntimeSession "didn't work" in my case.

For video recordings (screencapture -v -R 0,0,400,400 ~/Desktop/test.mov), the pixelDensity metadata tag appears to be correctly written to the file, though on the other hand, -r (see explanation above) doesn't seem to have an effect here, either (the pixelDensity metadata is still written to the movie file nonetheless).

Issue still exists in macOS Sonoma 14.1 (23B74)

bump, I've run into something similar with my app Transloader.

My situation in Transloader is like this: I save CKRecords in the private database (not zoned), with CKQuerySubscriptions for silent notifications. They work perfectly fine on all iOS devices, but the Mac either doesn't receive them, or very late (> 10 mins after the fact). Again, it's the same sync code running on Mac and iOS, but the Mac just doesn't get the notifications most of the time. I had to resort to polling the cloud as a temporary measure - that can't be what Apple intends here, since one of the reasons push notifications exist is to avoid polling. I did open a DTS but have not heard back yet. Will update if/when I do. – Matt

The DTS technician told me this has always been the case. Which it hasn't. And filing a bug report just ends up in a black box where no one ever knows if they even received it. Back to the stone age, where polling is king, and silent push notifications for content updates haven't been invented yet to prevent unnecessary loading and energy consumption.

macOS 14.2 apparently has brought no fix for this.

Issue still exists under macOS Sonoma 14.4b23E5196e (Feedback ID: FB13208235)