In one of my apps, I use NSTableViewDiffableDataSource in tandem with NSFetchedResultsController, which provides the necessary snapshots. This works great in macOS 14.5. However in latest macOS 15 betas, NSTableViewDiffableDataSource does not call the 'cellProvider' completion handler anymore when the data of a visible cell changes. When data of a visible cell changes, the didChangeContentWith method of NSFetchedResultsController is called correctly, but applying the provided snapshot doesn’t result in calling the said 'cellProvider' completion handler. This looks a rollback to the early state of this API in 2020. It concerns this piece of code: dataSource = NSTableViewDiffableDataSource(tableView: tableView, cellProvider: { (tableView, tableColumn, row, item) -> NSView in // Return a cell view with data }) Does anyone know a solution or workaround to get animated updates of visible cells working in macOS 15 beta? Yes, applying the snapshot without animation works, but that’s not where NSTableViewDiffableDataSource is designed for. In case an Apple engineer reads this: Looking at the sample code associated with FB13931189, is there anything wrongly implemented that prevents calling the 'cellProvider' method for visible cells? Is this perhaps actually a bug of NSFetchedResultsController? I’m asking this because NSCollectionViewDiffableDataSource does have a very similar problem (FB13943853). PS Yes, this post looks very similar to https://developer.apple.com/forums/thread/759381#759381021, because the problem is identical except that concerns NSCollectionViewDiffableDataSource.

In one of my apps, I use NSCollectionViewDiffableDataSource in tandem with NSFetchedResultsController, which provides the necessary snapshots. This works great in macOS 14.5. However, when updating data in Core Data related to a visible item in a NSCollectionView, the NSCollectionViewDiffableDataSource no longer calls the ‘itemProvider’ closure of the diffable data source when using macOS 15 Seed 3, after applying a snapshot with animation. As a result of this, the collection view does not update visible items when the related data changes. I’m talking about this piece of code which is no longer called when it concerns a visible item: dataSource = NSCollectionViewDiffableDataSource<String, NSManagedObjectID>(collectionView: collectionView, itemProvider: { // Return an NSCollectionViewItem here }) Does anyone know a workaround or solution to get updating of visible cells working in macOS 15 Seed 3, without losing animated updates? In case an Apple engineer is reading this: Are there any related API changes that must be taken into account? Is this perhaps actually a bug of NSFetchedResultsController? I’m asking this because NSTableViewDiffableDataSource does have a very similar problem in macOS 15 beta. See also FB13943853

Hello, I am trying to use the following code to disable the Hide option for my application : NSApplicationPresentationOptions options = [NSApp presentationOptions]; options |= NSApplicationPresentationDisableHideApplication; [NSApp setPresentationOptions:options]; , but it doesn't have any effect : the Hide option is still clickable : How could I remove this option? Thanks for any help in advance!

I'm getting a runtime assertion failure like this: "<FFRender3DView 0x616000271580> has reached dealloc but still has a super view. Super views strongly reference their children, so this is being over-released, or has been over-released in the past." Looking at the code, I can't see any strong reference to the view except by its superview, so I can't see how it could be released other than by removal from its superview. My first instinct was to override release and set a breakpoint there, but that's not possible in ARC code.

As the topic mentioned, I want to add a overlay window onto Apps that are in full screen mode, trying to create some blur effect on the screen. But Apple seems to treat full screen mode Apps differently as a "space." So currently I can only apply the blur effect like this. (This is my Desktop page) But When it doesn't affect the full screen mode Apps. (For example: My Xcode) And I know some of the App down this kind of stuff. Like this This is my current code. Hope someone can tell me how to solve it.

We are developing a lightweight VPN client inside a daemon process that will run even when no user session is active on machine. The lightweight VPN runs in machine context and does not require user session. We would like to display some basic diagnosis information about our lightweight client on macOS login window before user is logged into their machine (in case users need that). So, is it possible to display a UI window on login screen with some basic info that user can interact with. If yes, where can I get started? Please note, this is not an authorization plugin. We are just wanting to display info about our process that runs a lightweight VPN client on macOS login screen.

I am trying to wrap my head around proper lifecycles of NSWindows and how to handle them properly. I have the default macOS app template with a ViewController inside a window that is inside a Window Controller. I also create a simple programatic window in applicationDidFinishLaunching like this: let dummyWindow = CustomWindow(contentRect: .init(origin: .zero, size: .init(width: 200, height: 100)), styleMask: [.titled, .closable, .resizable], backing: .buffered, defer: true) dummyWindow.title = "Code window" dummyWindow.makeKeyAndOrderFront(nil) The CustomWindow class is just: class CustomWindow: NSWindow { deinit { print("Deinitializing window...") } } When I close the programatic window (either by calling .close() or by just tapping the red close button, the app crashes with EXC_BAD_ACCESS. Even though I am not accessing the window in any way. One might think it's because of ARC but it's not. One—the window is still strongly referenced by NSApplication.shared.windows even when the local scope of applicationDidFinishLaunching ends. And two—the "Deinitializing window..." is only printed after the window is closed. Closing the Interface Builder window works without any crashes. I dug deep and played with the isReleasedWhenClosed property. It made no difference whether it was false or true for the IB window. It stopped the crashing for the programmatic window though. But this raises three questions: What is accessing the programatic window after it's closed—causing a crash because the default behaviour of NSWindow is to release it—if it's not my code? What is the difference under the hood between a normal window and a window inside a window controller that prevents these crashes? If the recommended approach for programmatic windows is to always set isReleasedWhenClosed = true then how do you actually release a programatic window so that it does not linger in memory indefinetely? If the EXC_BAD_ACCESS means that an object is double de-allocated then that would mean that .close() both releases the window (first release) and removes it from the window list which would mean last strong reference is released and ARC cleans the window out (second release). The theory is supported by me calling .orderOut() instead of close which only removes it from the application list and that does indeed release it without crash. Does this mean programmatic windows should override the close() instance method to call orderOut() instead? This seems like poor API design or I am understanding it wrong?

Hello! In our codebase we have a NSView subclass that conforms to NSTextInputClient. This protocol is currently not marked as a main actor, but in the decade this has been in use here it has always been called on the main thread from AppKit. With Swift 6 (or complete concurrency checking in Swift 5) this conformance causes issues since NSView is a main actor but not this protocol. I've tried a few of the usual fixes (MainActor.assumeIsolated or prefixing the protocol conformance with @preconcurrency) but they were not able to resolve all warnings. So I dug in the AppKit headers and found that NSTextInputClient is usually implemented by the view itself, but that that is not a hard requirement (see NSTextInputContext.h the documentation for the client property or here). With that I turned my NSView subclass extension into a separate class that is not a main actor and in my NSView subclass create an instance of it and NSTextInputContext. This all seems to work fine in my initial tests, the delegate methods are called. But when the window loses and then regains key, I see a warning message in the console output. -[TUINSCursorUIController activate:]: Foo.TextInputClient isn't subclass of NSView. So my question is, am I doing it wrong with the custom class that implements the protocol? Or is the warning wrong? I would also appreciate a hint on how to better resolve the concurrency issues with NSTextInputClient. Is a main actor annotation coming at some point from your end? Thanks! Markus

Is there a way to opt certain windows out of tiling in macOS 15? I'm supporting a beloved feature called App Veil[1], which places windows below others that are not owned by the host application. These windows are passive: they don't allow mouse events and cannot be resized or moved. With the new tiling feature on macOS 15, the window manager will rearrange these windows if you choose an arrangement option (such as Arrange Left & Right). Ideally, I'd like to opt out of this behavior altogether for these windows, but I couldn't find a way to do that. The only thing I've found was that I could set a high window level, but that's not really an option as it's important to preserve the ordering so that the windows are directly below the out-of-process windows. 1: https://tuple.app/app-veil

Hi All, this question has been asked before by others, without any success so far. I'm using the following (standard) method to open the system provided settings screen for my macOS (only) app in SwiftUI. var body: some Scene { Settings { PreferencesView() } if #available(macOS 13, *) { // MenuBarExtra requires macOS 13, but SettingsLink used in here requires macOS 14 MenuBarExtra("...", image: "...") { ... // this one requires macOS 14 if #available(macOS 14, *) { SettingsLink() { Text("Settings...") } } else { Button { NSApp.sendAction(Selector(("showSettingsWindow:")), to: nil, from: nil) } label: { Image(systemName: "gear") } } } } } I want to know when the settings window closes. onDisappear does not work as the settings window is not really closed, but hidden. So the view stays active. All other hacks I have found neither work. Does anyone have any idea?

I just noticed that when closing a new document with edits in MacOS Sonoma that it skips the Save/Don't Save/Cancel panel and goes directly to default NSSavePanel with Delete/Cancel/Save buttons. The problem is that when I click "Delete" nothing happens. It should have simple solution, but I could not find anything. How does one respond to the "Delete" button? My undocumented (as far as I can tell) hack was to implement document:didSave:contextinfo selector for runModalSavePanelForSaveOperation. It appears that in this method for a new document: Delete button has didSave=YES (even though it did not save) and the document fileURL nil Cancel button has didSave=NO and document fileURL nil Save button has didSave=YES and document filieURL to saved file I can handle Delete button this way, but since it is not a documented method, it make me uncomfortable. For example what happens is user clicks "Save", but the save has an error? As an aside, since Apple is now working with ChatGPT, I thought it might provide some help. I asked it how I can respond to "Delete" button in MacOS Sonoma and it said to implement deleteDocument: in your NSDocument subclass. I pointed out to ChatGPT that deleteDocument: does not exist. It said "you are correct" and you should instead check the returned result from runModalSavePanelForSaveOperation and look for "stop" action. I pointed out to ChatGPT that runModalSavePanelForSaveOperation is void and does not return a result, it said again, "you are correct." It gave a third option which basically said to override runModalSavePanelForSaveOperation and build your own save panel from scratch. I didn't know if I should trust this answer. I reverted to my hack and wrote this post. Also ChatGPT never apologized for wasting my time with the wrong answers.

Hello guys, Is there any API developers can use to get advantage of the new windows resize and placement feature for macOS Sequoia? And of course I'm not talking about resizing the windows from your own app, but the windows from other apps. Thank you.

I'm seeing many apps, when restoring their state from a previous launch, have trouble opening windows to the space and minimized state they were last. What do I need to do so my AppKit app doesn't have this problem?

I have the following code: + (BOOL)activateWindow:(NSWindow*)window { if (NSApp.activationPolicy != NSApplicationActivationPolicyRegular) [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; if (window) { [NSApp activate]; //if (window.isMiniaturized) [window deminiaturize:nil]; [window makeKeyAndOrderFront:nil]; } return YES; } + (BOOL)hideWindowFromDock:(NSWindow*)window { if (NSApp.activationPolicy != NSApplicationActivationPolicyProhibited) [NSApp setActivationPolicy:NSApplicationActivationPolicyProhibited]; window.isVisible = NO; return YES; } I hide app main window by setting NSApplicationActivationPolicyProhibited if it is minimized or being closed. The code worked most of the time. But since upgrading to Sonoma, sometimes it won't correctly activate main window. The window icon reappears in the dock, but the window won't show up. I have to click on the window icon again to let it 'order front'. Sometimes, I observe a very weird behavior of the window being activated. It 'order front' and then disappears and re-appears.

When the user makes changes in my document, I call document.updateChangeCount(.changeDone) which seems to successfully mark the document as changed - the close button has a dot, the proxy icon is disabled, and when closing/quitting I get the save prompt. The problem is that the File > Save command is never enabled, so saving/quitting is the only way I can get it to save. I'm not overriding any menu validation methods in my NSDocument subclass. I do have a validateMenuItem() in my main view controller, but it's only for a popup menu, and setting a breakpoint there confirms that it only gets called for the popup. What else could be preventing Save from getting enabled? Edit: I tried overriding validateUserInterfaceItem() to return true when appropriate, which works, although the Save command then appears as "Save..." so apparently I'm also responsible for updating the title. In any case this seems like it shouldn't be necessary. I wonder if it's because I implement saving in save(to:ofType:for:completionHandler:) rather than one of the other possibilities. I was going to try wirte(to:ofType) instead but that is surprisingly nonisolated, so I'm not sure how I'm expected to safely access my data model from there. I can't do data(ofType:) because saving may involve writing to multiple files.

I am unfortunately faced with a large legacy code base in which Storyboards are heavily used. Now, for some reason, the entire app window is resized if a certain View Controller becomes visible. The issue: Apparently, there aren't any conflicting layout constraints (no LAYOUT_CONSTRAINTS_NOT_SATISFIABLE errors are raised on display of the view controller). There are also no calls to setFrame on the corresponding window. So, how do I debug this? Capturing the view hierarchy didn't provide any helpful insights, and ideally I could just force the window to not resize (due to possible constraint errors). Is there any way to achieve something like this? If not, how can I go about debugging this? Any help on this would be greatly appreciated.

In our Mac Catalyst app running on macOS, the Edit > Spelling and Grammar > Check Spelling While Typing, Check Grammar With Spelling, and Correct Spelling Automatically preferences are reset with each opening of a new text view. How can we make those preferences persistent? Ie, when someone changes those settings for our app's text view, other incarnations of our app's text views should respect the latest preferences. We looked at swizzling NSTextView's toggleAutomaticSpellingCorrection:, saving those to NSUserDefaults, and then reading those preferences when we set up our UITextView subclass, and then setting the UITextInputTraits properties accordingly. However, our approach felt heavy handed, and I'm wondering if we are missing some out-of-the-box functionality that will make those preferences intuitively persistent. Does anyone have any suggestions? Thank you.

My Xcode workspace contains build settings for a macOS, iOS, and tvOS application. My Sandbox macOS app builds just fine and works great - and is on the App Store. I am in the process of creating a new build / branch of this app that is not Sandboxed so that I can add IPC (Syphon support) - as I don't think I can use App Groups to enable CFMessage support (which Syphon requires) because Syphon (third party framework) - uses its own naming convention for the ports. Anyway, sandbox support for a Syphon app is a topic for another day (it's actually quite disappointing that I can't release a Syphon version on the App Store). The trouble I am having, is that even afer deleting the App Sandbox entitlement from my project, my App still seems to be running in the App Sandbox, and I can't figure out how to remove the App Sandbox entitlement completely. What I am seeing, is that even after deleting the App Sandbox entitlement (using the project settings and deleting it in the "Signing and Capabilities" tab (and also checking the entitlements file manually to doubly make sure it is gone) - I am still seeing the following error message: *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x8703, name = 'info.v002.Syphon.332143F7-0916-428A-A88A-59B752F95304' See /usr/include/servers/bootstrap_defs.h for the error codes. It is also saving my Application Support data in the ~/Library/Containers folder, and not in ~/Library/ApplicationSupport What step am I missing?

By Implementing the TipKit framework in the AppKit Mac OS application, we were unable to close the popover when we clicked on the cross icon presented in TipNSPopover view. And any clues about how to implement the TipNSPopover on Handover of NScollectionview ?. When the mouse enters any of the collection view cells, I have to present the TipNSpopover view. Please share your input and thoughts.

I'd like to know how to test behavior in Swift on Desktop that needs to interact with external elements, in my case the Finder. My goal is simple: add an option in the right-click menu of the Finder that will open my application with the selected entry or entries (file or folder) from the Finder. I have thus set the elements NSMenuItem, NSMessage, NSPortName, NSRequiredContext (NSApplicationIdentifier: com.apple.finder) etc. I also created a class FinderService with a function performService having this declaration: func performService(_ pboard: NSPasteboard, userData: String, error: AutoreleasingUnsafeMutablePointer&lt;NSString&gt;) { NSLog("performService called!") } And I instantiated my class like this: NSApplication.shared.servicesProvider = FinderService(). However, when I build and launch the application nothing happens, well my application runs fine and the instantiation of the class seems to be correctly called. But when I open my Finder, my action is not displayed in the right-click context menu. And in the logs of my application, no error appears. How can I test this?