2026年7月,当我们回望2019年那个万众瞩目的夏天,SwiftUI的诞生曾承载着无数开发者的憧憬与期待。彼时,苹果在WWDC上用「声明式UI」「跨平台重用」「实时预览」等关键词,宣告了一个新时代的到来 - - 告别Auto Layout的复杂,告别UIKit的冗余,告别平台割裂的痛苦。然而,七年过去,SwiftUI非但没有成长为一款成熟的生产级框架,反而沦为了一款「永远的Beta」。它的数据流如同黑盒,布局系统如履薄冰,API稳定性如同空中楼阁,性能表现更是让人怀疑苹果是否在「用M系列芯片掩盖架构缺陷」。而在这背后,隐藏着的,是苹果从「无 compromise 的工艺」向「够用就好」文化的蜕变,以及一场关于软件质量标准的全面滑坡。**一、从「革命性」到「半成品」:SwiftUI的七年蜕变**2019年6月,苹果在WWDC上发布SwiftUI时,现场掌声雷动。
时任苹果软件工程高级副总裁的克雷格·费德里吉(Craig Federighi)用「改变一切」来形容这款框架的意义。在他看来,SwiftUI将终结开发者与Auto Layout的「战争」,让UI开发像搭积木一样简单。然而,现实总是残酷的。时至今日,SwiftUI的「革命性」早已被「半成品」的标签所取代。我们不妨从三个维度来审视这七年的变化:首先是**开发者体验**。在SwiftUI的早期版本中,开发者们被迫面对的是一个充满「惊喜」的框架:一个简单的@State变量变更,可能引发整个视图树的重渲染;一个看似无害的修改,可能让原本稳定的布局彻底崩溃。
为了应对这些问题,苹果不得不推出Observation框架和@Observable宏,试图通过编译器魔法来「修复」数据流的混乱。但结果呢?数据流依然是一个让人头疼的黑盒。开发者无法确定一个视图会在什么时候、为什么被重新渲染,甚至连苹果官方的调试工具都无法提供完整的信息。这种「不可预测性」让SwiftUI从「简化开发」沦为「制造惊喜」 - - 只是这些惊喜通常不是什么好事。其次是**布局系统**。SwiftUI的布局系统基于「尺寸协商」的理念,这在理论上听起来很美好:每个组件都能根据自身需求和父容器的约束来决定自己的大小。
然而,在实际开发中,这种理念却变成了开发者的噩梦。试图构建一个浮动视图或自定义侧边栏?恭喜你,SwiftUI的布局引擎会让你体验到「意想不到的惊喜」。就连苹果官方的SwiftUI教程项目,在最新版本的macOS上运行时,也会出现按钮大小异常、布局错位等问题。更讽刺的是,这些问题在过去两年里几乎没有得到改善。为了「修复」这些布局问题,开发者们不得不求助于GeometryReader - - 这个被戏称为「彻底放弃声明式UI」的终极工具。一旦使用了GeometryReader,你就不得不手动计算坐标,其复杂程度甚至超过了Auto Layout。
更可怕的是,这些坐标计算可能在下一个SwiftUI更新中就彻底失效,因为苹果的布局系统似乎总是在「猜测」开发者的意图。最后是**API稳定性**。在一个成熟的框架中,API的稳定性是开发者能够长期依赖的基石。然而,SwiftUI的API却像走马灯一样频繁变更。从NavigationView到NavigationStack的替换,从@State到@Observable的迁移,每一次变更都意味着开发者需要重构大量代码。更让人无奈的是,SwiftUI的许多核心功能(如键盘自动收起、窗口工具栏自定义、网络图片缓存)直到最近几年才姗姗来迟,而即便如此,这些功能仍然处于Beta状态。
为了在不同iOS版本间保持兼容性,开发者不得不在代码中塞满#if #available检查,甚至维护多个分支版本。这种「API地狱」让SwiftUI从「少写代码」沦为「更多维护成本」。而苹果官方的态度却是:「这是正常的,因为SwiftUI还在发展中。」 - - 只是,七年时间足以让任何框架成熟,更何况SwiftUI的问题并非「发展中」的问题,而是「设计缺陷」的问题。**二、性能与跨平台:SwiftUI的两大「伪命题」**在SwiftUI的宣传片中,苹果总是喜欢用「性能优越」和「跨平台重用」来吸引开发者。然而,现实与宣传之间的差距,往往大到让人瞠目结舌。
先说**性能**。SwiftUI的性能问题一直是开发者们心中的痛。尽管苹果在每次WWDC上都承诺会「大幅提升性能」,但实际体验却让人怀疑这些承诺是否只是「PPT上的数字」。以图片库滚动为例,即使开发者使用了所有已知的性能优化技巧(如后台线程解码图片),SwiftUI的滚动流畅度仍然无法与UIKit相提并论。更讽刺的是,苹果在演示SwiftUI时总是使用最新的硬件(如M系列芯片),仿佛在暗示:「如果你用的是旧设备,那只能怪你自己。」然而,真正的问题并不在于硬件,而在于架构。
SwiftUI的渲染管线过于复杂,导致在低端设备上表现糟糕。试想一下,如果一个简单的图片库滚动都需要M5 Pro Max芯片才能流畅运行,那么SwiftUI的架构设计本身就存在严重问题。再说**跨平台**。苹果在推广SwiftUI时,总是强调「学一次,到处用」。然而,现实是,SwiftUI在iOS上的开发经验很难直接应用到macOS上。例如,在iOS上开发的导航栏和侧边栏,到了macOS上可能完全不适用,甚至需要重新设计整个UI。
更让人无奈的是,同一个SwiftUI组件在不同平台上的表现可能完全不同。例如,一个在iPhone上看起来还算正常的列表,到了iPad上可能变得拥挤不堪;而一个在macOS上运行良好的窗口,到了iOS上可能变得寸步难行。这种「平台割裂」让SwiftUI的「跨平台」承诺沦为笑柄。开发者们不得不在不同平台上维护不同的代码路径,甚至重新设计UI,这与苹果当初「少写代码」的承诺背道而驰。**三、苹果的「够用就好」文化:从工艺精神到「快速交付」**SwiftUI的问题,不仅仅是技术层面的问题,更是文化层面的问题。它反映了苹果从「无 compromise 的工艺」向「够用就好」文化的全面转变。
在乔布斯时代,苹果对软件质量的要求是极其严格的。Aqua界面的「液态按钮」之所以让人印象深刻,不仅仅是因为它的视觉效果,更是因为它背后的工艺精神 - - 每一个细节都经过精心雕琢,每一个动画都经过精确计算。然而,随着SwiftUI的推出,苹果似乎放弃了这种工艺精神。在SwiftUI的世界里,「够用就好」成了新的标准。苹果音乐的播放队列编辑会导致歌曲跳转错误,TestFlight的选择框会被截断,iPad的设置应用会显示崩溃报告,这些问题在过去几年里屡见不鲜。而SwiftUI作为苹果的旗舰UI框架,其问题更是层出不穷:布局错位、性能低下、API不稳定......这些问题在苹果的其他产品中也有体现,例如Logic Pro的本地化缺失、Home Screen的图标重复显示等。
这种「够用就好」的文化,不仅体现在SwiftUI上,更体现在苹果整个软件生态中。从Catalyst项目开始,苹果就试图通过跨平台开发来「简化」Mac应用的开发。然而,结果却是一系列「外星人」应用 - - 那些看起来像iPad应用硬塞到Mac上的怪胎。这些应用不仅外观丑陋,而且交互体验糟糕。苹果本可以投入更多精力来优化这些应用的本地化体验,但它选择了「快速交付」。这种「快速」背后,是对质量标准的全面放弃。
**四、工程师的无奈:在「半成品」框架中挣扎**对于广大开发者而言,SwiftUI的问题不仅仅是技术上的挑战,更是一种职业上的无奈。七年来,无数工程师在SwiftUI的「坑」中挣扎,试图用各种hack和workaround来「修复」框架的缺陷。然而,这些努力往往只是治标不治本,甚至可能引入更多的问题。以数据流为例。为了应对SwiftUI的数据流混乱,开发者们不得不学习Observation框架、@Observable宏、以及各种undocumented的调试技巧(如Self._printChanges())。然而,这些技巧并不能从根本上解决问题,它们只是让SwiftUI的数据流变得「稍微可控」一些。
更让人无奈的是,苹果在每次更新中都会改变数据流的行为,这意味着开发者需要不断更新他们的代码以适应新的变化。这种「永远在变」的状态,让SwiftUI从「简化开发」沦为「持续维护」。在布局系统方面,开发者们不得不依赖GeometryReader来「修复」SwiftUI的布局问题。然而,GeometryReader的使用意味着开发者需要放弃声明式UI的优势,转而使用命令式的坐标计算。这种「退步」不仅增加了开发成本,更让代码变得难以维护。更讽刺的是,苹果在每次更新中都会改变布局系统的行为,这意味着开发者可能需要在下一个版本中重新计算所有坐标。
这种「永远在重构」的状态,让SwiftUI的开发体验变得极其糟糕。在API稳定性方面,开发者们不得不在代码中塞满#if #available检查,以确保兼容性。然而,这种做法不仅增加了代码的复杂性,更让代码变得难以阅读和维护。更让人无奈的是,SwiftUI的许多核心功能(如网络图片缓存)直到最近才姗姗来迟,而即便如此,这些功能仍然处于Beta状态。这种「永远不完整」的状态,让开发者们不得不自己实现这些功能,或者依赖第三方库。而这些第三方库的质量参差不齐,可能引入更多的问题。
**五、用户体验的「牺牲品」:SwiftUI的「够用就好」如何影响最终用户**当开发者在SwiftUI的「坑」中挣扎时,最终受害的却是用户。SwiftUI的种种问题,最终都会体现在用户体验上:布局错位、动画卡顿、响应延迟......这些问题让原本应该「流畅」的用户体验变得糟糕透顶。以苹果官方的SwiftUI教程项目为例。这个项目在最新版本的macOS上运行时,按钮大小异常、布局错位等问题层出不穷。这些问题不仅影响了开发者的开发体验,更直接影响了最终用户的使用体验。试想一下,如果一个用户在使用一款由SwiftUI开发的应用时,遇到了布局错位、动画卡顿等问题,他们会如何看待这款应用?他们会认为这是「应用本身的问题」,还是「SwiftUI框架的问题」?更让人担忧的是,SwiftUI的「够用就好」文化正在向苹果的其他产品蔓延。
从苹果音乐的播放队列编辑错误,到TestFlight的选择框截断,再到iPad设置应用的崩溃报告,这些问题无一不体现了苹果对「质量标准」的全面放弃。而SwiftUI作为苹果的旗舰UI框架,其问题更是直接影响了苹果生态的整体质量。**六、未来何去何从:SwiftUI能否「涅槃重生」?**面对SwiftUI七年来的种种问题,我们不禁要问:SwiftUI能否「涅槃重生」,成为一款真正成熟的UI框架?答案或许并不乐观。从技术角度来看,SwiftUI的核心问题(数据流混乱、布局不可预测、API不稳定)并非短期内可以解决的。这些问题根植于SwiftUI的设计理念,而苹果似乎并不打算对这些理念进行根本性的改变。相反,苹果更倾向于通过「打补丁」的方式来「修复」这些问题,例如推出Observation框架来「修复」数据流问题,或者通过GeometryReader来「修复」布局问题。
然而,这些补丁只能治标,无法治本。它们只能让SwiftUI「稍微好用一些」,但无法让SwiftUI成为一款真正成熟的框架。从文化角度来看,苹果的「够用就好」文化已经根深蒂固。这种文化不仅体现在SwiftUI上,更体现在苹果的整个软件生态中。从Catalyst项目开始,苹果就试图通过「快速交付」来「简化」开发流程,而忽略了质量标准。这种文化的转变,让SwiftUI从「革命性」沦为「半成品」,让苹果的软件生态从「精工细作」沦为「粗制滥造」。
在这种情况下,SwiftUI想要「涅槃重生」几乎是不可能的。那么,开发者们该何去何从?对于那些追求高质量、高性能、高稳定性的应用而言,SwiftUI或许并不是最佳选择。相反,UIKit(iOS/macOS)和AppKit(macOS)仍然是更可靠的选择。尽管它们的开发体验不如SwiftUI「优雅」,但它们的稳定性和性能表现是SwiftUI无法比拟的。对于那些追求「快速交付」的应用而言,SwiftUI或许是一个「够用」的选择。但需要注意的是,这种「够用」的代价可能是用户体验的全面下降。
**七、结论:SwiftUI的「半成品」困境与工程师的选择**七年过去了,SwiftUI依然没有成长为一款成熟的UI框架。它的数据流如同黑盒,布局系统如履薄冰,API稳定性如同空中楼阁,性能表现更是让人怀疑苹果是否在「用M系列芯片掩盖架构缺陷」。而在这背后,隐藏着的是苹果从「无 compromise 的工艺」向「够用就好」文化的全面转变。对于工程师而言,SwiftUI的问题不仅仅是技术上的挑战,更是一种职业上的无奈。七年来,无数工程师在SwiftUI的「坑」中挣扎,试图用各种hack和workaround来「修复」框架的缺陷。然而,这些努力往往只是治标不治本,甚至可能引入更多的问题。
在这种情况下,工程师们不得不在「快速交付」和「高质量」之间做出艰难的选择。对于用户而言,SwiftUI的「够用就好」文化意味着更多的布局错位、更多的动画卡顿、更多的响应延迟。这些问题让原本应该「流畅」的用户体验变得糟糕透顶。而苹果作为用户体验的「守护者」,却在放弃对质量标准的坚持。七年时间足以让任何框架成熟,更何况SwiftUI的问题并非「发展中」的问题,而是「设计缺陷」的问题。在这种情况下,SwiftUI的「半成品」困境或许将成为永远的遗憾。
而工程师们,也将继续在「半成品」框架中挣扎,期待着有一天,苹果能够重新拾起「无 compromise 的工艺」精神,让SwiftUI真正成为一款成熟的UI框架。 。
