I'm sorry for the confusion, I know the two are completely unrelated. I just wanted to point out that they are currently different in the following way: one can be controlled within the app (login items), and the other one cannot (status item). For me, it would have made sense if both can be managed in System Settings alone. I just thought that perhaps it was Apple's intention to "slowly" migrate the status item to something that can strictly be toggled in System Settings (similarly to widgets and extensions which cannot be added or removed by the app itself).

Thanks for explaining about SMAppService. Admittedly I haven't used it to add login items or agents yet, and I probably made some wrong assumptions about how it would work. Regarding the status item, I filed FB20384263. Below is the code I attached to reproduce it. If this bug gets solved, will I be able to change isVisible back to true from within the app and have it reflected in System Settings? That's what I was talking about in my previous reply: if the current behaviour is intended, then one could enable the status item in the app, disable it in System Settings, and later become mad at the app because apparently the in-app preference doesn't make the status item visible again. That's why I was considering to remove the in-app preference and let the user toggle it in System Settings, just like with the system status bar icons. I personally like the idea of an app offering the functionality and then letting the user enable or disable it outside of the app, just like widgets or extensions (e.g. for Finder and Shortcuts). @main class AppDelegate: NSObject, NSApplicationDelegate { var statusItem: NSStatusItem! func applicationDidFinishLaunching(_ aNotification: Notification) { statusItem = NSStatusBar.system.statusItem(withLength: 20) statusItem.button?.image = NSImage(systemSymbolName: "globe", accessibilityDescription: nil) Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [self] _ in print(Date(), statusItem.isVisible) } } }

I'd really appreciate any concrete tip on how I should save the document, because everything I've tried doesn't work. Simply calling updateChangeCount(_:), like we already saw, messes with the undo mechanism. How is the text view able to save everything I input when the window first appears and then quit the app, but isn't able to when switching to another app and back again? This is the last thing I tried, and when quitting the app the .terminateNow branch is always executed. Just calling endUndoGrouping() without beginUndoGrouping() logs an error in the Xcode console that no undo group is currently open. func applicationShouldTerminate(_ sender: NSApplication) -> NSApplication.TerminateReply { for document in documents { document.undoManager?.beginUndoGrouping() document.undoManager?.endUndoGrouping() } let edited = documents.filter({ $0.hasUnautosavedChanges }) if edited.isEmpty { return .terminateNow } var remaining = edited.count for document in edited { document.autosave(withImplicitCancellability: false) { [self] error in if let error = error { presentError(error) } else { remaining -= 1 if remaining == 0 { NSApp.reply(toApplicationShouldTerminate: true) } } } } return .terminateLater }

In your case, the changes in your text view don't go to the undo stack Only the last changes, all previous other changes do as expected. save the document as needed That is what I'm wondering about. What is the correct way of nudging the undo mechanism so that autosaving would see the document as dirty? We already saw that simply calling updateChangeCount(_:) breaks the undo mechanism. though AppKit folks may see the current behavior, which skips the save for a clean document when terminating the app, as correct Skipping save for a clean document is correct in my opinion as well, but the problem is that the document should not be clean in this case, and the question is how it should correctly be marked as dirty without breaking the undo mechanism. The text view probably has an open undo group (waiting for more text to be inserted) that should be closed when trying to quit the app, so that the document is then correctly marked as dirty.

Thanks. Your code doesn't do step 2, and that's why your changes are lost. But again, even without doing that, the document is regularly saved, so the fact that the very last changes are not saved is, from my point of view, unexpected behaviour. I came across NSDocument.updateChangeCount(_:) some time ago, but concluded that I shouldn't interfere with automatic saving done by the text view. For instance, when using your latest code, if I type anything in an empty document, then undo all the changes and try to close the now empty document, it presents a save panel. This doesn't happen when I just let the text view track the changes (which is also what I would expect). The documentation for that method reads: If you are implementing undo and redo in an app, you should increment the change count every time you create an undo group and decrement the change count when an undo or redo operation is performed. Note that if you are using the NSDocument default undo/redo features, setting the document’s edited status by updating the change count happens automatically. You only need to invoke this method when you are not using these features. Since the documentation says that I don't need to call that method when I use the default undo mechanism and, like I explained above, doing so introduces unwanted behaviour, I'm a little wary. I even had this code in my production app for some time many years ago, but then removed it again, possibly because it caused other unwanted side effects or bugs (although I don't remember exactly right now). I think I also tried implementing my own undo mechanism for text views, but quickly figured out that going beyond a basic implementation (registering a new undo group for each typed letter, which is a pain for the user to undo and not what they're used to) would take too much time. It looks to me like the default undo mechanism would need to be nudged when the user tries to close a document or the app. Would that be something AppKit could do automatically in a future release, and can I nudge it somehow now?

