SwiftUI 只会让开发糟糕的应用变得更容易★ SwiftUI Only Makes It Easy to Develop Bad Apps
苹果曾向开发者承诺,其平台不仅容易开发应用,而且容易开发出优秀的原生应用。然而,虽然这一承诺在 AppKit 和 UIKit 上依然成立,但在已经诞生七年的 SwiftUI 上却从未真正实现。SwiftUI 虽然降低了构建基础 UI 的门槛,但在处理复杂应用状态和定制化需求时暴露出严重的局限性。这使得开发者很容易用 SwiftUI 拼凑出应用,却很难用它打造出真正符合平台高标准的高质量原生体验。
Sunday, 7 June 2026
Paulo Andrade 上个月的文章《使用 SwiftUI 在 2026 年构建纯正的 Mac 应用》:
我最近推出了 Shopie 的 macOS 版本,这款应用最初于去年年底在 iOS App Store 上线。Shopie 可以帮你关注感兴趣的商品:你可以创建心愿单,当商品的价格、库存状态及其他细节发生变动时,它会及时通知你。与我其他应用通常混合使用 AppKit(或 UIKit)和 SwiftUI 的做法不同,Shopie 完全使用 SwiftUI 构建。我希望以此最大化在 iOS、iPadOS 以及如今的 macOS 之间的代码复用率。这篇文章探讨了在 2026 年,SwiftUI 在 Mac 平台上究竟能做到什么程度,尤其是当你想开发一款具有真正原生体验的应用时。这并非一篇关于 macOS 版 SwiftUI 的详尽评测,它仅仅是我在移植 Shopie(一款相当小巧的应用)并保持其 100% 纯 SwiftUI 的过程中,所收集的解决方案与踩坑记录。
Andrade 举了大量的例子。他的结论十分严厉:
Apple 在这方面搞砸了。AppKit 曾领先于时代,而 UIKit 则是 AppKit 更加精炼的版本。苹果本该在 SwiftUI 出现的很早之前,就推出一个统一两者的严肃跨平台框架。然而,苹果却任由 AppKit 停滞僵化,然后试图一步到位地跨过这个问题。其后果随处可见。SwiftUI 高效、现代,且常常令人愉悦——直到你试图用它去打造一款真正优秀的 Mac 应用。就在那一刻,你会突然发现,自己正在为了 Mac 平台 20 年前就已经解决的事情而与框架苦苦搏斗。
SwiftUI 存在非常严重的问题。在我日常使用的应用中,最典型的例子就是 Apple Journal。那些几十年来一直稳定可靠的基础功能——有些甚至迄今为止都运行良好的东西——现在却出现了致命的故障。如果你运行的是 MacOS 26 Tahoe,请打开 Journal 并新建一条测试记录。输入类似“The quick brown fox.”的句子。然后双击选中单词“brown”并将其删除。接着执行“撤销”(Undo)操作。
你期望单词“brown”会重新出现,但实际发生的情况是……整个句子都消失了。彻底没影了。执行“重做”(Redo)操作,你也只能恢复到“The quick fox.”。单词“brown”就这么永远消失了,根本不在撤销栈里。这简直烂透了。我以前在 AppKit 应用中从未见过这种荒谬的情况。(我也没在 UIKit 应用里见过——而且在 iOS 版的 Journal 上同样会发生这种事。只是我们在 iOS 上很少执行撤销和重做操作,所以不太容易注意到罢了。)
我平时确实在使用 Journal 这款应用,就因为这个极其糟糕的撤销实现,我已经丢失了整句整句的文字。在 Journal 里编辑文本是一件危险的事情,因为 SwiftUI 连文本编辑这种最基础的功能都处理得如此糟糕。AppKit 早在 1989 年左右就把这个问题解决掉了,那比苹果与 NeXT 重组早了整整十年。我在这里举的例子只是冰山一角,Andrade 在他的文章中记录了大量类似的问题。Shopie 本是一款优秀的现代 Mac 应用——但读完他的文章,你几乎能真切地感受到,Andrade 的双手已经被无数个细小的割伤弄得伤痕累累。
因此,尽管目前全世界的注意力主要集中在明天 WWDC 上苹果的 AI 相关发布上,但我个人却非常关注 SwiftUI(在所有平台上)以及原汁原味的 Mac 原生开发。苹果过去向开发者传达的理念是,不仅为他们的平台开发应用很简单,而且很容易开发出优秀的、地道的原生应用。你开箱即可获得正确的复杂行为——比如 Undo/Redo。这一点在 AppKit 和 UIKit 上依然成立,但在 SwiftUI 上却从未实现过,而 SwiftUI 如今已经有七年历史了。这么长的时间,任何借口都站不住脚了。
需要完整排版与评论请前往来源站点阅读。