现在还有多少人做 C++跨平台移动开发？

有什么好处吗

楼主可以考虑下 Qt ？

真的没有很大优势，要说某些核心模块用 C++开发还是可以的，整个底层框架全部用 C++开发，风险怕是比较高，毕竟企业做一款新产品，第一目标是尽快上线。

就是想不重复造轮子呗，逻辑写一次，然后在两个平台用

QT 能跨安卓 ios 开发吗？

进现在这公司 4 年半就是一直做这个，这项目已经存在不知道多少年了，就是你说的这种形式，我做下面的 C++部分。

个人觉得坑主要在 C++和 UI 层的接口很难设计，既要好用，又要高效，有点像鱼与熊掌。胶水代码又会增加维护难度。
然后是权责容易分不清，有些事情既也可底层 C++做，也可以上层 UI 做，会互相推诿。
再就是对 C++人员要求略高，有时候需要了解各平台的细节，比如 socket，各平台就算是相同名字的 API，行为上也有差异，而且现在 C++不好招人。
最后，感觉缺一个好用的跨平台构建工具，我们之前用的 scons，用的 python 语法，总感觉不好用，后来收购合并了另一个产品，有一部分用了 cmake，情况更复杂了。

Qt 可以跨安卓 iOS 的
甚至还可以 wasm
基于 Qt 的 Felgo 也可以顺便看看

Qt 可以跨 Android，iOS，但不推荐做产品（自己玩票性质的可以试试。理由：
1. 界面不够 native look feel，而且基本上至少移动端和桌面端是要分别做的，有这精力直接上 native 开发不是更好？
2. 很多东西最终还是要用 native 的代码实现，比如 mac/ios 用 objc，android 用 java，然后自己加胶水代码调用
3. 最终生成文件体积大很多，感觉不太好
4. license 商业使用需要购买，大概一年 3w 多人民币
5. Qt 这个框架大毛病没有，项目规模稍微大点后就会发现小 bug 不断，如果你没发现 Qt 的 bug 说明你要么不细心要么水平臭

早些年大厂有人这么搞，不过现在由于原生的支持越来越强大，基本上没这个必要了
github.com/williamwen1986/Luakit 之前鹅厂搞的这个，用 lua 桥接写的你可以参考一下

底层业务逻辑用 C++写 ？？？
一般是追求效率的算法、或特定功能模块才需要 C++吧····
不然 C++开发效率哪比得上原生语言。

我感觉 C++人员要求高，难招人，这个一个问题就已经够难受了的

不扯 UI，一切好说。摊上几个奇葩的平台，基本上你不用 C++也没什么备胎能选。原生？能接受哪天突然发现某个原生 API 不够用或者政策出问题不给用了缺胳膊少腿也行，否则省省吧。
UI 的话，Web 的实现本身依赖 C++。别的你要是自己没把握撸整个平台的话就算了吧。

@missdeer Qt 这个项目技术上最大的毛病和其它类似 C++ 项目的毛病一样，就是把用户搞傻了，框架设计人员自己本事又不到家，以至于各种选型都是次等货色，还居然被社区稀里糊涂地接受了。
（什么 moc 就不婊了，那啥 qmake 啊 qbs 折腾了多少时间又滚回 cmake 这种半吊子……不安分老实 autocrap+make，或者搞个类似 xmake 的会死？）
而且基本上 Qt 的用户是没本事推翻 Qt 框架设计内部缺陷和拾人牙慧的问题的。小 bug 多也很自然，因为就没几个有本事一开始就尽量避免小 bug 的开发者有耐心对付这个陈年破烂。
然后不用 Qt 的 C++用户某种意义上还分裂了……（虽然这主要不是技术问题。）

C++移动端，貌似就 QT 吧？但 QT 又不如其他方案好用，目前也没听说哪个公司用 QT 开发移动端 app。从招人的角度看，java、oc 或者混合开发的人大把，公司如果选 QT/c++开发，估计很难找到合适的人。

你提的这个方案甚至还不如 J2ObjC 靠谱，至少这个感觉半死不活的项目目前还有人在维护

举个例子, iOS 华为商城 App, 一些商品的购买按钮是跳转到微信小程序.

可以参考 dropbox 最近的一篇 blog
讲为什么他们不再继续 c++ 跨平台的方案了

