Running print operation on WKWebView I hit EXC_BREAKPOINT and there is all kinds of console spew that looks concerning: ERROR: The NSPrintOperation view's frame was not initialized properly before knowsPageRange: returned. (WKPrintingView) ** CGContextClipToRect: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.** WebContent[7743] networkd_settings_read_from_file Sandbox is preventing this process from reading networkd settings file at "/Library/Preferences/com.apple.networkd.plist", please add an exception. CRASHSTRING: XPC_ERROR_CONNECTION_INVALID from launchservicesd CRASHSTRING: rdar://problem/28724618 Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd. WebContent[7921] The sandbox in this process does not allow access to RunningBoard. Safe to ignore all this?

Is there any way I can know that another app has gone full screen? Please note that this is not what NSWindowDidEnterFullScreenNotification does, that only works for my own windows. As for why I need to know: Say you're playing a YouTube video full screen. The video fills up the main display, and if there's a second display, it goes black. Well, mostly. I have a utility app with small status windows that remain on top. I'd like to be polite and hide them in this scenario.

I created an application extension that uses IdentityLookup framework for SMS filtering. How can I deploy my product as a library? I tried wrapping it as a framework, but it was not successful.

I have (had) a view controller that does a bit of manual layout in a -viewDidLayout override. This was pretty easy to manage - however since introducing NSGlassEffectView into the view hierarchy I sometimes am getting hit with "Unable to simultaneously satisfy constraints" and Appkit would break a constraint to 'recover.' It appears translatesAutoresizingMaskIntoConstraints is creating some really weird fixed width and height constraints. Here I wasn't doing any autolayout - just add the glass view and set its frame in -viewDidLayout. At runtime since I do manual layout in -viewDidLayout the frames are fixed and there is no real "error" in my app in practice though I wanted to get rid of the constraint breaking warning being logged because I know Autolayout can be aggressive about 'correctness' who knows if they decide to throw and not catch in the future. In my perfect world I would probably just prefer a view.doesManualLayout = YES here - the subviews are big containers no labels so localization is not an issue for me. Rather than playing with autoresizing masks to get better translated constraints I decided to set translatesAutoresizingMaskIntoConstraints to NO and make the constraints myself. Now I get hit with the following exception: "The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window" So this happens because the view which now has constraints -- I adjusted the frame of it one point in -viewDidLayout. My question is - is not legal to make changes in -viewDidLayout - which seems like the AppKit version of -viewDidLayoutSubviews. In UIKit I always thought it was fine to make changes in -viewDidLayoutSubviews to frames - even if constraints were used - this is a place where you could override things in complex layouts that cannot be easily described in constraints. But in AppKit if you touch certain frames in -viewDidLayout it can now cause this exception (also related: https://developer.apple.com/forums/thread/806471) I will change the constant of one of the constraints to account for the 1 point adjustment but my question still stands - is it not legal to touch frames in -viewDidLayout when autolayout constraints are used on that subview? It is (or at least was if I remember correctly) permitted to change the layout in -viewDidLayoutSubviews in UIKit but AppKit seems to be more aggressive in its checking for layout correctness). What about calling -sizeToFit on a control in viewDidLayout or some method that has side effect of invalidating layout in a non obvious way, is doing things like this now 'dangerous?' Shouldn't AppKit just block the layout from being invalidated from within -viewDidLayout - and leave whatever the layout is as is when viewDidLayout returns (thus making -viewDidLayout a useful place to override layout in the rare cases where you need a sledgehammer?)

