When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?

I'm using an XPCSession to send a message to a service/agent. When calling session.cancel(reason: "stop") the connection is not immediately canceled. The session seems to wait for any pending replies from the service. According to the docs for XPCSession.cancel: When you cancel a session, it discards any unsent messages and invalidates its connection. If there are messages awaiting replies, the session calls the reply handlers with an appropriate XPCRichError. This does seem to imply that messages waiting for replies are immediately canceled, however that's not the case. The service may be busy and may take a while to respond, or it may not reply at all. The session is only canceled after all enqueued messages get a reply from the service. let session = try XPCSession(xpcService: "com.example.listener", cancellationHandler: { print("client session canceled") }) try session.send("Test", replyHandler: { reply in print("reply", reply) }) print("cancel") session.cancel(reason: "cancel") // calls cancellationHandler *after* receiving reply Is that expected behaviour? If the service does not respond at all the XPCService will never be canceled. Compared to xpc_connection_create + xpc_connection_cancel(connection) this does seem to immediately cancel the connection and call the reply_handler and event_handler. This does not wait for pending replies from the service. Is there an alternative way to force cancel an XPCSession? Main goal is to protect against two potential issues: The service is busy and doesn't respond in time. The client fires a timeout and wants to disconnect/reconnect, but the cancellationHandler is not called until service responds. So the timeout is not useful, client needs to wait for a reply anyway. The service does not respond at all. This could for example happen if a Launch Agent is improperly configured. The mach service is registered, but the agent may not launch. Sending a message on the XPCSession will never receive a reply.

CTFontManagerCreateFontRequestRunLoopSource does not receive any font requests on macOS 27, since beta 5. This API worked fine until macOS 27 beta 4, including previous macOS releases. It looks like this is caused by the App Sandbox. When the com.apple.security.app-sandbox entitlement is disabled the font request source does receive events. Report including sample project: FB24764122 let source = CTFontManagerCreateFontRequestRunLoopSource(0, { (dict, pid) in /* does not receive events when sandboxed */ } CFRunLoopAddSource(CFRunLoopGetCurrent(), source, .defaultMode) Is this a deliberate change or is this a bug in macOS 27? Is there an entitlement that can be set to enable the API in sandboxed apps? My application is distributed on the Mac App Store and as standalone app. Both are properly sandboxed for added security. Disabling the App Sandbox for this specific API would be very undesirable as users will lose all Sandbox benefits.

I’m looking for some advice regarding the usage of temporary exception entitlements in Mac App Store apps. Specifically the Apple Event Temporary Exception to communicate with other third party applications (not first-party macOS system apps): The Best Practices for Submitting Scriptable and AppleScript Apps to the Mac App Store section is a bit vague (how to 'request' a temporary entitlement?) and I couldn't find it mentioned in the Review Guidelines. Before designing, implementing and testing functionality based on the Apple Event Temporary Exception I’d like to know if these entitlements would: A. Always be rejected on the Mac App Store B. Only accepted in highly specific use cases C. Accepted if there is a clear use case and sufficient argumentation For this particular use case I’d like to send Apple Events to Adobe Illustrator and QuarkXPress. The application helps the user with some design tasks in their documents. The app requests the currently open documents and accesses document content to process used design elements. This is optional functionality that the user must explicitly enable in the app. I’m aware that the com.apple.security.scripting-targets entitlement is preferred. (Side question: are these always allowed or can they also be rejected for third party app scripting?) However, many third party applications don’t offer any scripting access groups in their definition, including Adobe Illustrator and QuarkXPress in this case. So before spending a lot of time implementing this feature I’d like to have some indication whether it is unlikely that sending Apple Events to third party apps will be allowed on the Mac App Store. Thanks for any insights!

Security scoped bookmarks that were created before updating to macOS 14.7.5 cannot be resolved anymore after updating to macOS 14.7.5. Reproduction: Sandboxed app on macOS version 14.7.4 Create and store a security scoped bookmark to a user selected folder: let url: URL = <user selected url from NSOpenPanel> let data = try url.bookmarkData(options: [.withSecurityScope], includingResourceValuesForKeys: nil, relativeTo: nil) <persistently store data> Update to macOS 14.7.5 Resolve the previously stored bookmark: let data: Data = <restore data from persistent storage> var stale: Bool = true let url = try URL(resolvingBookmarkData: data, options: [.withSecurityScope], relativeTo: nil, bookmarkDataIsStale: &stale) Expected: The bookmark is resolved correctly and the resulting url can be used to access the folder/file in the sandboxed app after starting access. Observed: URL(resolvingBookmarkData:) throws an error: Error Domain=NSCocoaErrorDomain Code=259 "The file couldn’t be opened because it isn’t in the correct format." New security scoped bookmarks created on macOS 14.5.7 can be resolved without issue. The same appears to happen with macOS 13.7.5. Entitlements: com.apple.security.app-sandbox com.apple.security.files.bookmarks.app-scope com.apple.security.files.user-selected.read-write This is very disruptive, as it appears that Sandboxed apps cannot access any previously stored bookmarks anymore. Particularly after the recent ScopedBookmarkAgent issues in 14.7.1 and 15.0, which were resolved in 14.7.3/15.1 respectively: https://developer.apple.com/forums/thread/764435

I've received some reports from users of my macOS app that the application quits when putting their Mac to sleep after hiding all windows. The NSApplicationDelegate implements applicationShouldTerminateAfterLastWindowClosed and returns true. However this method is called even though there are still windows open. Unfortunately I'm not able to reproduce the issue, but here are the steps to reproduce according to the user: Open app (single NSWindow visible) Press Command-H to hide the single window Put Mac to sleep The app is terminated when the Mac wakes. These steps have been confirmed by a user in Safe Mode, so I expect no interference of other applications (macOS 15.1.1). When this happens the application logs show that applicationShouldTerminateAfterLastWindowClosed is called when the Mac goes to sleep. But the main NSWindow is still open (yet hidden). The close() method on NSWindow is not called before applicationShouldTerminateAfterLastWindowClosed. Order of events: NSApplicationDelegate.applicationWillHide NSApplicationDelegate.applicationWillResignActive [...] NSApplicationDelegate.applicationShouldTerminateAfterLastWindowClosed NSApplicationDelegate.applicationShouldTerminate NSApplicationDelegate.applicationWillTerminate NSWindow.close I assumed that applicationShouldTerminateAfterLastWindowClosed is only called after all windows are closed. Is that assumption incorrect? Does a user-hidden NSWindow count as a closed window? For me (and other users) the API works as expected and the app stays running when the app is hidden as the Mac sleeps. applicationShouldTerminateAfterLastWindowClosed is not called until all windows are actually closed.

I’ve been trying to update the pricing tier of one of my IAPs, but when checking the Mac App Store pages and StoreKit API (production, not Sandbox) it is still the old pricing tier after 7 days. I changed the pricing tier on May 16th, then again on May 18th because I didn't see any changes. Still no changes visible as of May 23th. Should I confirm pricing changes anywhere else in App Store Connect, or should just clicking 'Save' on the IAP page be sufficient? I assume pricing changes should be updated relatively quickly (some delay due to caching is expected), so waiting 7 days is a bit much. FB10022965 (Edit: looks like the automatic FB link here is incorrect and doesn't support 8 digits...)