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

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?

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

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.

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

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

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 }

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.

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.

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.

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 don't see what your code would fix or change, other than creating an extra variable. It also changes the program behaviour, because now the variable created in if let index is never used. I should also specify that I was never able to reproduce this crash myself.

Such an elegant solution. There is potential for a data race, so that must be it. Thank you. (It's strange that Google doesn't show that other topic even when searching for the assertion name. Only this topic is found, on this website and on another website vmhkb.mspwftt.com. Do you know what that is?)