In theory it could cause a crash, but in practice it shouldn't happen as one is always a subfile of the other. I'm specifically interested about the crash I talked about, which is also shown in the crash report I attached at the end, and which I have no idea what it's caused by.

I tried some more myself and I was able to solve the issue by adding Apple Vision Pro to the Supported Destinations of the extension. Previously I had only added it to the main app.

Can you try deleting the phyical one and rely only on the "info.tab"? I don't see how, since the NSExtension plist key contains a nested structure. Inversely, can you de select from build settings the 'generate info.plist' and handle that fully manually? Not sure what that should change. Should I simply copy the generated contents into the Info.plist file? The error doesn't happen at compile time, but at installation time. What happens if you deliberately make the NSExtensionPointIdentifier 'wrong' like making a typo - do you get same error message? Same error message, now mentioning the updated NSExtensionPointIdentifier value.

Even a text paragraph in a website, when applied the CSS font-size: 20vh, resizes perfectly by keeping a constant ratio between container height and font height. Is there a way to adopt this behaviour in AppKit or should I just use a WKWebView instead of a NSTextView? Although from my first tests it looks like a web view always sets its own background, so it's not ideal to use as a text overlay.

Forgot this bit in the Document class which makes sure that documents that are only opened but not changed are not saved on quit again: override func read(from url: URL, ofType typeName: String) throws { ... savedText = textStorage.string }

Thanks for confirming. Unfortunately, you're asking me to do an unfeasible thing: I'm unable to test the thousands of bugs I filed on every new release. I'm just a single developer.

I just tried to load a video with subtitles in Safari, and the subtitles resize perfectly with the video (or at least the subtitle width is always proportional to the video width, while the height seems to be adjusted so that the line height is an integer, i.e. it changes in small jumps). Is it a secret how it's done, or can you share how that's implemented?

Thanks. I added a link to this post to the feedback. NSDocument.fileURL is nil for a new document that hasn't been saved – In that case, when you try to terminate your app or close the document window, AppKit shows an alert asking if you'd save the document, and so you should be fine. Yes, but only assuming that the document has been marked as dirty... which is what we're trying to work around. I noticed that there is another issue now: Create a new document. Type a letter. Switch to another app and back again. Type another letter. Quit and restart the app. The document is correctly restored, but when selecting File > Close (or hitting Command-W), it is closed without asking whether I want to save or discard it, and so it probably stays in its autosave directory without the user knowing where it is. This is my current implementation: class Document: NSDocument { private var textStorage: NSTextStorage! private(set) var savedText: String? override func data(ofType typeName: String) throws -> Data { savedText = textStorage.string ... } } func applicationShouldTerminate(_ sender: NSApplication) -> NSApplication.TerminateReply { var remaining = 1 for document in documents as! [Document] { if document.textStorage.string != document.savedText, let fileURL = document.fileURL, let fileType = document.fileType { remaining += 1 document.save(to: fileURL, ofType: fileType, for: .saveOperation) { [self] error in if let error = error { presentError(error) } else { remaining -= 1 if remaining == 0 { NSApp.reply(toApplicationShouldTerminate: true) } } } } } remaining -= 1 return remaining == 0 ? .terminateNow : .terminateLater }

Same with document.fileType. When do these properties become non-nil? I'm afraid they don't become non-nil soon enough for new documents. You ignore the error parameter of the callback passed to save(to:ofType:for:callback:). Shouldn't app termination be cancelled if an error happens while saving? I noticed that you used NSDocumentController.shared.currentDocument. In my example above I iterated through NSDocumentController.shared.documents. Is there a specific reason why you didn't do so as well? I still can't wrap my head around this behaviour that sometimes discards the latest text changes. It appears to me as a bug, but I got the impression that you still see it as expected behaviour. As I mentioned at the beginning, when entering any text, switching to another app and back again, then entering some new text and quitting the app, the last changes are discarded. Why does this only happen for changes that are inserted after switching to another app and back again? Why do changes inserted in a new document always seem to be saved, provided that I don't switch app? I tried creating a new document and typing the letters "a b c d e" with a 1 second time interval after each one, and they were always correctly restored after restarting the app. Whereas when creating a new document, typing the letter "a", switching to another app and back again, then typing "b c d e" (again with a 1 second time interval after each one) and quitting the app, only "a" is restored. If this is intended, what's the intention/logic behind this behaviour?

Thanks. This is a start, but it still won't work for documents that have no fileURL. The documentation doesn't specify at what point it becomes non-nil. Can you tell us more about this? On iOS, UIDocument.fileURL is not even an optional.

Seems to be solved in macOS 26.1 beta 1, thank you. Although I still wonder how Xcode is doing it without that fix...

By "some text that should appear the same," did you mean that the text size (both width and height) changes proportionally with the window size? Correct. Worth mentioning though, adjustsFontSizeToFitWidth doesn't provide a pixel perfection result. I haven't used UILabel.adjustsFontSizeToFitWidth before, so I'm not sure how it actually behaves, and I'm also not sure what you mean with "pixel perfection". I'm looking for a solution that resizes the text so that it stays proportional to the container view frame (which has a fixed aspect ratio). To be specific, I'm simulating subtitles on top of a video. While playing with NSString.size(withAttributes:) and NSAttributedString.size(), I noticed that these methods only allow me to determine the size of a string when laid out on a single, infinite line. There is no equivalent to NSString.draw(in:withAttributes:) that also takes a rectangle. Should I instead use NSTextView (in which the text is eventually laid out anyway) and query its frame property?

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 }