My app (FindAnyFile) provides a Finder-like interface in which it also offers a QuickLook preview command, which invokes [[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil]; Now, if it shows .abcdp files, it often, but not always, crashes. This has been happening for many macOS versions, at least since 10.15, up to 26.1. Also, it does not seem to matter which SDK/Xcode I build with, as I used several and all versions lead to the crash. The issue rather appears to be inside the QLplugin for the AB file (ABCardCollectionView etc.). I am able to trace this crash in Xcode. There are a LOT of errors and warnings coming up, and eventually the qlplugin throws an ObjC exception which in turn brings down my entire app (and here I thought that the XPC system was designed to expressly avoid such crashes). Possibly significant errors are: CNAccountCollectionUpdateWatcher 0x6000025cf800: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Error using remote object proxy when fetchAnonymousXPCEndpoint: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller" UserInfo={NSDebugDescription=connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller} connection to service named com.apple.coreduetd.people … CNPropertyNotFetchedException: A property was not requested when contact was fetched. I've attached the (mostly) complete console output from such a debug run. I have also an open bug report regarding this kind of crash (back then I was not able to reproduce it myself): FB15553847 Also, when I "Quick Look" the same file in Finder, I get a "Preview not permitted" for the same items that crash in my app. If I copy the same items to the Desktop, then Finder can QL them and my app doesn't crash when viewing the item on the Desktop. So, the crash only happens with the items inside ~/Library/Application Support/AddressBook/Sources/…/Metadata/. Now, here is the weirdest part: You might think: So, if the Finder shows "Preview not permitted", then my app trying to view those items is the result of that condition (even if that's not supposed to crash). However: I have a clean 26.1 install (in an Apple ARM VM) where Finder also says "Preview not permitted" for these items in the user's Library/AB/Metadata folder, but my app can QL those items without crashing! Also, I have one user who uses 26.1 and gets the crash with files in the same location. So, the "Preview not permitted" is probably not the cause of this crash, though it's suspicious that a user gets this at all - why can't a user QL the abcdp files in the Metadata folder but when copied to the Desktop, QL works? You'd think that Finder has the necessary entitlements to access the AB, or doesn't it? Of course, my app has permission enabled under Privacy & Security / Contacts (if it's disabled, then the app can't show anything but will also not crash). And it has the "Address Book" entitlement. Would be nice if this could be looked into and eventually be fixed. Alternatively, I'd welcome any suggestions on how to prevent my app from crashing if the qlplugin throws. But if you look at the stack trace you'll see that there's no method of my own app involved where I could insert an exception catcher. I added code to my previewItemURL delegate method to make sure the NSURL item is readable, and it is, even Of course, apart from the issue with .abcdp files, the QL operation in my app works flawlessly, i.e. I have never received any other crash reports relating to any other QL plugins. QuickLook for AddressBook crash messages

Is anyone else getting new warning about menu items with submenus when running on Tahoe? I'm getting big performance problems using my menu as well as seeing these messages and I'm wondering if there's a connection. My app is faceless with a NSStatusItem with an NSMenu. Specifically it's my own subclass of NSMenu where I have a lot of code to manage the menu's dynamic behavior. This code is directly in the menu subclass instead of in a controller because the app I forked had it this way, a little wacky but I don't see it being a problem. A nib defines the contents of the menu, and it's instantiated manually with code like: var nibObjects: NSArray? = [] guard let nib = NSNib(nibNamed: "AppMenu", bundle: nil) else { ... } guard nib.instantiate(withOwner: owner, topLevelObjects: &nibObjects) else { ... } guard let menu = nibObjects?.compactMap({ $0 as? Self }).first else { ... } Within that nib.instantiate call I see a warning logged that seems new to Tahoe, before the menu's awakeFromNib is called, that says (edited): Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> as a supermenu, but the supermenu does not seem to have any item with that submenu My_StatusItem_App.AppMenu: 0x7f9570c1a440 is my menu belonging to the NSStatusItem, NSMenu: 0x6000034e5340 is the submenu of one of its menu items. At a breakpoint in the NSMenu subclass's awakeFromNib I print self and see clear evidence of the warning's incorrectness. Below is a snippet of the console including the full warning, only edited for clarity and brevity. It shows on line 32 menu item with placeholder title "prototype batch item" that indeed has that submenu. Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> Title: Supermenu: 0x7f9570c1a440 (My StatusItem App), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010e4fa0 Do The Thing Again, ke mask='<none>'>", "<NSMenuItem: 0x6000010e5040 Customize\U2026, ke mask='<none>'>", "<NSMenuItem: 0x6000010e50e0, ke mask='<none>'>" ) believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu (lldb) po self <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010fd7c0 About My StatusItem App\U2026, ke mask='<none>', action: showAbout:, action image: info.circle>", "<NSMenuItem: 0x6000010fd860 Show Onboarding Window\U2026, ke mask='Shift', action: showIntro:>", "<NSMenuItem: 0x6000010fd900 Update Available\U2026, ke mask='<none>', action: installUpdate:, standard image: icloud.and.arrow.down, hidden>", "<NSMenuItem: 0x6000010e46e0, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4780 Start The Thing, ke mask='<none>', action: startTheThing:>", "<NSMenuItem: 0x6000010e4dc0 \U2318-\U232b key detector item, ke mask='<none>', view: <My_StatusItem_App.KeyDetectorView: 0x7f9570c1a010>>", "<NSMenuItem: 0x6000010e4e60, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4f00 saved batches heading item, ke mask='<none>', view: <NSView: 0x7f9570b4be10>, hidden>", "<My_StatusItem_App.BatchMenuItem: 0x6000016e02c0 prototype batch item, ke mask='<none>', action: replaySavedBatch:, submenu: 0x6000034e5340 ()>", "<NSMenuItem: 0x6000010f7d40, ke mask='<none>'>", "<My_StatusItem_App.ClipMenuItem: 0x7f956ef14fd0 prototype copy clip item, ke mask='<none>', action: copyClip:>", "<NSMenuItem: 0x6000010fa620 Settings\U2026, ke='Command-,', action: showSettings:>", "<NSMenuItem: 0x6000010fa6c0, ke mask='<none>'>", "<NSMenuItem: 0x6000010fa760 Quit My StatusItem App, ke='Command-Q', action: quit:>" ) Is this seemingly incorrect inconsistency message harmless? Am I only grasping at straws to think it has some connection to the performance issues with this menu?

