从 Instagram 开源 IGListKit 聊聊 iOS 开发趋势

最早知道 IGListKit 这个库是在 try! Swift NYC 这个会议上,这是由 Instagram 开发的应用在自身 App 上的一个 UI 组件库。

当时 Twitter 上的 @janlay 还提了一个问题:「话说都 Swift 写了,为啥还要带 IG 前缀…」今天这个库正式开源,一些问题也将得到解答,我想也趁这个机会聊聊我所了解的当下的 iOS 开发趋势。

首先,IGListKit 并不是由 Swift 开发的一个库,它依然使用了 Objective-C 为主要语言开发。我想是因为 Instagram 作为已经五年以上的 App,也就是一定是一个 Objective-C 项目。它运作良好,没有特殊原因没必要用 Swift 重写。所以它的核心 UI 组件库 IGListKit 依然是 Objective-C 也是正常的。

其次,尽管 IGListKit 不是 Swift 写的,但是你不得不忽视 Swift 在这个库中的存在感,列举一二:

  • IGListKit 对 Swift 项目提供完整支持,简单来说,nullable/nonnull、genercis 的采用会让你用它时感受不到背后是 Objective-C 还是 Swift 在提供支持;
  • IGListKit 的 demo 是 100% Swift 写的;
  • IGListKit 的文档的示例代码也是 100% Swift 代码。

综上所述,IGListKit 是一个很典型的使用 Objective-C 开发的,但却是个偏向使用 Swift 语言开发者的一个 UI 组件库。首页示例代码都不提供 Objective-C 版本,这不是要阻挡依然使用它作为主要语言的开发者吗?

所以结合在 try! Swift 这个大会上 Instagram 来介绍这个库这件事情,我想一些 iOS 开发趋势就可以由此可见了。

首先,不管开源库是基于 Objective-C 还是 Swift 实现的,如果你想要你的库让越来越多正在使用 Swift 语言的开发者也能使用的话,无论是代码层面还是文档存层面,对 Swift 语言做调整并适配将成为必要动作。

其次是我在之前就观察到过一个现象,一个用 Objective-C 写的库可以同时用在 Objective-C 和 Swift 项目上,而一个 Swift 写的库却不一定能用在 Objective-C 项目上。所以如果你想要你的库被更多的人使用,建议还是基于 Objective-C 来实现。当然这里有个重点不要搞错,你的库是优先考虑自己的项目,其次再考虑开源给外界用的。

然而现实是,我正看到越来越多 Swift Only 的库诞生(包括一些不是用在 iOS 上的 Web 相关的库),这些库的作者从一开始就不会考虑去让 Objective-C 的项目用,它们没有这个历史包袱,甚至没有平台包袱(可以用在 macOS、Linux 上),所以 Swift 这个社区正在进行各种有意思的演化。而相比之下,Objective-C 目前只能用在 Apple 生态圈里做客户端开发,想要被重视就得像 IGListKit 一样对 Swift 进行适配。真是完全不同的风格了。

最后我想说,在可以预见的长期 Objective-C 和 Swift 生态圈共存共荣的情况下,后者的上升趋势以及跳出 Apple 产品生态圈的变化是已经实实在在发生的了。写这篇文章就是通过自己的观察和分析,给大家做一个参考了。

对了,还有 Stack Overflow 的 Developer Survey Results 2016 调查也出来了,Swift 排名第二的被 Most Loved 的语言(排名第一是 Rust)。所以受关注程度还是挺高的。

作为一个使用 Swift 已经第三年的开发者,我想等明年 Swift 4.0 出来的时候再写一篇观察和分析,一定会有更多变化了吧🤔

欢迎使用图拉鼎和他的团队开发的作品

效率控 - 聚合众多实用小工具

装机必备的高颜值工具箱,拥有超过 18 款工具,完成日常各类任务。支持 iPhone、iPad 和 macOS。

1 Comment

『它运作良好,没有特殊原因没必要用 Swift 重写』,这句话听起来真棒

Leave a Comment