什么时候是采用Swift 3的正确时间？

自苹果推出Swift以来已经两年了。

在最初的12个月中，我很犹豫地推荐Swift作为一种实现语言。 实际上，我认为我的确切话是“不”。 在Swift大一的时候，这些工具不稳定，语言和库还很不成熟。

但是，在过去的12个月中，语言在不断发展壮大。 苹果公司开源了Swift，并通过Swift.org向更广泛的社区开放了该语言的发展。

这鼓励了社区通过Swift Evolution流程对Swift做出的巨大贡献，而即将发布的Swift 3也从这些努力中取得了成果。 Swift 3带来了该语言在其短生命周期中所看到的最重大的变化。

Swift 3和“伟大的重命名”

Swift 3带来的最重大更改可能是“ The Great Renaming”。

去年这一年，Swift Evolution Process提出了许多建议，以澄清和标准化Swift标准库的命名方案，以及Swift如何导入Apple现有的框架（如Foundation，UIKit和Core Graphics）。 这产生了“ Swift API设计指南”。

这个新的命名标准意味着在使用这些框架时，Swift 3将与Swift 2完全不同。 随着向Swift 3的迁移，几乎所有现有的Swift代码都将需要迁移到新的命名标准并遵循这些准则。

Xcode 8包含一个迁移工具来帮助完成此过渡。 工具很棒，但是就像大多数工具一样，它可以节省您的工作，而不是从过程中消除所有想法。 我认为，所有Swift应用程序代码仍将需要由人工迁移来审核和审查。 此外，迁移工具无法帮助您将现有的应用程序代码转换为新的API准则。 它仅解决您的代码如何与Apple框架交互以及该API的更改方式。

Swift 3和ABI稳定性

Swift 3的目标之一是ABI稳定性。 这没有发生。 这意味着为了将项目升级到Swift 3，该项目的所有Swift依赖项也都需要更新到Swift3。不可能将Swift 3应用程序与Swift 2库链接。

在接下来的12个月中的某个时候，Sw​​ift 3很有可能达到ABI的稳定性，而在今年的WWDC上，克里斯·拉特纳（Chris Lattner）表示，在考虑日后对语言的更改时，保持源代码兼容性将是一个强大的约束。 因此，希望明年不再需要“ Great Renaming 2”。

何时切换到Swift 3？

团队现在应该开始为此进行计划。 根据现有Swift代码库的规模，此迁移可能会对项目产生重大影响。 在主应用程序可以采用Swift 3之前，所有项目的依赖项也都需要采用Swift3。采用Swift 3并迁移到新的API指南的库可能会因此改变自己的API。 这意味着需要更改应用程序中库代码的许多用法。 Xcode 8迁移工具无法解决这些问题。

为了简化Swift 3的采用，开发人员应该熟悉新的API设计指南，并从今天开始在新代码中采用它们。

如果您已经有一个Objective-C代码库，并且还没有开始采用Swift，那么您可能要等到今年晚些时候发布第3版之后再采用Swift。 与在后期采用Swift 2.x之后再经历迁移过程相比，这将使您处于更好的位置。

现在，在预览/测试版中采用Swift 3将会是一个痛苦的过程，因为还没有足够的第三方库代码。 尽管在Xcode 8和iOS 10 Beta期间这可能会迅速改变。

幸运的是，对于希望采用缓慢而稳定的方法来迅速采用Swift 3的开发人员，Apple已在Xcode 8中引入了功能，以允许开发人员在iOS 10发行版之后继续使用Swift2。Xcode8同时支持Swift 2.3和3。您不能将它们混合在一个应用程序中，但是可以继续使用2.3，直到您的项目和团队方便地将其切换到3。

Swift是可可发展的未来吗？

简短的回答：是的。

我一直认为，采用Swift的转折点将是苹果自己开始引入仅是Swift的框架时。 尽管苹果还没有走得那么远，但他们开始将仅Swift的功能引入所有基础构建的基础框架中。 可以使用这些框架进行的更改对于Swift语言来说感觉更加原生。 这些新增功能以及苹果公司将iOS的Swift Playgrounds作为一种教育辅助手段的推出，说明了苹果致力于进一步推动Swift的未来。

可能要经过很多年，Objective-C才最终屈服并退出Cocoa开发舞台，但总的来说，我认为Swift的优势正在迅速显现。 如果您还没有加入Swift潮流，那么即将进行的向Swift 3的过渡可能会提供这样做的正确机会。

Itty Bitty Apps 总部位于澳大利亚墨尔本， 为大小客户提供了出色的移动和Mac软件。 这也使 揭示   -适用于iOS开发人员的功能强大的运行时视图调试。