I received the following crash: Thread 0 Crashed: libsystem_kernel.dylib __pthread_kill + 8 libsystem_pthread.dylib pthread_kill + 296 (pthread.c:1721) libsystem_c.dylib abort + 124 (abort.c:122) libc++abi.dylib __abort_message + 132 (abort_message.cpp:66) libc++abi.dylib demangling_terminate_handler() + 304 (cxa_default_handlers.cpp:76) libobjc.A.dylib _objc_terminate() + 156 (objc-exception.mm:496) libc++abi.dylib std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59) libc++abi.dylib __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 (cxa_exception.cpp:152) libc++abi.dylib __cxa_throw + 92 (cxa_exception.cpp:299) libobjc.A.dylib objc_exception_throw + 448 (objc-exception.mm:385) Foundation -[NSConcreteMutableAttributedString initWithString:] + 268 (NSAttributedString.m:1049) CloudDocs -[BRCloudPathComponentDisplayMetadata initWithDisplayName:suffix:url:icon:] + 180 (BRCloudPathComponentDisplayMetadata.m:75) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:]_block_invoke + 516 (BRCloudPathComponentDisplayMetadata.m:292) CloudDocs -[NSArray(BRAdditions) br_transform:keepNull:] + 228 (NSArray+BRAdditions.m:20) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:] + 76 (BRCloudPathComponentDisplayMetadata.m:276) AppKit -[NSPathCell _autoUpdateCellContents] + 2080 (NSPathCell.m:442) AppKit -[NSPathCell setURL:] + 76 (NSPathCell.m:599) AppKit -[NSPathControl setURL:] + 64 (NSPathControl.m:366) I tried reproducing on my end by passing various URLs in iCloud Drive to an NSPathControl, file reference urls, attempting to evict a URL from iCloud Drive then settings the URL property without luck. Setting the URL to nil does not crash (the property is nullable). I have no idea how to trigger that code path. Anyone else run into this and have a workaround?