我们就是这么干的，我做的两个项目都是，一个已经十几年了，另一个五六年了。我自己刚做两三年，这种模式有好有坏，要有人能 hold 住才行，说白了就是要有大佬撑腰壮胆

@missdeer 可以考虑 jinja2

@crayygy 有没有新的项目还采用这种方案了？
是因为老项目没法回头了才继续采用的吧？

@crayygy 从你的 id 和回复记录看，我猜你是 Android team 的 Guangyu Yang ？

@FrankHB 我是想既然用 C++那么痛苦，两边直接用源生可以了。
如果是轻量级的 APP 再考虑跨平台技术，如 Flutter、RN

@missdeer 大佬，我认为招人难这点就很致命了，你们团队是不是长期存在严重的人力缺口？或者说某些业务 /项目，因为人力的问题，不得不采用源生方案？

@damngood Dropbox 都这么说，仍然有很多人不信邪的，我也很不理解。

@cyxcw11 确实一直在招人，内部推荐的奖励也越来越高，但是还是很难招到人，当然也不能排除学历门槛和薪资吸引力不够的原因。不过我们 C++的 code base 很大，我能预见的未来被换掉的可能性极低。。。

做过 Xamarin 跨平台 App 开发。

@missdeer 学历门槛是必须的，薪资如果比平时的移动端开发，高出太多的话，公司 HR 也会不爽。
我觉得难招的主要原因，还是 C++从业者很少投移动开发，现在大多数是后台、游戏引擎、人工智能方向。你一个移动端方向除了要 C++技能还需要 Android(Java)/iOS(OC)技能，别人优先会不考虑。
靠应届生补充的话，依然不是很靠谱，C++要求素质太高了，应届生都要培养好一段时间才能保证不经常踩坑。

我觉得能做到新项目新业务，不继续陷入 C++的这种假跨平台方案，已经够 hold 得住场面的了。

一般的应用，客户端的逻辑有很复杂吗？不是 UI + call HTTP API 吗

有一篇 slack team 的文章, 供参考 https://slack.engineering/client-consistency-at-slack-beyond-libslack-c9cfbe778fb7

这种模式没啥不好的，但是人不好找，离职成本也很高，有时候都找不到接手维护的。。。。。

成本不划算啊，前期 20%，后期 80%。。。还不如招原生。
这种跨平台项目，不失败，我是觉得很难。 不知道，大佬都是怎么想的。。。做过一段时间 RN 的菜鸡，留。

规模很大，有多大？我接触的一个跨平台的（ win，mac，ios，android ），几百万行的 cpp，无界面。界面开始是一个自己开发的库，js 驱动，后来放弃了。现在改成 node.js 方案。cpp 部分成为 node。界面部分是 js。
开发人员主要是由二十个左右的，有三十年 cpp 开发经验的人员组成。产品已经在全球运行了几年。用户很多。
这种项目，优先考虑不是语言，是你有没有合适的人和研发组织。找不到人，人员变动大，研发组织混乱，什么语言都没用。
那这个平台为什么能成？很简单，开发组由公司老板领导，成员都是几十年的老员工，老板第一线写代码，开发组没有沟通问题，没有协作障碍。需求清晰，技术路线变革很稳健。这些都是必要条件，没有的话只能自求多福了。

@missdeer yes，您是？

可以的 有些业务逻辑 用 C++构建 输出.a 库 iOS 可以接入使用的

@missdeer 商业使用时,以 lgpl 动态链接库的形式,不需要买授权吧

楼上很多人若无大型应用的经验就不要随便给建议，也包括对 C++一知半解的人

1. 大型应用
若都用原生开发的话，成本是极高的（包括不限于人力、开发与测试等等），当然，最大的是后期的维护成本。你要知道，就一端就有可能需要 5-10 个人的研发团队。光移动端就有 iOS/Android 主流的这两个。

而对于大型应用，一般根据公司的长远产品规划，逐步支持非移动端及智能硬件上也是会初步处于规划中的，比如 Window/OSX/Linux，以及智能硬件（如嵌入式的），若是这样的话使用原生的开发对于后续的运维与扩展（新功能、新平台）基本是不可行的，而且成本极高

而且还可能需要提供 sdk 给第三方（有这样的需求的）

