When any image view is being destroyed, make sure you're setting the target image to null and you've torn down any KVO "infrastructure" you've created that's tied to that object The NSImageView is in fact in a NSTableView, and I call NSImageView.bind(_:to:withKeyPath:options:) in the callback passed to NSObject.observe(_:options:changeHandler). The observer is added when the table cell view's objectValue is set, then removed again when it is set to nil. I'll add a call to NSImageView.unbind(.value) and see if that solves the crash. class MyCellView: NSTableCellView { private var observer: NSKeyValueObservation? override var objectValue: Any? { didSet { if let objectValue = objectValue as? MyObject { observer = objectValue.observe(\.property) { [weak self] _, _ in for view in subviews { view.removeFromSuperview() } let imageView = NSImageView(image: nil) imageView.bind(.value, to: objectValue, withKeyPath: keyPath) addSubview(imageView) } } else { observer = nil } } } } That's generally a reasonable statement for the "core" of Objective-C’s memory management model Not sure if it's relevant, but I'm using Swift, although I suspect KVO is at the Objective C level. I would also try Zombies Sorry, forgot to add that I also enabled that one, but no crash for now. I'll keep that enabled too. Thanks for your precious input and I'll update you when I find out more.

[quote='853904022, DTS Engineer, /thread/777545?answerId=853904022#853904022'] Your code has me a bit confused. [/quote] I should have gone more into details. The property in objectValue.observe(\.property) is actually an array of objects that represent a file URL, and in the observer callback I iterate through that array, create an image view for each element, and bind the image to a property of the respective element. The table view cell effectively displays a dynamic set of URL icons. I modify MyObject.property (I should have called it MyObject.entities) whenever an element is added or removed, and I modify MyEntity.image whenever the image changes. objectValue is set by the table view. I'll think if I can avoid using KVO, but this means I'll have to reload the table view cells manually in quite some places.

[quote='853894022, DTS Engineer, /thread/784984?answerId=853894022#853894022'] On macOS, a user can kill an app in different ways [/quote] I don't expect the document changes to be saved when the user intentionally kills the app, but I would expect that when the app is quit normally via the main menu or keyboard shortcut Command-Q, the pending changes would be saved. Are such changes really intended to be discarded? After all, if there is an open document that has never been saved and I try to close it, I'm asked if I want to save or delete it. Why would the last changes not be autosaved when I gracefully quit the app? It seems weird that changes are saved periodically, but not at the very end of the lifetime of the app. If I'm really supposed to autosave all documents manually in applicationShouldTerminate, which API should I call? Again, it seems weird that this is taken care of automatically until before quitting the app, and then I have to manually track which documents are saved and when everything's saved, quit the app. It would seem to me like boilerplate code that every document-based app would automatically want.

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.

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

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.

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.

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.

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 }

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.

Thanks, that link mentions this exact use case.

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 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).

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?

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.