On MacOS Tahoe (26.0 26.1 or 26.2), when loading an application that was built with an SDK older than version SDK 14.5, all CGContextDrawShading calls to draw onto the screen (inside of NSView drawRect:) fail silently, filling the path with a single color instead of a gradient. If rendering into a local CGBitmapContext instead of the NSView context on Tahoe, CGShading works as expected. On MacOS 15 and earlier, CGShading works as expected too. If the app is built with SDK version 14.5 or newer, CGShading works normally on MacOS Tahoe. For recent applications, they can of course be rebuilt with a more recent version of the SDK, which fixes the problem. However for Audio Units or any other type of plug-in, even if they are built with the "appropriate" SDK, if they are loaded inside of a legacy application that was built with an older SDK, the problem arises, which customers complain about and do not understand. I have noticed that there had been a few changes in MacOS Tahoe regarding the CGShading APIs, could this problem be related? If this issue cannot be fixed in an upcoming MacOS update, is there maybe a "defaults" value that can be changed? (since this behaviour is specific to a sdk version, I guess that it is triggered by a version check in the Frameworks and that there is a "defaults" value that can be changed to avoid this specific behaviour, as it is usually the case via a DefaultValueFunction)? I have already opened a feedback regarding this issue, but maybe someone already has a solution for this problem?

I am building a macOS utility using SwiftUI and Swift that records and displays keyboard shortcuts (like Cmd+C, Cmd+V) in the UI. To achieve this, I am using NSEvent.addGlobalMonitorForEvents(matching: [.keyDown]). I am aware that global monitoring usually requires the app to be non-sandboxed. However, I am seeing some behavior I don't quite understand during development: I started with a fresh SwiftUI project and disabled the App Sandbox. I requested Accessibility permissions using AXIsProcessTrustedWithOptions, manually enabled it in System Settings, and the global monitor worked perfectly. I then re-enabled the App Sandbox in "Signing & Capabilities." To my surprise, the app still records global events from other applications, even though the Sandbox is now active. Is this expected behavior? Does macOS "remember" the trust because the Bundle ID was previously authorized while non-sandboxed, or is there a specific reason a Sandboxed app can still use addGlobalMonitor if the user has manually granted Accessibility access? My app's core feature is displaying these shortcuts for the user's own reference (productivity tracking). If the user is the one explicitly granting permission via the Accessibility privacy pane, will Apple still reject the app for using global event monitors within a Sandboxed environment? Code snippet of my monitor: // This is still firing even after re-enabling Sandbox eventMonitor = NSEvent.addGlobalMonitorForEvents(matching: [.keyDown]) { event in print("Captured: \(event.charactersIgnoringModifiers ?? "")") } I've tried cleaning the build folder and restarting the app, removing the app from accessibility permission, but the events keep coming through. I want to make sure I'm not relying on a "development glitch" before I commit to the App Store path. Here is the full code anyone can use to try this :- import SwiftUI import Cocoa import Combine struct ShortcutEvent: Identifiable { let id = UUID() let displayString: String let timestamp: Date } class KeyboardManager: ObservableObject { @Published var isCapturing = false @Published var capturedShortcuts: [ShortcutEvent] = [] private var eventMonitor: Any? // 1. Check & Request Permissions func checkAccessibilityPermissions() -> Bool { let options: NSDictionary = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true] let accessEnabled = AXIsProcessTrustedWithOptions(options) return accessEnabled } // 2. Start Capture func startCapture() { guard checkAccessibilityPermissions() else { print("Permission denied") return } isCapturing = true let mask: NSEvent.EventTypeMask = [.keyDown, .keyUp] eventMonitor = NSEvent.addGlobalMonitorForEvents(matching: mask) { [weak self] event in self?.processEvent(event) } } // 3. Stop Capture func stopCapture() { if let monitor = eventMonitor { NSEvent.removeMonitor(monitor) eventMonitor = nil } isCapturing = false } private func processEvent(_ event: NSEvent) { // Only log keyDown to avoid double-counting the UI display guard event.type == .keyDown else { return } var modifiers: [String] = [] var symbols: [String] = [] // Map symbols for the UI if event.modifierFlags.contains(.command) { modifiers.append("command") symbols.append("⌘") } if event.modifierFlags.contains(.shift) { modifiers.append("shift") symbols.append("⇧") } if event.modifierFlags.contains(.option) { modifiers.append("option") symbols.append("⌥") } if event.modifierFlags.contains(.control) { modifiers.append("control") symbols.append("⌃") } let key = event.charactersIgnoringModifiers?.uppercased() ?? "" // Only display if a modifier is active (to capture "shortcuts" vs regular typing) if !symbols.isEmpty && !key.isEmpty { let shortcutString = "\(symbols.joined(separator: " ")) + \(key)" DispatchQueue.main.async { // Insert at the top so the newest shortcut is visible self.capturedShortcuts.insert(ShortcutEvent(displayString: shortcutString, timestamp: Date()), at: 0) } } } } PS :- I just did another test by creating a fresh new project with the default App Sandbox enabled, and tried and there also it worked!! Can I consider this a go to for MacOs app store than?