2. 小型应用
这样的，随便是原生或是 h5 的方案或别的跨平台方案都是随便的，这个可以根据公司内部已有人员的技术栈选择就可以

3. C++跨平台应该怎么构建
对于这个的话，参考 google 维护的 WebRTC 就可以了——一个平台源码包括构建工具 >10GB

一般的做法，都是“C++库 + 平台接口层 + 原生（一般做 UI 与简单业务）”

稍微有些不一样的就是这个平台接口层的做法某，
a ） 比如可以直接用各个平台的原生语言封装一层提供接口
这种是目前主流的做法，WebRTC 也是这样。比如 Android 则是用 jni 封一层提供接口，iOS 就是 OC 一层；对于 Linux/OSX/Window 等，也是类似的做法。每个平台封装一层做接口

b ）可以网络的方式（如 IPC/MQ/RPC ）
这种更为灵活，这个做服务端是很成熟的做法；对于做大型客户端，有但是不太多

对于具体那种做法，是要根据业务进行综合评估的。

4. 对于 Qt 框架
其实 Qt 之前主要的应用场景是工业或嵌入式（如汽车电子、工控、各种智能设备）这些，对于跨平台这块，若 Qt 敢称第一，应该没有别的框架敢说第二。别拿基于 h5 的方案来说事，不是一个级别上的东西（包括性能、支持的平台等等这些）

做客户端，基于 Qt 好处的地方就是，
a ）提供统一的开发环境与构建方式
QtCreator + qmake/cmake，基本可以应付绝大多数场景与开发环境（ Linux/Window/OSX ）
输出根据自己的方案，可以是动态库或执行文件，都是没有问题的

b ）封装完善的基础功能
包括不限于常见的数据结构、网络（ http/ws 这些）、硬件接口等。简单点就是，很多基础功能不用自己维护，也不需要自己构建或寻找第三方的库（这个可以省事很多）

简单点就是，常用的基本都有提供


其实这最大的困难的地方就是，要用 C++做跨平台，团队内需要有非常资深的人可以 hold 得住整个框架，只要能够确保这一点，基本是不会有问题的。

另外，C++真的没有如外界所传的那么难。很多时候说难用，其实就是缺乏把握框架与方向的人，因为特性诸多，很容易给滥用。其实不管是什么语言，都存在这个问题，只是 C++更为明显而已。


注：本人维护过基于 C++/Qt 跨平台的客户端软件，源码量 > 50W 行以上，所以对于这块有足够的发言权。

其实若 go 再成熟下（对不同平台的支持——主要是移动平台），做跨平台的客户端 go 应该是最合适的做法。UI 层与业务层通过 RPC/MQ 这样的方式提供接口或服务

UI 用各个平台的原生来做，也可以用 h5 的方式（如 electron 或 flutter ）

ui 可以参考 cocos 2d 那套框架，但是移动端开发真心不建议 c++，开发和维护成本太高

会用一部分。

在大厂做这块几年了，上层接口逻辑和 UI 用原生语言（ oc/java，windows 上随便用哪个都可以），底层 C++，目前是 4 个平台：Windows/Mac/iOS/Android。
如果要给用户提供 sdk 或者用到第三方 sdk 的话，需要注意 iOS 下的符号冲突问题（ c++就改命名空间，c 的话自己写脚本对静态库符号进行重命名，这个是巨坑，挺恶心的。
客户端还需要考虑体积和性能问题。

暂时还没发现有别的靠谱方案

Dropbox 前阵子才放弃 c++开发移动端，另愿开发两套代码

本人作为一个从 windows 时代就开始编程的人，必须说跨平台付出的代价是巨大的，某些时候真的不是一套代码能解决所有的问题，所谓跨平台只适合你的业务并不是特别负责，对目标平台的原生功能应用不多的情况下，特别是项目初期，跨平台的初期收益能超越复杂度带来的代价，但是随着项目稳定，时间越长，跨平台带来的技术难度代价会超越“一套代码”带来的收益，这也是为啥凡是能活下来的大型 App 最后还是走了分化的，一个平台一套代码的道路

@rainymorn iOS 的 app store 不允许动态链接非系统的库

基础类库跨平台就行了，业务逻辑不推荐

