这是一个问题，我已经错过了一段时间，但它达到了一个点，现在勉强可用。
我的项目开始有一个体面的大小65 Swift文件和一些桥接的Objective-C文件(这真的不是问题的原因)。
它似乎像对任何Swift文件的任何轻微的修改(如在类中添加一个简单的空白，在应用程序中几乎不使用)将导致重新编译指定的目标的整个Swift文件。
经过深入调查，我发现编译器时间的几乎100％是CompileSwift阶段，其中Xcode在目标的所有Swift文件上运行swiftc命令。
我做了一些进一步的调查，如果我只保留应用程序委托与一个默认控制器编译是非常快，但随着我添加越来越多的我的项目文件，编译时间开始变得非常慢。
现在只有65个源文件，每次编译大约需要8/10秒。不是很迅速。
我没有看到任何帖子谈论这个问题，除了this one，但它是一个旧版本的Xcode 6.所以我想知道如果我是唯一的那种情况下。
更新
我已经检查了一些像Alamofire，Euler和CryptoSwift的GitHub的Swift项目，但没有一个有足够的Swift文件来进行比较。唯一的项目我发现，开始一个体面的大小是SwiftHN，即使它只有十几个源文件，我仍然能够验证同样的事情，一个简单的空间和整个项目需要重新编译，开始采取少时间(2/3秒)。
相比Objective-C代码，分析器和编译都很快，这真的感觉像Swift将永远不能处理大项目，但请告诉我错了。
更新与Xcode 6 Beta 7
仍然没有任何改善。这开始变得可笑。由于缺少#import在Swift，我真的不知道苹果将如何能够优化这。
更新与Xcode 6.3和Swift 1.2
苹果已经添加了incremental builds(和许多其他编译器优化)。您必须将代码迁移到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的更改，这将是OK)，但也是FileC，因为FileB被重新编译，这是相当糟糕，因为FileC从不使用FileA在这里。
所以我希望他们改进依赖树解算器…我已经打开一个radar与这个示例代码。
更新与Xcode 7 beta 5和Swift 2.0
昨天苹果发布了beta 5和内部的发行说明，我们可以看到：
Swift Language & Compiler
• Incremental builds: changing just the body of a function should no longer cause dependent files to be rebuilt. (15352929)
我已经试过，我必须说，它是真的(真的！)现在好了。他们大大优化了swift中的增量构建。
我强烈建议你创建一个swift2.0分支，并保持你的代码更新使用XCode 7 beta 5.你会很高兴的编译器的增强(但我会说，XCode 7的全局状态仍然很慢&婴儿车)
更新与Xcode 8.2
这是已经有一段时间，因为我上次更新这个问题，所以这里是。
我们的应用程序现在约20k行几乎完全Swift代码，这是体面，但不突出。它进行了swift 2和swift 3迁移。它需要大约5 / 6m编译在2014年中期Macbook pro(2.5 GHz Intel Core i7)，这是一个干净的构建是好的。
然而，增量构建仍然是一个笑话，尽管苹果声称：
Xcode will not rebuild an entire target when only small changes have occurred. (28892475)
显然，我认为我们很多人只是笑了，检查出这个废话(添加一个私人(私人！)属性到我的项目的任何文件将重新编译整个事情…)
我想指出你们this thread在苹果开发者论坛，它有一些更多的信息关于这个问题(以及赞赏苹果开发沟通一段时间)
基本上人们已经想出了一些东西来尝试改进增量构建：
>将HEADER_MAP_USES_VFS项目设置添加为true
>禁用从您的方案中查找隐式依赖项
>创建一个新项目并将您的文件层次结构移动到新的项目。
在这个整体情况下，讽刺的滑稽是，看看第一篇关于这个问题，我们使用Xcode 6，我相信swift 1或swift 1.1代码，当我们达到第一个编译迟缓，现在大约两年后，尽管实际改进从苹果情况与Xcode 6一样糟糕。多讽刺。
我真的很遗憾选择Swift over Obj / C为我们的项目，因为它涉及每天的沮丧。 (我甚至切换到AppCode，但这是另一个故事)
无论如何，我看到这篇文章有32k的意见和143 ups的写作，所以我想我不是唯一的。挂在那里的家伙尽管对这种情况悲观，可能有一些光在隧道尽头。
如果你有时间(和勇气！)我猜苹果欢迎雷达。
下一次！干杯
现在不要误会我。 Swift每次都会重新编译所有文件，但是现在的伟大之处在于，Apple对其编译的文件添加了实时编译反馈，因此Xcode 6 GM现在可以显示正在编译的Swift文件以及实时编译的状态你可以看到在这个屏幕截图：
所以这很方便地知道你的文件是这么长时间。在我的case是这段代码：
var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
"url" : self.url?.absoluteString ?? "","title" : self.title ?? ""
])
return dic.copy() as NSDictionary
因为属性标题的类型是var title：String？而不是NSString。编译器在将其添加到NSMutableDictionary时会疯狂。
将其更改为：
var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
"url" : self.url?.absoluteString ?? "","title" : NSString(string: self.title ?? "")
])
return dic.copy() as NSDictionary
使编译从10/15秒(也许更多)下降到一秒钟…惊人。