This example application crashes when entering any text to the token field with FAULT: NSGenericException: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The app uses controlTextDidChange to update a live preview where it accesses the objectValue of the token field. If one character is entered, it also looks like the NSTokenFieldDelegate methods tokenField(_:styleForRepresentedObject:) tokenField(_:editingStringForRepresentedObject:) tokenField(_:representedObjectForEditing:) are called more than 10000 times until the example app crashes on macOS Tahoe 26 beta 6. I've reported this issue with beta 1 as FB18088608, but haven't heard back so far. I have multiple occurrences of this issue in my app, which is working fine on previous versions of macOS. I haven't found a workaround yet, and I’m getting anxious of this issue persisting into the official release.

NSApplicationDelegate.application(_:open:) gets the files it needs to read from the file URLs given. There are similar older functions that use a String to identify the file. What format are those strings expecting? A path name? An URL?

I would like to provide a default filename when saving a document depending on the document data. I thought I could do so by overriding NSDocument.prepareSavePanel(_:) and setting NSSavePanel.nameFieldStringValue, but simply implementing that method seems to hide the file format popup button shown by default (see image). Calling super doesn't help. Is it possible to set a default filename and keep the file format popup button? On macOS 15, I can toggle NSSavePanel.showsContentTypes, but how about macOS 14 and older?

I have a program that installs an NSStatusItem button in the Menubar. It registers for both the right and left click events. Before Tahoe, clicking into the statusitem with the mouse at the very top of the menubar would also invoke the Action handler, be it a right or a left click. Now, with Tahoe, where the menubar height was changed from 24 to 30, left clicks at the top edge still trigger the Action event, but right clicks do not - they only work if moving the mouse a few pixels down. This is quite inconvenient - the idea of the menubar being at the edge of the screen was always that one can just push the mouse to the edge and then click to interact. Tahoe has broken this basic GUI concept now partially. And since left clicks still work, it suggests that I don't do anything wrong - the clicks are controlled by the framework, and I'm never asked to provide a frame in which the clicks shall be accepted. It's that Apple's code apparently now uses the smaller statusitem's bounds instead of the full menu bar height for hit-testing. Is that on purpose or a bug? And does someone know a work-around, i.e. can I hook into the click-handler at a deeper level and do the hit testing myself? I've tried adding a subview to the statusitem's window's contentView, but that also only reacts to clicks in the smaller area.