Thanks for your input. I haven't tested this, but I think isVisible will tell you when it's been disabled. I tried before posting, but isVisible stays true even when disabling the status item in System Settings. I'd generally recommend using an agent (not login item) But will the agent be listed in System Settings > General > Login Items? If not, then that could be another source of confusion, similar to the status item: the user can enable "launch at login" both in the app (which uses an agent) and in System Settings (which uses a login item), then later removes it from System Settings and wonders why it keeps being launched at login (because they forgot that they have to disable it in the app as well). In my opinion it would make more sense to use an option that is kept in sync between the app and System Settings, or remove it from the app entirely since it can already be done in System Settings. Looking at how different privacy features are implemented in macOS, I would have expected that login items (or agents, or however we might call them) can be disabled in System Settings, without the app being able to turn them on again without the user noticing. That's the same reasoning that makes me want to remove the option to show or hide the status item from my app in macOS 26: System Settings has the last word in regard to the status item's visibility, so it would only be confusing to have that option in the app if toggling it doesn't do anything. After all, the status item is something similar to a widget, and I haven't done widgets yet but I would assume that they can only be added and removed by the user outside of the app (in macOS itself).

I forgot to mention that this behaviour only happens when using the .fullSizeContentView window style mask. Without it, the sidebar extends almost to the top of the screen in fullscreen mode. It's still cut off shortly before reaching the top, but at least there's not such a big gap. When moving the mouse to the top of the screen to show the menu bar, the top of the sidebar and content view are hidden, but that's what I would also expect with a full screen content view.

Thanks, that link mentions this exact use case.

Sorry, perhaps I wasn't entirely clear. I know about app sandboxing. What I meant is that when selecting ~/Library in an open panel, I would expect to get access to every subfile and subfolder, just like when selecting any other folder. Instead, trying to access ~/Library/Mail (and other folders) as a result of scanning the files contained in ~/Library gives the error I mentioned. Only when selecting these folders explicitly in an open panel there are no errors when trying to access them.

I tried this implementation to autosave changes before quitting the app, but it doesn't work since NSDocument.hasUnautosavedChanges is unexpectedly false. I now get the impression that perhaps a document would be saved automatically before quitting, but there is an issue with how NSTextView marks a document as edited. I would appreciate any insight into this issue. func applicationShouldTerminate(_ sender: NSApplication) -> NSApplication.TerminateReply { let edited = documents.filter({ $0.hasUnautosavedChanges }) if edited.isEmpty { return .terminateNow } var remaining = edited.count for document in edited { document.autosave(withImplicitCancellability: false) { [self] error in if let error = error { presentError(error) } else { remaining -= 1 if remaining == 0 { NSApp.reply(toApplicationShouldTerminate: true) } } } } return .terminateLater }

With the system monospaced font it seems to work, regardless whether I use the window width or height to calculate the font size. On the other hand, with the standard system font, it doesn't work with either width or height. I thought the font size is related to the height, in which case using a monospaced font (where characters have equal width) should make no difference.

size(withAttributes:) returns CGSize not a number. Why wouldn't you calculate newSize = actualSize * newWidth / pastWidth instead? But that's the same as calculating newSize = newWidth * constant, which as I showed doesn't work.

That's exactly the question: how do I adapt the size to fit the window width? I don't see how size(withAttributes:) would help me finding out the correct font size with a single call.

Also when setting SCStreamConfiguration.includeChildWindows = true it’s currently not possible to capture the image of the correct size (i.e. in full resolution).

Thanks, that seems to work. I would have preferred not having to rewrite the various pieces of code that update the table view, but at least we have a workaround.