对我来说(xcode 6.1)，原因是我忘记采用我的子类协议。

例如，这是错误的:

protocol SomeProtocol { ... }
class A :NSObject, SomeProtocol {
...
}
class B : A {
...
}

这是可以的:

protocol SomeProtocol { ... }
class A : NSObject, SomeProtocol {
...
}
class B : A, SomeProtocol {
...
}

将部署目标更改为iOS 8.0对我来说很有效。我知道有人说将它移动到<=7.1可以工作，但这个问题似乎来自多个来源，所以这个替代方案可能可以工作。

在Xcode 6 Beta 3中，我每隔几秒钟就会遇到这个问题，甚至在全新的项目中，这个问题仍然存在。我将部署目标从8.0更改为7.1，它已经停止。

对我来说(xcode 6.1)，原因是我忘记采用我的子类协议。

例如，这是错误的:

protocol SomeProtocol { ... }
class A :NSObject, SomeProtocol {
...
}
class B : A {
...
}

这是可以的:

protocol SomeProtocol { ... }
class A : NSObject, SomeProtocol {
...
}
class B : A, SomeProtocol {
...
}

Swift试图动态地而不是静态地找出所有内容的类型，但当它处理复杂类型(如链式过滤器、映射、flatMap调用)或大型字典时，这可能需要付出巨大的努力。有时你需要把它们分开，以便编译器更容易分析。这个问题的一个表亲是“太复杂而不能及时评估”的错误。想象一下，有几个几乎太复杂而无法及时评估的项目:它们一起变成了资源占用者。

试着找到所有您创建动态字典或使用无类型调用链的地方。尝试更具体地输入，特别是在变量声明处。

一些简单的例子:

字典

Bad:

let myDict = [ /* bunch of different things */ ]

好:

let myDict: [String: AnyObject] = [ /* bunch of different things */ ] 

最好的:

let myDict: [String: SpecificType] = [ /* bunch of similar things */ ]

映射

Bad:

let filteredUserIds = users.filter({ user in user.enabled })
    .flatMap { user in user.name != nil ? return user.id : return nil }

好:

let filteredUserIds: [Int] = users.filter({ user in user.enabled })
    .flatMap { user in user.name != nil ? return user.id : return nil }

最好的:

let enabledUsers: [User] = users.filter { user in user.enabled } 
let filteredUserIds: [Int] = enabledUsers.flatMap { 
    user in user.name != nil ? return user.id : return nil 
}

好处还包括额外的检查代码，因为您总是会得到预期的类型或编译器错误。缺点是它开始看起来有点像Java。

当然，随着项目的发展，这个问题首先会积累起来。小型Swift项目总是很快。所以可能有很多工作要做。经验告诉我们哪些表达是复杂且耗时的。如果你能对这些事情进行基准测试，那就太好了。

我在苹果的开发者论坛上找到了一个解决方案(需要登录，所以我也会在这里解释)。

TLDR:不要在Objective-C中导入与@interface同名的@protocol到Swift桥接头。例如，Facebook SDK有一个名为“FBGraphObject”的协议和接口。

以下是论坛帖子:

Adding Facebook SDK causes SourceKitService to crash. If you want to use beta 3 and you need Facebook SDK, one work around that I found and is working for me is refactoring Facebook SDK's @protocol FBGraphObject and renaming it to something like @protocol FBGraphObjectProtocol as an @interface FBGraphObject also exists and apparently SourceKit doesn't like it. It sure is a temporary solution just to keep you functional and you'll have to use Cocoapods or otherwise build Facebook SDK yourself rather than using the framework library. For the time being, you'll need to make sure you don't have conflicting @protocol and @interface declarations and that includes 3rd party libraries you may be using. This cost me today, hope it helps! Posted by e.parto on July 10, 2014