@cyxcw11 理想情况下，C++ 的技术优势是一坨屎。重复重点，“一坨”屎。因为这种涉及移动平台的开发普遍缺乏标准化，基本上你用几个 native 方案就是几坨屎（语言、框架甚至开发工具都不怎么通用），充其量就是比 C++的屎小那么点；但只要是超过一坨，工程上的复杂性就超过一坨两倍以上；而且因为可以公开使用的资源可能不够丰富的问题会恶化；实际要正经考虑跨的平台不止两个，那就经常不止两坨；种种原因综合下来，高下立判。
然而非技术问题上的渣滓对一般来讲更麻烦。首先，C++ 糊的屎的粘度经常不够大，就算是自己造的，不专门安排人去“优化”框架本身的话，一不小心就散了，结果碎片化方案的数量上比直接用 native 的更恶心。然后，C++ 的用户素质比起现有 C++框架方案设计本身普遍还要低下，你招得到能 hold 住现有方案的人，那就是在赌脸。
和 @xsen 说的有点不同，这里 hold 住还不够，要保证框架维护人员能跟得上产品生命周期，否则万一人员流失交接起来会非常困难，规模一大会很快没法收拾，于是其实还得有足够强力的备胎开发人员才安稳……所以实力不够养的起闲人（乃至自己搞整个跨平台方案的）项目组基本就只能被迫放弃整坨 C++ 屎了。
尴尬的是，有些地方现实可行角度上还是非得用 C++ 不可，于是流行 C++ 写这种不得不用的所谓“关键”模块。所以你会见到这种大杂烩，其实就是工程上的妥协。（另一个角度上说，真能强行拿 C++ 硬肛的那确实算是有点实力的，虽然经常不能算是经济上的最优方案，质量也经常不咋地。）
而具体妥协的效果能怎么样，真没法一概而论，不光和人员素质，和开发内容（比如说现实不得不用 C++ 的模块占比）也有关。你还是得问问你老板能给多少预算和承受多少项目失败的风险再决定。
再具体来讲，如果你是要开荒自己造平台甚至造生态，那么一开始就上 C++ 之外，基本没什么别的选择（除非你自己能花几年做出汇编器编译器之类的全套工具链，像 Chez Scheme + Racket 这样；至于 C，会搞这个的更难找，别多想了）。
而如果只是要开发应用，那么方案余地会松一些。特别地，只限定 Windows/Linux/macOS/Android/iOS 这几个常见平台中的个别几个的话，可能还有不少别的选择。只是很遗憾，现时如果你打算通吃这些平台并执意避免分别重复开发不同的 native 实现，现成的方案里大概可能就只有 Qt 能马上上手——效果看着办，不大容易比用 native 的好。
关于 Qt 多提几句：
1.开发新平台的话，要是不考虑成本没项目周期限制，自造的肯定能有更大的余地。定制 Qt 是小的嵌入式平台的备胎选择，理论上确实也算是 Qt 的卖点之一，实际上嘛，呵呵……
2.话说回来，Qt 的 GUI 其实还算 Qt 里质量相对过得去的（尽管其实现的绝对质量不咋地，GUI 实现这部分隐藏了尤其多的外行人难以摆平的恶心的细节，相对质量一般总比临时赶工自己造的轮子好），所以要用 Qt 放弃还里面的 GUI 某种程度还是有点浪费的；而只是做业务框架，其实并不见得比有经验的自己搭框架好。
3.QtCreator 是能用，但主要只是跨平台统一环境有优势，实际体验谁用谁知道。如果你是 PM，建议别限制开发人员的环境（反正都跨平台了……）。同时，对上规模的项目，为了分散上游选型风险，需要考虑采取措施避免过于依赖 Qt-specific 的（特别是和别家 C++ 习惯都太不一样的）技术。
（我现在没维护多少用 Qt 项目的代码，但我为了自己造能代替 Qt 的备胎，主流 C++ 框架多少都看过，而且改过若干 W 行用 Qt 的开源代码自用，所以可修改性问题有多屎的参考意见……看着办。）

