根据我对 SO 的了解，Qt 在 OS X 上看起来根本不是原生的。
那么你如何解决这个问题？您是否使用其他 GUI 库，例如 GTK？但是它不会在 Linux 以外的任何东西上原生，对吧？
您是否必须为每个操作系统编写 GUI？所以你为 Windows 编写了一个 Qt GUI，为 Linux 编写了一个 Qt GUI，为 OS X 编写了一个 Qt GUI？或者它看起来仍然是非本地的？
您是否必须根据操作系统使用不同的 GUI 库？所以你在 Windows 上使用 Qt，在 Linux 上使用 GTK，在 OS X 上使用 Cocoa？但 Qt 不仅仅是一个 GUI 库；它有很多功能。那么这是否意味着您需要为 Linux 和 OS X 重新发明轮子？
根据我的经验，您在开发 GUI 时有两个相互竞争的目标：
就目前而言，您基本上必须选择对您最重要的一个。
据我所知，没有任何 GUI 工具包可以实现可移植性和看起来“属于”每个平台的结果的理想完美——这包括 C++ 和 Java 选项。肯定有一些东西可以达到接近原生的外观，但总有一些东西不太对劲。就个人而言，我开始更喜欢我称之为“引擎便携性”的东西，而且我敢肯定它有更好的名字。基本上，它将使您的逻辑核心尽可能可移植，同时能够（但不需要）在必要时移植 GUI。
这基本上意味着不要依赖像 Qt 这样的库的所有非 GUI 功能，除非您确定它们将在您需要运行的每个目标平台上可用。例如，我不得不将一些 C++ 代码移植到 Android 上，而当时 Android 上的 Qt 并不存在。如果我的核心逻辑依赖它，我会遇到麻烦。如果我的引擎没有很好地与我的 GUI 分离，我就会遇到麻烦。事实上，我不得不用 Java 重新编码 UI，然后通过 JNI 调用引擎。我还得移植一些低层的特性，比如线程，因为当时C++11还没有定型，不能使用boost线程，而且原代码是针对Windows的。但是核心逻辑并没有直接调用操作系统线程库，
（顺便说一句：这并不是说您不能使用 Qt 之类的非 GUI 功能，但是如果您的代码与它紧密相关，那么如果您必须为该库的平台编写代码，那么您将陷入困境不支持。如果你的代码和Qt之间有抽象层，那么你只需要移植抽象层。）
便携并不容易。事情肯定已经走了很长一段路，但我们还没有实现我们开发人员都希望拥有的东西，而且我不相信我们真的会做到。
这只是恕我直言，但它是基于经验。