app开发已经成为移动互联网时代的标配，ios平台的app开发有两种开发语言可以选择，Swift和Objective-C，往往在决定是否将Objective-C或Swift用于项目并不总是一个明确的决定; 每次开始新项目时都要考虑许多因素。我们决定解决这个问题，因为这是我们从开发人员那里听到的最常见问题之一。选择最合适的语言取决于项目和团队环境，以及对特定编程语言的偏好和偏好。

我们不是挥舞我们的Objective-C或Swift标志，而是查看项目的所有方面，这些方面指向一种语言，而不是项目范围和规模，团队组成和技术考虑因素。本文甚至深入研究是否要为正在进行的项目切换语言。在您阅读时，请记住，没有任何一个点可以支配决策。只有在权衡了以下因素后才能做出决定，因为它们适用于您正在进行的工作。

您对Objective-C vs Swift的体验

首先要考虑的是您目前使用Objective-C和Swift的经验。如果您对两种编程语言都有相同的经验，那么语言选择取决于我们在下面解决的因素组合，如第三方库兼容性，API支持，团队组成等。

相反，如果您有使用一种语言而不是另一种语言的经验，则倾向于选择熟悉的语言，除非某些项目或团队要求否决了该语言。使用您最不熟悉的语言创建生产应用程序将使您有机会了解有关该语言的更多信息，它很有可能积累大量技术债务并延迟应用程序的进度。您可能会发现自己处于像在沙滩上建造房屋的情况，没有任何重组可以挽救它。换句话说，最初的技术债务可能让您别无选择，只能从头开始重写应用程序。

另一方面，如果您决定创建生产应用程序的原型，请使用最陌生的语言。这种方法让您有机会熟悉新语言。它也将有益于生产应用程序，因为从那时你将从两个洞察角度接近你的应用程序，它的功能和挑战。

应用项目时间表，范围和比例

首先检查项目的具体要求和约束。您的经验，团队的构成以及项目的规模将帮助您倾向于使用一种语言而不是另一种语言。

应用程序时间表

与我们上面提到的类似，用不熟悉的语言编写生产应用程序会产生巨额技术债务的风险。这笔技术债务是按时付出的。如果你有一个积极的时间表，你应该倾向于你有更多经验的语言。如果你没有更多的经验，请倾向于Swift（稍后会详细介绍）。

如果你有一个软时间线和一些摆动空间，你应该考虑用最让你感到不舒服的语言写作（出于学习目的）。如果你偶然发现其中一个没有固定时间线的神话般的项目，你一定要选择让你最不舒服的语言。没有设定时间表的项目是我们职业生涯中不会经常出现的奢侈品，利用这种奢侈品来提升我们的游戏水平是一个好主意。

团队组成

这是一个在更多技术问题上可以忽略的主题，但不应该。在做出任何语言决定之前，您需要与您的团队进行交流 - 即使您在自己的代码库孤立区域工作也是如此。确保在您将其应用于自己之后重新审视适用于您的团队的所有要点。

例如，您是否在拥有大量具有多年经验的敏锐Objective-C开发人员的公司工作？在Swift中开始写作直到它们都在它上面并不是一个好主意。即使你觉得你有充分的理由而且你的论据都是基于本文中的所有内容，你也不应该按自己的方式行事。团队摩擦可能带来灾难性的后果，最终没有人获胜。只要你倾听你的团队成员并采用民主的方法来决策过程，你就可以了。

项目规模

小项目有权选择最合适的语言，因为转换Swift代码的开销变化很小。另一方面，大型项目需要对采用Swift非常谨慎。Swift是不成熟的，每个新版本（甚至是次要版本）都可能需要繁忙的工作来转换为新的语法和习语。每次推出新的Swift版本时，没有人希望看到构建中断几天到一周。或者更糟糕的是，作为开发人员必须解释为什么它被破坏了管理层或类似的利益相关者。

Xcode为我们提供了将Swift x代码转换为Swift x + 1的工具。然而，这些工具并不能捕捉到一切。这并不是对Xcode团队在转换工具中付出的辛勤工作的抨击。在不知道代码背后的上下文的情况下，某些语言更改无法自动转换。

Objective-C和Swift之间选择的技术考虑

Objective-C和Swift适用于不同的技术优势。以下是在检查应用范围和团队组成后应考虑的因素。

工具支持

Xcode团队在升级构建过程以支持Swift方面做得非常出色。他们必须处理实现复杂语言并支持使用非常不同的语言（Objective-C）。IDE本身滞后并且Swift的工具支持很少，这一点也不足为奇。有时你很幸运能得到语法高亮。通常你会没有自动完成。并且重构工具变得无效。如果您是喜欢现代IDE提供的强大支持的人，您应该考虑坚持使用Objective-C或评估替代IDE。AppCode是常见的替代方案，但肯定有人拥有完美的设置emacs和/或vim.