还是分情况吧
[小型项目]
你爱用什么都可以。
[大型项目]
不知道楼上各位公司体量和 Slack、Dropbox、Alibaba 等公司比起来怎么样？
是大厂招不到能 hold 住 C++跨平台、能“把握框架与方向”的人吗？
是大厂只能招到对 C++“一知半解”的人吗？
是大厂觉得钱多了，放弃掉“成本更低”的跨平台方案，选择“成本更高”的原生方案吗？
目前大厂中最多的情况依然是：上层 UI 用原生或者 JS 跨平台实现，底层每个平台一套代码。这套代码可以是 C++，但一般不会是一套代码全平台共享。
为什么？ C++跨平台初期可以让团队尝到“甜头”。但是项目一旦慢慢变大，随着业务扩张、底层深入、人员变动，“跨平台”的代码也会逐渐变得越来越难维护。

@abcbuzhiming 结论上我同意这位说的。
不过到这个份上，所有在这楼里提到问题的其实还只是冰山一角……能只考虑单一项目的问题而不是更长期的副作用，实在是很幸福的了。一方面，做项目会遇到选型问题；另一方面，维护个人技术栈也是很坑的。
虽然和主题没有直接的关系，我在这里想多补充一点生态而不是方案上的牢骚：造成现在的混乱的原因，虽然算不上是有意的，但过于放纵 naive 的 native 方案的开发者多少都有历史责任。
首先，业界公认的一些基础方案的可移植性实际是非常强的，远远超过在个别指定平台中选择可行方案的跨平台需求，但欠缺足够多的用户去鸟，造成形同虚设，还要在标准化上倒贴维护成本。
像 ISO C 从一开始就强调 portability，强到了绝大多数应用开发者匪夷所思的地步——比如 CHAR_BIT >=8 （ 1 字节可以大于 8 位），比如整数的表示可以源码补码反码之一，比如 '0' ~ '9' 执行字符集要求编码连续但 'A' ~ 'Z' 就不是……
一方面这些差异因为几乎从来没什么开发者去纠结而默认了—— POSIX 和 Win32 以及常见体系结构都钦定 1 字节 = 8 位，几乎所有体系结构都要求机器数用反码，除了 IBM 的某些异类都要求 'A' ~ 'Z' 的编码连续……这样的一个结果就是大多数 C 的开发者其实只是使用了一个较弱可移植性的子集。而 C 的层次上，因为提供了这样强的可移植性，对实现的约束就非常弱，所谓 strictly conforming program 几乎就没什么实际的活能干。其实 C 的用户在这个意义上已经分裂了，绝大多数的人都在用 GNU C、POSIX C 或者 Win32 下的 MSVC 方言，外加一票嵌入式平台的魔改方言。另一方面，ISO C 又不可能把这些方言都吸收了，因为这削弱可移植性，跟 C 的设计者的意愿就有冲突，也会引起不同厂商之间不可调和的矛盾。这就是一个长期没人能解决的两难状况。
ISO C++ 因为 C++ 的复杂性这样的一坨屎的情况，比 C 总体好得多（虽然 C++ 的乱加特性还导致另外的问题），比如干脆直接回避了 strictly conforming program 的概念。不过大部分 C 的可移植性包袱包括用户脱离语言 spec 的认知的问题也还是继承了下来（如大部分用户可能都不知道直到 C++20 才刚刚要去除除了补码以外的机器数的支持）。这样长期下来的结果就是 C++ 和 C 用户一样具有强烈的碎片化倾向，而标准语言长期不够用又反过来让不可移植的小圈子扩展更加猖獗继续加剧碎片化（如 Qt 的 moc ）。加上非通用工具使用经验的依赖，进一步大幅提升招人的成本。
对关心以后业界发展的生态用户来说，这一直是两难问题。一方面不能否认 Qt 这样的（相对标准 C++ ）半吊子扩展方案确实解决了标准语言不便搞定的不少问题；另一方面，越是依赖 Qt 这样的方案，越是没有办法阻碍分裂，以至于以后越来越不可能有标准化的跨平台方案能用（直接的原因：人员和工具成本越来越高）。
所以在选型的立场上我也是两难的态度：一方面用 C++ 这样的基础方案本身已经在承受无法彻底解决问题的困难；另一方面，足够大的项目中不去用 C++ 这样的单一基础方案而分别重复造轮子的选项，多出来的开销迟早会让你无法自拔。
WG21 已经认识到这里的问题的严重性了，所以才强推不适合在语言 spec 里搞定的 module 之类的东西，以便加强 tooling。不过技术上这种强行乱来我是不看好，该无视的还是无视吧。
（至于 C/C++ 最终是靠什么才在一片混战下活了下来？山中无老虎猴子称大王+历史包袱。）
其次，有不少大企业想建立生态填补这里的矛盾，但实际上技术上都失败了，败给了 C/C++ 的历史包袱。
考虑现在应用的技术栈，操作系统（是个大坑）先不提，光是运行时的实现，只要有些定制需求，就不可能彻底甩脱这个包袱。比如，各种服务器语言的运行时不是 C 就是 C++ 实现的；最终用户碰到的 web agent 几乎无一例外都是 C++ 实现的。结果就是你逃离 C/C++ 完成常规的开发基本还算可行，但一旦要“调优”，就得多少储备这些实现上的细节。然而运行时基本都不是自己开发的……谁能保证这样的任务总是能够被解决？（于是有的企业干脆就自己定制语言实现了，但还是一种循环。）
好在大部分项目在接触到这个坑之前，业务上可能就已经自然死了。但万一没死……恭喜你又制造了一坨业界历史包袱……
苦中作乐的话这也不全是坏事：恶心的屎全归结到 C/C++ 以后，C/C++ 就是屎的事实上的金标准，甚至在没有具体厂商撑腰的前提下就可以避免 vendor lockin。比如听说某果想仗着 ObjC 搞垄断？没关系，你 ObjC 糊弄多少新的开发者也没 C/C++ 的历史包袱和群众基础，只要能糊得上，就算没 native 程度的支持是会恶心到大多数开发者，但谅你也不敢彻底不支持，否则就是自寻死路。（相比之下，web 自己作另说，搞图形学什么的就有点惨了。）
最后，作为历史包袱的受害者能怎么做？
横竖都不咋地，如果没法改变所谓的生态，自求多福，祈祷不会遇到意外吧。
如果谁真能在业务以外实际推动跨平台的实践，我姑且代表个人表示感谢。不过我是真不太信整个蓝星人都不太搞得好的问题，一般人能不添乱的。能尽量别依赖并且能适当抵制不靠谱的半吊子 native 方案就不错了。
请量力而行。

