为什么坚持做原生应用？
在跨平台框架盛行的今天，分享我选择 SwiftUI 原生开发 macOS/iOS 应用的理由与体会。
2026年5月10日8 分钟阅读技术分享
原生开发的选择
在这个 Electron、React Native、Flutter 等跨平台框架大行其道的时代，为什么我依然选择用 SwiftUI 做 macOS/iOS 原生开发？
这不是一个容易的决定，但经过多年的实践和思考，我越来越确信这是正确的选择。
性能是体验的基础
原生应用在性能上的优势是显而易见的：
启动速度 — 原生应用几乎是瞬间启动，没有 WebView 或虚拟机的启动开销
内存占用 — 一个典型的 SwiftUI 应用内存占用通常在 20-50MB，而 Electron 应用动辄几百 MB
流畅度 — 60fps 甚至 120fps 的流畅滚动和动画，不需要额外的性能优化
电池续航 — 原生应用对 CPU 的使用更加高效，不会让你的风扇狂转
与系统深度集成
原生应用可以充分利用平台提供的一切能力：
通知中心 — 完美的系统通知体验
小组件 — iOS 和 macOS 的桌面小组件
快捷指令 — 与 Shortcuts 应用无缝集成
Spotlight — 系统级搜索集成
上下文菜单 — 原生的右键菜单和触控板交互
Handoff — 在设备间无缝切换
这些集成不是「锦上添花」，而是构成了完整的用户体验。
SwiftUI 的开发效率
很多人认为原生开发效率低，但 SwiftUI 改变了这一点：
声明式语法 — 与 React 类似的思维模式，描述你想要的界面
实时预览 — 修改代码的同时看到实时效果
原生组件 — 不需要自己实现导航栏、列表、标签页等基础组件
无障碍访问 — 系统组件自带无障碍支持
深色模式 — 几乎不需要额外适配
跨平台的代价
跨平台框架确实有「写一次，到处运行」的诱惑，但实际代价是：
平台感缺失 — 在 macOS 上感觉像网页，在 iOS 上感觉像 Android
调试困难 — 框架层的 bug 往往难以定位和修复
版本滞后 — 新系统功能发布后，需要等待框架支持
体积臃肿 — 内嵌浏览器引擎导致应用体积巨大
维护负担 — 框架升级经常带来 breaking changes
我的建议
如果你的目标平台只有 Apple 生态，强烈推荐原生开发。SwiftUI 的学习曲线并不陡峭，而且你能获得最好的用户体验和最高的性能。
如果你需要同时覆盖 Android，可以考虑共享业务逻辑层（如网络请求、数据模型），但 UI 层仍然建议各平台原生实现。
总结
做原生应用不是为了「炫技」，而是为了给用户最好的体验。当你打开一个应用，感受到它和系统浑然一体、丝滑流畅的时候，你就会理解这份坚持的意义。