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.