Using the screencapture CLI on macOS Sonoma 14.0 (23A344) results in a 72dpi image file, no matter if it was captured on a retina display or not. For example, using screencapture -i ~/Desktop/test.png in Terminal lets me create a selective screenshot, but the resulting file does not contain any DPI metadata (checked using mdls ~/Desktop/test.png), nor does the image itself have the correct DPI information (should be 144, but it's always 72; checked using Preview.app). I noticed a (new?) flag option, -r, for which the documentation states: -r Do not add screen dpi meta data to captured file. Is that flag somehow automatically set? Setting it myself makes no difference and obviously results in a no-dpi-in-metadata and wrong-dpi-in-image file. The only two ways I got the correct DPI information in a resulting image file was using the default options (forced by -p): screencapture -i -p, and by making the capture go to the clipboard screencapture -i -c. Sadly, I can't use those in my case. Feedback filed: FB13208235 I'd appreciate any pointers, Matthias

I have a stand-alone watchOS app that starts a WKExtendedRuntimeSession and a 1-second repeating timer when a button is pressed. No CPU-intensive stuff happens during this extended (background) time. On watchOS 9, this worked perfectly until I stopped it again (or after the hour I get out of a Mindfulness Session Type has passed, and the extended runtime session expires). The screen could go dark, and the timer would keep running. On watchOS 10, I get about 50 seconds when the screen goes dark, and then the timer just stops. No delegate methods are called (i.e. no "extendedRuntimeSession...willExpire()" or "...didInvalidateWith()" is called), though. Also, the scenePhase does not change at this point, it remains at inactive. The execution just stops. When I tap the watch to turn the screen back on, the timer resumes as if nothing happened. Does anybody know what's going on here? Has something changed in WKExtendedRuntimeSessions in watchOS 10, or is it a bug? I tried removing the timer and changing it to a recursive DispatchAsync.main.asyncAfter block, but it yielded the same result.

Hi, when I try to push to my git repository using Xcode 12 beta, I get the following error: An unknown error occurred username does not match previous requests (-1) It works correctly using Xcode 11, using the same copy / files on disk. Is this a known issue? Thank you, Matthias

Hi, I reported this issue a while back for Xcode 12, which I then marked as resolved because it intermittently worked: https://developer.apple.com/forums/thread/652855 However, since Xcode 13, even in Xcode 14 RC 2, Git pushing to a custom server just does not work for me at all anymore. I get the following error: An unknown error occurred username does not match previous requests (-1) Feedback ID: FB9812942 Thank you, Matthias

Hello, I want to archive a folder containing files into a single file using Apple Archive. So far so good, it works as it should. Now, the documentation says: The zlib compression algorithm, which is recommended for cross-platform compression. The encoded format is the raw DEFLATE format as described in IETF RFC 1951, the following obtains the equivalent configuration of the encoder: deflateInit2(zstream,5,Z_DEFLATED,-15,8,Z_DEFAULT_STRATEGY) Thus, I'm using .zlib, because I want the archive to be unarchivable on macOS as well as other, non-Apple platforms. The thing is, I don't know what file extension to use so it is unarchivable / openable on both macOS and, say, Windows. Using .aar ("Apple Archive"), or .aea ("Apple Encrypted Archive"), it works on macOS, but I doubt those can be opened on Windows (since it's the Apple-proprietary file format). Using .zip doesn't work on macOS, so I doubt it'll work on Windows. Using .zlib doesn't work (can't be opened on macOS) Usng .z doesn't work (can't be opened on macOS) So my question is, with a folder compressed using .zlib for cross-platform, what file extension must I use for the resulting archived file so it can be opened with an unarchiving app on macOS and non-Apple platforms? Thank you for any insights, Matthias

Hi all, so, in my app Transloader, when the app is terminated, I sync the Mac's "turned off" status to iCloud. This works on Intel Macs and on Apple silicon Macs when the user manually quits the app. However, on Apple silicon Macs, when the user shuts down or restarts the Mac and the app is terminated that way, the app is terminated right away (doesn't even receive the -applicationWillTerminate: call), so I'm unable to properly sync the status. This still works on Intel Macs, as far as I know. So, is there any new API to extend the Mac's shutdown a little longer to finish my sync? Currently, I use -applicationShouldTerminate:, returning NSTerminateLater, and after syncing, calling -replyToApplicationShouldTerminate:YES . Again, this works fine on Intel Macs if the user manually quits, as well as if the Intel Mac shuts down, but on Apple silicon, it only works if the user manually quits - a shutdown results in the app being terminated without even receiving a -applicationWillTerminate: call. Both NSSupportsSuddenTermination and NSSupportsAutomaticTermination are disabled in the app's Info.plist. Thank you for any insights, Matt

Hello, everyone.My name is Matt, I'm the developer of Eternal Storms Software.I recently released a freeware app: SiriMote, outside of the Mac App Store.The reason I could not release it on the Mac App Store is that it uses CGEventPost to simulate keypresses (for example, when the play/pause button is pressed on the Siri Remote, the Play/Pause media key (on the F8 key) of the Mac's keyboard is pressed), and CGEventPost is ignored inside the sandbox.So I was wondering - is there a way to do this inside the sandbox?I guess an alternative would be using the Scripting Bridge, but then I would have to specifically communicate with particular apps. The nice thing about CGEventPost is that any app that responds to the media keys can be used with SiriMote.I'd love a more open approach, like CGEventPost.Any hints appreciated!Thank you kindly,Matt