坚定地选择 Swift 语言
我大约是从Swift3.0版本才开始接触Swift语言的，陆续通过Swift语言重构或新开发了一些项目。我现在依然清晰的记得，因为那时Swift的ABI尚未稳定，很多语法特性还在频繁变动，每次升级Xcode之后，伴随着Swift编译器版本的升级，我都要花一些时间处理因语法变动带来的业务代码的修改。虽然这部分工作大部分情况下被Xcode自动完成了，但还是有少量的错误需要手动处理，这是非常让人不悦的。如果说那个时候在项目中使用Swift考虑兼容性、稳定性等问题还有情可原，那么现在，2023年，Swift语言早已经定型，稳定性已经得到充分验证，作为iOS开发者应该坚决地选择Swift。依然对Objective-C抱残守缺的，就有些不思进取了。
现在，Swift编译器已经足够聪明足够智能，可以放心地在新App、新SDK、甚至一个单模块中使用Swift编写业务。也不用担心Swift和Objective-C混编，modulemap很优雅地处理了这个问题，在SwiftUI中你甚至能够发现几乎不需要开发者额外处理，可以直接使用Objective-C对象。
从 UIKit 到 SwiftUI
SwiftUI必须使用Swift语言开发，入门SwiftUI先要掌握Swift语法。
从UIKit到SwiftUI不是简单的更换UI框架，而是开发思维的转变。这点对于开发者来说，可能在开始会有些不适应，但多尝试几下，就会发现声明式UI框架的好处。如果你有Vue.js、Flutter、微信小程序等其它声明式框架的开发经验，那么使用SwiftUI就会更得心应手了。我单方面认为，使用UIKit的经验似乎并不能为转向SwiftUI带来优势，相反做过Vue.js等开发的同学可能会更容易上手SwiftUI。在各种前端框架已经将声明式布局作为标配的时候，SwiftUI在理念和设计上应该更有后发优势。
在UIKit时代，我们经常讨论的MVC、MVP和MVVM等设计框架，在SwiftUI这里终于可以终结了。说实话，我个人非常反感这类感念。一方面每个人的理解很难完全一致，另一方面即使完美实现了一个方案，也很可能会在后续的业务变动中因为不同开发者的接手造成对原有实现的歪曲。如果一个方案不是通用，且是可替代的，那么就不能成为金科玉律。
SwiftUI完美的解决了这个问题，解决方式果断而暴力：现在开发者有且只能有一个选择。SwiftUI原生支持数据的双向绑定，开发者再也不需要为了实现所谓的MVVM而借助各种第三方框架编写各种奇怪的、晦涩难懂的但感觉很高大上语法的代码了。
使用SwiftUI，可以确保团队中所有开发者的代码思路都是相对统一的，至少降低了怪异代码风格的概率，再也不会有MVC、MVP、MVVM之争。
是时候学习 SwiftUI 了
结合笔者使用SwiftUI这段时间的感受谈谈：
- iOS 13系统的普及率
SwiftUI最低支持iOS 13系统。截止到2023年1月，有约1%的iPhone设备使用的是iOS 13及以前的iOS系统，再加上API的升级或变动，这部分系统的用户可能无法正常使用SwiftUI开发出的APP或不能使用某些特性功能。商用App需要考虑到这部分用户。
- 和 UIKit 并存
SwiftUI还不能完全脱离UIKit。SwiftUI提供了UIViewRepresentable和UIViewControllerRepresentable解决向SwiftUI过渡过程中对UIKit一些依赖，有些UI效果现阶段可能必须得依赖UIKit实现。这个依赖的持续时间应该会很漫长，在可以预见的未来，UIKit和SwiftUI会一直并存使用。
- 对 Flutter 等的影响
SwiftUI应该会对Flutter等造成一些冲击，这并不是技术原因，而是话语权的问题。在Apple生态中，Swift和SwiftUI是目前主推的技术方案，对于iOS开发者来说，首选肯定是SwiftUI，而且私以为目前跨端开发有逐渐式微的趋势，原生开发框架的效率和优势会越来越明显。
- 开发者该如何选择？
可以肯定的是，向 SwiftUI 迁移是必然的趋势，现在就应该学习SwiftUI并储备相关的技术知识。后续，我也会结合开发过程中遇到的问题多写一些SwiftUI相关的文章。
留言板