语言运行时

Objective-C运行时比Swift运行时更健壮。Swift的运行时并不接近追赶Objective-C，而且可能在未来几年都不会。如果您计划编写将受益于对象和类型的反射和深度内省的代码（通常保留给强大的SDK，但有时在常规应用程序中找到），Objective-C是一个明智的选择。如果你不知道最后一句话意味着什么，那么你很可能会接受斯威夫特。

代码稳定性

由于其强大的打字系统和错误处理，Swift是一种安全的编程语言。如果您遵循惯用的Swift并避免使用!代码中的运算符，则可以或多或少地保证您的代码可以解决所有潜在的错误情况。这并不意味着它能抓住一切。保留周期中的内存泄漏是Swift代码中与Objective-C同样普遍存在的错误的一个示例。这是因为Swift的自动参考计数系统没有变化。

使用FOUNDATION API

如果您计划制作的应用程序主要使用基础API（一些示例是CoreFoundation，AVFoundation和CoreAnimation），您应该倾向于Objective-C。Swift提供了一些不错的包装器，使内存管理更加顺畅，但这些仍然是C API和基于C的函数调用，它们更自然地适合于Objective-C代码库。

使用C ++代码

与Foundation API类似，使用C ++库或构建在跨平台C ++ SDK之上将适用于Objective-C项目。您无法将C ++导入Swift文件。要使用Swift，您必须完成制作Objective-C或Objective-C ++包装类的繁琐且经常出错的任务。每次要使用C ++库的其他部分时，这都需要桥接和额外开销。如果您打算使用C ++，Objective-C更适合。

操作系统版本

Swift可在iOS 7 +，Mac OS 10.9+以及所有版本的tvOS和watchOS上运行。如果项目需要支持以下任何内容，那么您别无选择，只能使用Objective-C。

面向未来

最具前瞻性的项目是用Swift编写的。在过去两年中，Swift的使用已经扩展到所有开源Cocoa项目的三分之一。在接下来的四年中，按照这个速度，它将等于Objective-C。此外，大多数新教程和博客都是用Swift编写的。我们相信在5到10年内，Swift上应该有足够的信息来否定理解Objective-C的必要性。也就是说，在Objective-C消失之前，您将有足够的时间来转换代码，因此请将其作为思考的食物。

您是否应该为现有的Objective-C项目切换到Swift？

在我们回答这个问题之前，了解在单个项目中同时使用Swift和Objective-C意味着什么很重要。这个概念称为“桥接”。当您将Swift文件添加到Objective-C项目时，Xcode将为您创建一个“桥接头文件”。这与您的常规Objective-C标头没有什么不同，除了您只使用它来导入要向Swift代码公开的Objective-C标头。Xcode自动创建一个标头，将所有Swift代码桥接到Objective-C。您可以通过在要使用Swift代码的Objective-C文件中添加ModuleName-Swift.h一行（例如，Mail-Swift.h如果您正在处理名为Mail的项目）来使用它。

接下来要考虑的是项目的规模。一个大型项目不适合桥接，因为Objective-C代码具有泄漏的抽象，使我们的Swift代码不那么惯用。例如，如果您有一个扩展协议以便NSObjectProtocol在实现协议的对象上使用Objective-C运行时，那么实现该协议的Swift类将必须继承层次结构NSObject中的某个类或其他类NSObject。这不是理想的，因为支持Objective-C运行时会导致方法调用的性能损失四倍（因为它使用动态调度而不是静态）。一个小项目可以比大项目更平滑地混合和匹配Objective-C代码。但是，根据我们的经验，您最终希望将剩余的代码转换为Swift，一个小项目最终会得到您希望转换为Swift的Objective-C代码的待办事项列表。

其他考虑因素包括团队组成和项目紧迫性。如前所述，如果您在团队环境中工作，那么在添加将Objective-C项目桥接到Swift的复杂性之前，应达成共识。如果你在没有团队买入的情况下开始编写Swift，那么你将被标记为牛仔编码器，可能很快就会开始寻找新的工作。此外，桥接代码是一种痛苦，并且需要比您想象的更多的开销。如果项目紧急或期限不灵活，请倾向于Objective-C。否则，考虑上面的谈话要点，考虑在Swift中启动新代码。

结论说明

这些是开发人员在为新的和现有的应用程序项目决定Objective-C和Swift时需要解决的更常见的因素。您的项目可能包含大量应用通常不会遇到的其他注意事项。请记住，选择编程语言时最重要的操作是检查项目上下文并与团队成员讨论决策。与其他开发人员一起接受这两种语言的优缺点和头脑风暴选项将有助于您在重要时做出正确的呼叫。