草，一坨错别字……
“源码反码补码”→“原码反码补码”
“几乎所有体系结构都要求机器数用反码”→“几乎所有体系结构都要求机器整数用补码”

按照当时 Dropbox 的博客和后续的评价，他们的问题其实在于能搞定 C++ 框架的人跑了，现有团队 C++ 水平一般，而且看起来有些方向搞错了。

例如，他们提到的几个自己搞的库:

- json11 (为 c++11 开发的 json 库)

和 nlohmann/json , rapidjson 等比起来简陋太多了。这个库从 2013~2014 年开始在 GitHub 上维护。C++ 的 Serialization 库多如牛毛，json 库是打架最厉害的地方，不知道他们怎么想的要自己搞。

- 一套跨平台的 C++ 构建工具
"Most importantly, we needed a custom build system that created libraries containing C++ code as well as Java and Objective-C wrappers and could generate targets that were understood by both Xcodebuild and Gradle."
这种东西根本不是一个小团队能填完的坑……

跨平台里 C++ 应该承担的任务，我觉得 reddit 一个用户就说得很好：

> Slightly puzzled here, as it is not clear as what the scope of that C++ library is.

> I would expect dropbox to have a C or C++ cross platform library for its core behaviour (file content hashing, meta-data handling, sync configuration, thumbnail generation, indexing and searching, profile management, networking, caching, renaming, etc), and have it used on mobile and desktop platforms.

> Anything on top of that, like the model behind the mobile views, or the navigation logic, would be done in the native environment.

> From the look of it, it seems to me that they tried to implement pieces of the logic behind the UI of the mobile app in C++, and that isn't such a good idea. But I hope they didn't end up redoing all the core logic locally, that would be a waste.

> But still puzzled at the idea that the code that sync files may not be the same on all platforms...

https://www.reddit.com/r/cpp/comments/cqft4t/dropbox_replaces_c_with_platformspecific_languages/

