从Swift到Rust：一个iOS开发者的系统语言祛魅史

Swift基础：面试官爱问、项目里真会踩坑的东西

第一个坑：值类型和引用类型。2019年我在一家电商公司，线上用户地址列表刷新后数据串了。排查到凌晨两点，发现某同事把class改成了struct，觉得“结构体更安全”。结果struct是值拷贝，闭包捕获的是副本，改了不生效；他又用inout强行改，直接改崩了数据流。

值类型在赋值和传参时发生拷贝，引用类型共享同一份内存。枚举也是值类型，且Swift的枚举可以关联值。比如网络请求结果：

enum Result<T> {
    case success(T)
    case failure(Error)
}

这种写法在Objective-C里得用两个可选值或回调block塞一堆参数，Swift一个枚举就搞定。

第二个知识点是可选值。Swift用?和!把空值处理从运行时提前到编译期。Objective-C里给nil发消息啥事没有，Swift里!直接crash。但这逼着你在写代码时就思考“这个值到底能不能为空”，长期来看少了很多线上崩溃。

第三个是协议导向编程。Swift标准库大量使用协议扩展，实际开发中我用协议抽象数据源，让ViewModel和View解耦。但滥用协议会让代码跳转像走迷宫，一个方法实现要找五六个文件。

该吐槽的必须吐槽

版本兼容性是最大的坑。Swift 3到4的迁移让多少项目痛不欲生，Swift 5好不容易稳定，Swift 6又开始搞严格并发。去年我们组升级Xcode 16，Swift 6模式下编译错误直接翻倍，Sendable检查把之前“能用就行”的代码全部打回原形。

还有Xcode本身。代码补全和重构功能，连JetBrains的AppCode都比不上，更别提每次大版本更新必出的索引卡死问题。

那Rust来凑什么热闹？

iOS开发已经过了纯UI时代。现在做iOS大概率要碰底层——音视频处理、图片编解码、性能敏感的计算模块。Rust在内存安全上的设计（所有权、借用检查器）让它做底层库时既有C++的性能，又不会动不动野指针崩溃。

我们团队去年做了一个图片处理模块，最开始用Swift写，处理大图时内存峰值飙到800MB，低端机上直接被杀。后来用Rust重写核心算法，通过FFI暴露给Swift调用，内存峰值降到了200MB以内。合适的工具做合适的事：Swift负责UI和业务逻辑，Rust负责性能敏感的核心模块，这个组合在业界已经越来越常见。

学Rust不是让你转行，而是让你理解内存管理的底层逻辑。Rust的借用检查器会逼你搞清楚每一块内存谁拥有、谁借用、生命周期多长。这套思维反过来写Swift时，你对ARC、闭包捕获列表、循环引用的理解会上一个台阶。

Adobe Firefly和iOS开发有什么关系？

关系不大。但Adobe Firefly代表了一个趋势：越来越多重复性的、模板化的工作会被AI吃掉。UI切图、占位图、App图标变体这些活儿，现在用Firefly输入“生成一个iOS App图标，扁平风格，蓝色渐变”，几秒钟出来四个方案。对独立开发者尤其友好。

但AI生成的是“看起来像”的东西，真正能跑起来、不崩、体验流畅的App，还是需要人去理解业务、设计架构、处理边界情况。语言只是工具，解决问题的能力才是不可替代的。

写在最后

每次技术焦虑上头的时候，我就告诉自己：别慌，把基础打牢，把一门语言学透，再横向扩展。Swift的值类型、可选值、协议、闭包、内存管理——这些东西吃透了，学Rust只是换个语法而已，核心的编程思维是相通的。

如果你正在学iOS开发，别急着追热点。老老实实把Swift基础过一遍，写几个能上架的App。等你在项目里被值类型坑过、被闭包循环引用坑过，再回头看这些基础知识，你会觉得它们不是枯燥的语法，而是救命的东西。

技术的世界永远在变，但底层逻辑不变。与其焦虑Rust会不会取代Swift，不如想想怎么用Rust把Swift写得更稳。