still the case on macOS 14.4b5(23E5211a)

I've submitted it to TestFlight and App Review, and as expected, it's taking a very long time in "In Review" (and very likely leading to a rejection). I hope this'll get fixed before 14.4 is released.

hm, it works when I add group.com.apple.screencapture to the XPC's App Groups, but I very much doubt it'll make it through App Review.

doesn't work when run from Shortcuts.app, either, as a "run script"

still the case in macOS 14.4b4 23E5205c

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

macOS 14.2 apparently has brought no fix for this.

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.

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

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

Issue still exists in macOS Sonoma 14.1 (23B74)

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

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.

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

have you ever found a solution to this?