The NSAttributedString supports this attribute since macOS 12, allowing users to use language identifiers to specify which PingFang variant (SC, TC, or HK?) should be used to draw system font. static let languageIdentifier: NSAttributedString.Key I don't know how to use this identifier with Text() in SwiftUI.

Apple offered two ways of reading data from FileHandle(): // till macOS 10.15.3 func readData(ofLength length: Int) -> Data // macOS 10.15.4 and later func read(upToCount count: Int) throws -> Data? For some reasons I have to use the previous one (to make sure it works with older macOS releases). However, the first choice doesn't throw fileHandleOperationException by default. Is there a way to let it return nil on fileHandleOperationException?

I found a classic NSAlert implementation in Objective-C (written by TroikaTronix). I managed to rewrite the entire implementation in Swift: https://github.com/TroikaTronix/NSCustomAlert/pull/3 (See NSClassicAlert.swift) It looks good except that all buttons in NSClassicAlert does not execute its designated actions. I don't know why. @discardableResult public func addButton(withTitle title: String) -> NSButton { let frame = NSRect(x: 0, y: 0, width: 40, height: 30) let btn = NSButton(frame: frame) btn.bezelStyle = .rounded btn.font = .systemFont(ofSize: NSFont.systemFontSize) btn.target = self // TARGET ACTION btn.action = #selector(buttonPressed(_:)) btn.title = title btn.sizeToFit() btn.tag = buttons.count expandButtonSize(button: btn, amount: 10, minWidth: 75) buttons.append(btn) panel?.contentView?.addSubview(btn) return btn } @objc internal func buttonPressed(_ sender: NSButton) { guard let panel = panel else { return } var response = NSApplication.ModalResponse.alertFirstButtonReturn switch sender.tag { case 1: response = NSApplication.ModalResponse.alertSecondButtonReturn case 2: response = NSApplication.ModalResponse.alertThirdButtonReturn default: response = NSApplication.ModalResponse.alertFirstButtonReturn } if let docWindow = docWindow { docWindow.endSheet(panel, returnCode: response) } else { NSApp.stopModal(withCode: response) } panel.orderOut(nil) }

I tried googling this, but only found results dealing with other file formats like images.

I have an issue with my input method project (an open-sourced project offering some crucial features that macOS built-in bopomofo method didn't offer in these decades). Its candidate list window consists of NSTextFields wrapped with nested stack views. It works well on macOS 10.13 High Sierra and macOS 13 Ventura. However, on macOS 10.9 Mavericks it shows nothing, looking like every of its sizable components are shrinked to nearly zero width and zero height. At least, if setting the window Opague to "false", it doesn't show anything. Here's the candidate window controller: https://github.com/vChewing/vChewing-OSX-Legacy/blob/ff9eccd22dba22225a858d57b5f1eb9f4b9cbd17/vChewing/Modules/CandidateControllers/CtlCandidateTDK.swift Here's the candidate view (subclassed from NSStackView): https://github.com/vChewing/vChewing-OSX-Legacy/blob/ff9eccd22dba22225a858d57b5f1eb9f4b9cbd17/vChewing/Modules/CandidateControllers/VwrCandidateTDK_Cocoa.swift On update, the window controller regenerates the entire view using a shared backend CandidatePool instance. CandidatePool offers data of Strings and NSAttributedStrings as materials, and the frontend will use these materials to construct the candidate panel. Note: The codebase of these components are exactly the same (except the lack of SwiftUI-specific things for macOS 10.15 and later) as what used in vChewing Mainstream release (requiring macOS 10.13 and later): https://github.com/vChewing/vChewing-macOS/tree/ReferenceForApple/Packages/vChewing_CandidateWindow/Sources/CandidateWindow/TDKCandidates Its SwiftUI version of the candidate view is inside the folder above. I was thinking of opening a Code-level support ticket, but I just don't know whether they still deal with such compatibility issues with macOS 10.9, the last macOS release that supports Steve Job's Aqua interface (making people want to lick on it). BTW: I do wonder why SwiftUI lags terribly in this case.