我正在使用Xcode 6 Beta 6。
这已经困扰了我一段时间，但是现在已经到了几乎无法使用的地步。
我的项目已经开始有一个体面的65个斯威夫特文件的大小和几个桥接Objective-C的文件（这是真的不是问题的原因）。
似乎对任何Swift文件进行任何微小的修改（例如在应用中几乎没有使用的类中添加简单的空白）都会导致重新编译指定目标的整个Swift文件。
经过更深入的调查，我发现CompileSwiftXcode在swiftc目标的所有Swift文件上运行命令的阶段占了编译器时间的几乎100％。
我进行了进一步的研究，如果仅使用默认控制器保留应用程序委托，则编译速度非常快，但是随着我添加越来越多的项目文件，编译时间开始变得很慢。
现在只有65个源文件，每次编译大约需要8/10秒。一点也不快。
我还没有看到任何帖子谈到这个问题，除了这一个，但所以我想知道如果我在这种情况下，只有一个，这是一个旧版本的Xcode 6。
更新
我已经在GitHub上检查了一些Swift项目，例如Alamofire，Euler和CryptoSwift，但是它们都没有足够的Swift文件可以进行实际比较。我发现唯一一个启动时大小合适的项目是SwiftHN，即使它只有十几个源文件，我仍然能够验证同一件事，一个简单的空间，整个项目需要重新编译，这开始需要一个很少的时间（2/3秒）。
与分析器和编译速度都很快的Objective-C代码相比，这确实让Swift永远无法处理大型项目，但是请告诉我我错了。
Xcode 6 Beta 7更新
仍然没有任何改善。这开始变得荒谬。由于缺少#importSwift，我真的看不到苹果将如何进行优化。
使用Xcode 6.3和Swift 1.2进行更新
苹果增加了增量构建（以及许多其他编译器优化）。您必须将代码迁移到Swift 1.2才能看到这些好处，但是Apple在Xcode 6.3中添加了一个工具来帮助您做到这一点：
然而
不要像我那样高兴得太快。他们用来使构建增量的图形求解器尚未得到很好的优化。
的确，首先，它不关注函数签名的更改，因此，如果在一个方法的块中添加空格，则将重新编译所有依赖于该类的文件。
其次，它似乎基于重新编译的文件来创建树，即使更改不影响它们也是如此。例如，如果将这三个类移到不同的文件中
class FileA: NSObject {
var foo:String?
}
class FileB: NSObject {
var bar:FileA?
}
class FileC: NSObject {
var baz:FileB?
}现在，如果您进行修改FileA，则编译器显然会标记FileA为要重新编译。它还将重新编译FileB（根据对的更改，这将是可以的FileA），而且还FileC因为FileB重新编译了，这很糟糕，因为在此FileC从未使用FileA过。
因此，我希望他们能够改进依赖关系树求解器...我已经用此示例代码打开了雷达。
Xcode 7 beta 5和Swift 2.0更新
昨天，Apple发布了beta 5，在发布说明中我们可以看到：
Swift语言和编译器•增量构建：仅更改函数的主体将不再导致依赖文件的重建。（15352929）
我已经尝试过了，我必须说它现在确实（真的！）运行良好。他们迅速优化了增量构建。
我强烈建议您创建一个swift2.0分支，并使用XCode 7 beta 5使代码保持最新。您会对编译器的增强功能感到满意（但是我会说XCode 7的全局状态仍然很慢且有错误）。
Xcode 8.2更新
自从我最近一次更新此问题以来已经有一段时间了。
现在，我们的应用程序大约有2万行代码，几乎都是Swift代码，虽然不错，但并不出色。它经历了迅速的2迁移，而不是迅速的3迁移。在2014年中的Macbook pro（2.5 GHz Intel Core i7）上编译大约需要5 / 6m，这在干净的版本上还可以。
但是，尽管苹果声称：增量构建仍然是一个笑话：
仅发生很小的更改时，Xcode不会重建整个目标。（28892475）
显然，我认为我们很多人在检查了这个废话之后就笑了（向项目的任何文件添加一个私有（私有！）属性都会重新编译整个过程……）
我想指出你们在Apple开发者论坛上的这个线程，该线程上有关于此问题的更多信息（以及不时赞赏的Apple开发人员就此问题的交流）
基本上，人们想出了一些方法来尝试改进增量构建：
- 将
HEADER_MAP_USES_VFS项目设置添加到true - 禁用
Find implicit dependencies您的方案 - 创建一个新项目，然后将文件层次结构移至新项目。
我将尝试解决方案3，但解决方案1/2不适用于我们。
具有讽刺意味的是，在整个情况下，有趣的是，当我们遇到第一个编译缓慢问题时，尽管我们从Apple那里获得了实际的改进，但我看到Xcode 6使用的是Swift 1或Swift 1.1代码，而现在大约两年后，这种情况与Xcode 6一样糟糕。
其实，我真的很后悔选择了雨燕的OBJ / C为我们的项目，因为每天的挫折它涉及到的。（我什至改用AppCode，但这是另一个故事）
无论如何，在撰写本文时，我看到这篇SO帖子拥有32k +的视图和143个ups，所以我想我不是唯一的一个。尽管对这种情况感到悲观，但还是呆在那儿，隧道尽头可能有些亮光。
如果您有时间（并且有勇气！），我想苹果公司欢迎对此表示欢迎。
直到下一次！干杯
Xcode 9更新
今天偶然发现了这一点。Xcode悄悄地引入了一个新的构建系统，以改善当前的糟糕性能。您必须通过工作空间设置启用它。
请尝试一下，但完成后将对其进行更新。看起来很有希望。