So, I was going to make a macOS application that accepts dropped apps. This used to work fine in older macOS versions such as High Sierra. It also works for apps like Script Editor. But I cannot get my own app, made with either Xcode or Script Editor, receive dropped apps any more. Mind you, Finder does accept dropping .app items onto my app, so the CFBundleDocumentTypes are fine. And, as I said, it works in High Sierra. The problem is that some part in AppKit or Core Services filters out apps from the list of dropped URLs before application:openURLs: is invoked. What's up with that, and how do I make this work again? I've tried copying all of Script Editor's Info.plist entries to no avail, so there's something more sinister going on here. Also filed under FB21456137

This method on UIEvent gets you more touch positions, and I think it's useful for a drawing app, to respond with greater precision to the position of the Pencil stylus. Is there a similar thing in macOS, for mouse or tablet events? I found this property mouseCoalescingEnabled, but the docs there don't describe how to get the extra events.

I have the following code (compile as a standalone file): #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate> @property (strong) NSWindow *window; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { // Create main window self.window = [[NSWindow alloc] initWithContentRect:NSMakeRect(100, 100, 800, 600) styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskMiniaturizable) backing:NSBackingStoreBuffered defer:NO]; [self.window setTitle:@"Nested ScrollView Demo"]; [self.window makeKeyAndOrderFront:nil]; // Split view controller NSSplitViewController *splitVC = [[NSSplitViewController alloc] init]; // Sidebar NSViewController *sidebarVC = [[NSViewController alloc] init]; sidebarVC.view = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 200, 600)]; sidebarVC.view.wantsLayer = YES; NSSplitViewItem *sidebarItem = [NSSplitViewItem sidebarWithViewController:sidebarVC]; sidebarItem.minimumThickness = 150; sidebarItem.maximumThickness = 400; [splitVC addSplitViewItem:sidebarItem]; // Content view controller NSViewController *contentVC = [[NSViewController alloc] init]; // Vertical scroll view (outer) NSScrollView *verticalScrollView = [[NSScrollView alloc] initWithFrame:NSMakeRect(0, 0, 600, 600)]; verticalScrollView.automaticallyAdjustsContentInsets = YES; verticalScrollView.hasVerticalScroller = YES; verticalScrollView.hasHorizontalScroller = NO; verticalScrollView.autoresizingMask = NSViewWidthSizable | NSViewHeightSizable; NSView *verticalContent = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 600, 1200)]; verticalContent.wantsLayer = YES; verticalContent.layer.backgroundColor = [[NSColor blueColor] CGColor]; [verticalScrollView setDocumentView:verticalContent]; // Add several horizontal scroll sections CGFloat sectionHeight = 150; for (int i = 0; i < 5; i++) { // Horizontal scroll view inside section NSScrollView *horizontalScroll = [[NSScrollView alloc] initWithFrame:NSMakeRect(0, verticalContent.frame.size.height - (i+1)*sectionHeight - i*20, 600, sectionHeight)]; horizontalScroll.hasHorizontalScroller = YES; horizontalScroll.hasVerticalScroller = NO; horizontalScroll.autoresizingMask = NSViewWidthSizable | NSViewHeightSizable; NSView *horizontalContent = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 1200, sectionHeight)]; horizontalContent.wantsLayer = YES; // Add labels horizontally for (int j = 0; j < 6; j++) { NSTextField *label = [NSTextField labelWithString:[NSString stringWithFormat:@"Item %d-%d", i+1, j+1]]; label.frame = NSMakeRect(20 + j*200, sectionHeight/2 - 15, 180, 30); [horizontalContent addSubview:label]; } horizontalScroll.documentView = horizontalContent; [verticalContent addSubview:horizontalScroll]; } contentVC.view = verticalScrollView; NSSplitViewItem *contentItem = [NSSplitViewItem splitViewItemWithViewController:contentVC]; contentItem.automaticallyAdjustsSafeAreaInsets = YES; contentItem.minimumThickness = 300; [splitVC addSplitViewItem:contentItem]; self.window.contentViewController = splitVC; // Sidebar label NSTextField *label = [NSTextField labelWithString:@"Sidebar"]; label.translatesAutoresizingMaskIntoConstraints = NO; [sidebarVC.view addSubview:label]; [NSLayoutConstraint activateConstraints:@[ [label.centerXAnchor constraintEqualToAnchor:sidebarVC.view.centerXAnchor], [label.centerYAnchor constraintEqualToAnchor:sidebarVC.view.centerYAnchor] ]]; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app run]; } return 0; } Obviously, since the contents of the right part (the content of the sidebar) has its content inset, the horizontal scrolling views cannot extend to the left beneath the sidebar. I can change line 39 to say verticalScrollView.automaticallyAdjustsContentInsets = NO; which will make the inner horizontal scroll views able to extend below the sidebar, but then I'd lose out on the automatic inset management to not have other content overlap beneath the sidebar. So what can I do here? I've tried manually changing the frame of the inner scroll views to start on a negative x, but that does not allow me to scroll all the way to the leftmost content. I'm hoping I won't have to adjust for safe areas manually for the outer scroll view. I'd also appreciate tips on how to fix the fact that veritical scrolling doesn't work when your mouse is in a horizontal scroll view. Thanks! P.S. same thing also exists on UIKit.

