其实到现在为止 Swift 离替代 Objective-C 还是很遥远，因为 Apple 内部一直在用 Objective-C 来做一些 Framework 的开发，低层也不可能用 Swift 实现
— Cyan
目前苹果的框架, 底层实现都是使用 C , 然后再套上一层 Objective-C 去暴露外部接口. 这种方式既保证了性能, 又能保证 API 的易用性.
而且苹果使用了大量的开源框架, 系统底层很多模块, 都已经有了开源的基于 C 语言的框架实现, 跟 C 的交互上, Swift 明显不如 Objective-C 那么方便
Swift 目前的问题
代码稳定, 其实都是小事情, 迁移, 几十万行代码, 分配给所有人, 最多也就是一个星期的事情. Swift 的开发者都很积极, 主流的第三方框架基本上两个星期内都能更新到最新的版本, 我用的库 75% 都从 beta 时期就开始跟进 Swift 的更新.
Swift 3 最大的问题我觉得还是工具链不稳定
增量编译做的不好. 编译随时 Segment Fault, 必须 clean 一次才行.
超长的编译时间. 每次编译出错, clean 之后可能需要编译七八分钟, 之前我记得还有人总结了一份什么样的语法会导致编译时间变长的列表, 为了编译时间缩短而却强行改变代码应有的样子, 我觉得很不值得.
我采用的解决方式就是把底层模块抽出来, 独立成一个框架, 使用 Carthage 去进行包管理, 全部编译成静态库, debug 编译的时候, 只要链接上去就行了, 大大减少编译时间, 而且由于判断增量编译的工作量减少了, 索引速度也会大大提高, 代码补齐跟代码高亮会工作地更好一点. (顺带一说, Carthage 是用 Swift 写的)
代码高亮随时崩, 代码补齐几乎没有. Xcode 很容易变白板, 我个人而言发生情况不多, 一天能遇上个两三次左右, 但是代码补齐就真心是完全没有, 每天基本上都是盲打, 只有像是 UICollectionElementKindSectionFooter 这种才会等等代码补齐. (补充一下, AppCode EAP 对于 Swift 3的支持异常的好, 补齐跟高亮都能够很好地满足日常需求, 我的 Air 8g 内存就能跑的很好)