在我看来，dropbox 这件事的意义在于告诉我们哪些地方尝试用 C++ 造轮子是坑，而不是“再也别考虑在任何跨平台应用里用 C++”. 不止是 UI 不应该跨平台写，所有不方便统一的 Native API 也要避免（例如它提到的“应用唤醒后台任务的 API”），这个不算 UI，但 platform-specific 的事情无论如何你也得写两遍，区别无非是 (Java/Kotlin 写一遍+ ObjC/Swift 写一遍) vs (用 C++ 写两遍然后用很难看的 macro/脚本 区分开)，前者毫无疑问会更清晰且更好调试。

@icylogic 这里有些细节问题其实不太好一概而论。我是指，关于 platform-specific UI。
对有意造轮子的 team 来说，实际上他们的产品本身已经就是框架了。如果 hold 不住当然应该放弃，但如果 hold 得住呢？
须知，native 的 GUI API 的设计大多真的是挺不咋地的。
如 Win32 API 的基于 HWND 的 GUI 部分，就普遍比之后所谓 DirectUI 设计得要烂（ Win32 API 烂的不止是整体风格问题，还有各种莫名其妙的随 API 版本碎片化的变通，比如子窗口半透明什么的）——其实后者才是应该正经设计的 API 的基本思路（乃至于我认为 DirectUI 这个词就不应该出现，因为所谓 DUI 就该是天生正常的套路）。
这个意义上，尽量依赖 native API 的 wxWidget 就比自造轮子的 QtWidget 靠谱，因为后者是方法论上更正常的原本就应该采用的设计。（这不限 C++ 。类似地，WPF 就比 WinForms 更自然。）
更进一步讲，我认为 C++ 这样的静态语言的普遍上不适合搞定通用 GUI 的任务。这个意义上，用 C++ 可能整体上就是历史习惯导致的错误选型。Web 在这方面就纠正了一部分，但还是相当地半吊子了。而移动端的玩意儿，我是不指望更干净。
水平比较，Win32 的 GUI 其实还算是 C/C++ API 里设计得比较好的了。（比起 X11 的一团混乱以及各种 CAD 之类的扩展 API 什么的惨不忍睹的玩意儿来讲的话。）
然而不踩过更烂的屎坑又没本事刷新自己技术栈的用户，可能用过一种 native GUI 就被这样套牢了，一旦换个底层技术栈就难以复用人员。这比项目维护本身可能还要命。
这样看，足够大的项目可能还不如一开始就如造 WPF 一样最小化跨平台兼容层的轮子了。

草，写反了，，“尽量依赖 native API 的 wxWidget 就比自造轮子的 QtWidget 靠谱”→“尽量依赖 native API 的 wxWidget 就不会比自造轮子的 QtWidget 靠谱”……

Pascal 也可以

我们游戏的战斗引擎是 C++, 然后渲染是游戏引擎

我做了两年多的 C++跨平台底层+Native UI 的（大型）客户端开发。迭代速度是很快。对人的要求比较高（需要熟悉不同语言的坑）。国内的某钉好像也是这种架构。

入坑 QT 中

感觉怎么说呢, 坑蛮多的.

入手成本高,维护成本也高.

很多问题都是 plantform-specic

遇到问题解决问题起来没有原生快.

@xuyuheng0905 钉钉用的是 CEF……底层逻辑是两套……UI 是混合 Native 和 H5 的……

@shuangya 移动端也是？

@shuangya 要分情况讨论。CEF 在 Windows/Mac 比较适合，但也只是业务实现的形式罢了。说白了就是个皮。通用模块用 C++开发的跨平台库，是在于模块复用 /维护 /性能等多方面考虑的结果，还是值得讨论和尝试的。

@shuangya
@xuyuheng0905
现在聊天软件的对话界面用 HTML 是一大流行趋势

我们也是 cpp 的 backend+native 的 UI，因为之前有 server 的代码可以直接移过来用（某些功能想直接在 client 做）。但是觉得这个维护起来非常不方便，而且人“跑”了也是一个潜在的风险。加上双端又有自己的限制，修修补补经常导致各端逻辑不一致。

@xzc2677 心真大……

@xuyuheng0905 钉钉移动端是 Native 实现核心功能，C++底层库（大部分代码是写了两遍的……）很多非核心功能都是小程序形式接入的

对于我这种，不是很懂 java 的，但是想弄一个自己的 app，核心全部 c++,java 就是一个显示而已