Appkit starting logging these warnings in macOS 26.1 about my app's MainMenu. **Internal inconsistency in menus - menu <NSMenu: 0xb91b2ff80> Title: AppName Supermenu: 0xb91a50b40 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: () believes it has [<NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp:] 0xb91a50b40> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu ** I don't what that means. The supermenu is the menu that represents the menu used for my app's menu bar (as described by NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp Everything seems to work fine but log looks scary. Please don't throw!

I have a Mac application that uses the NSEvent.addLocalMonitorForEvents API to receive all mouse movement events. It receives all the mouse movement events and calculate the event reporting rate. The code used as following: import SwiftUI struct ContentView: View { var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundColor(.accentColor) Text("Hello, world!") } .frame(width: 400, height: 400) .padding() .onAppear() { // here NSEvent.addLocalMonitorForEvents(matching: [.mouseMoved]) { event in print(event.timestamp) return event } } } } With the exact same code, before I upgraded my macOS to the latest version 26.2, I could receive approximately 460+ mouse events per second, this matched the hardware reporting frequency of my mouse device perfectly. However, after upgrading to version 26.2, I noticed that the number of mouse events received per second is limited to match the screen refresh rate: when I set the screen refresh rate to 60Hz, I only receive 60 mouse events per second; when set to 120Hz, I receive 120 events per second. It is clear that some changes has be delivered in macOS 26.2, which by default downsamples the frequency of mouse events reported to applications to align with the screen refresh rate. The question is how can I reteive all the original mouse events in macOS 26.2? I tried to search and dig, bug no any related APIs found.

Hello, I am developing a macOS app using AudioToolbox's MusicSequence and MusicPlayer APIs to play Standard MIDI Files. The MIDI playback works correctly and I can hear sound from the external MIDI device. However, the user callback registered via MusicSequenceSetUserCallback is never invoked during playback. Details: Callback registration returns no error. MusicPlayer is properly started and prerolled. The callback is defined as a global function with the correct @convention(c) signature. I have tried commenting out MusicTrackSetDestMIDIEndpoint to avoid known callback suppression issues. The clientData pointer is passed and correctly unwrapped in the callback. Minimal reproducible example shows the same behavior. Environment: macOS version: [Tahoe 26.2] Xcode version: [26.2] Is it expected that MusicSequenceSetUserCallback callbacks may not be called in some cases? Are there additional steps or configurations required to ensure the callback is triggered during MIDI playback? Thank you for any advice or pointers. Execute playTest() in the viewDidLoad() method of the ViewController. extension ViewController { private func playTest() { NewMusicSequence(&sequence) if let midiFileURL = Bundle.main.url(forResource: "etude", withExtension: "mid") { MusicSequenceFileLoad(sequence!, midiFileURL as CFURL, .midiType,MusicSequenceLoadFlags()) NewMusicPlayer(&player) MusicPlayerSetSequence(player!, sequence!) MusicPlayerPreroll(player!) let status = MusicSequenceSetUserCallback(sequence!, musicSequenceUserCallback, Unmanaged.passUnretained(self).toOpaque()) if status == noErr { print("Callback registered successfully") } else { print("Callback registration failed: \(status)") } MusicPlayerStart(player!) } else { print("MIDI File Not Found") } } } The callback function was generated by Xcode and defined outside the ViewController. func musicSequenceUserCallback( clientData: UnsafeMutableRawPointer?, sequence: MusicSequence, track: MusicTrack, eventTime: MusicTimeStamp, eventData: UnsafePointer<MusicEventUserData>, startSliceBeat: MusicTimeStamp, endSliceBeat: MusicTimeStamp ) { print("User callback fired at eventTime: \(eventTime)") if let clientData = clientData { let controller = Unmanaged<ViewController>.fromOpaque(clientData).takeUnretainedValue() // Example usage to prove round-trip works (avoid strong side effects in callback) _ = controller.view // touch to silence unused warning if needed print("Callback has access to ViewController: \(controller)") } else { print("clientData was nil") } }

I am creating a macOs SwiftUI document based app, and I am struggling with the Window sizes and placements. Right now by default, a normal window has the minimize and full screen options which makes the whole window into full screen mode. However, I don't want to do this for my app. I want to only allow to fill the available width and height, i.e. exclude the status bar and doc when the user press the fill window mode, and also restrict to resize the window beyond a certain point ( which ideally to me is 1200 x 700 because I am developing on macbook air 13.3-inch in which it looks ideal, but resizing it below that makes the entire content inside messed up ). I want something like this below instead of the default full screen green When the user presses the button, it should position centered with perfect aspect ratio from my content ( or the one I want like 1200 x 700 ) and can be able to click again to fill the available width and height excluding the status bar and docs. Here is my entire @main code :- @main struct PhiaApp: App { @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate var body: some Scene { DocumentGroup(newDocument: PhiaProjectDocument()) { file in ContentView( document: file.$document, rootURL: file.fileURL ) .configureEditorWindow(disableCapture: true) .background(AppColors.background) .preferredColorScheme(.dark) } .windowStyle(.hiddenTitleBar) .windowToolbarStyle(.unified) .defaultLaunchBehavior(.suppressed) Settings { SettingsView() } } } struct WindowAccessor: NSViewRepresentable { var callback: (NSWindow?) -> Void func makeNSView(context: Context) -> NSView { let view = NSView() DispatchQueue.main.async { [weak view] in callback(view?.window) } return view } func updateNSView(_ nsView: NSView, context: Context) { } } extension View { func configureEditorWindow(disableCapture: Bool = true) -> some View { self.background( WindowAccessor { window in guard let window else { return } if let screen = window.screen ?? NSScreen.main { let visible = screen.visibleFrame window.setFrame(visible, display: true) window.minSize = visible.size } window.isMovable = true window.isMovableByWindowBackground = false window.sharingType = disableCapture ? .captureBlocked : .captureAllowed } ) } } This is a basic setup I did for now, this automatically fills the available width and height on launch, but user can resize and can go beyond my desired min width and height which makes the entire content inside messy. As I said, I want a native way of doing this, respect the content aspect ratio, don't allow to enter full screen mode, only be able to fill the available width and height excluding the status bar and doc, also don't allow to resize below my desired width and height.