Reactive Cocoa的灵感来自于功能反应性编程，但在过去几个月中，也被Reactive Extensions所启发。结果是一个框架，与Rx共享一些东西，但有来自FRP的名称。

首先要说的是，根据Conal’s definition的概念，RAC和RxSwift都不是功能响应编程实现。从这一点，一切都可以简化为每个框架如何处理副作用和一些其他组件。

让我们谈谈社区和元科技：

> RAC是一个3岁的项目，出生在Objective-C后来移植到Swift(与桥梁)为3.0版本，完全放弃对Objective-C正在进行的工作。
> RxSwift是一个几个月的项目，似乎在社区有一个势头。对RxSwift很重要的一件事是在ReactiveX组织下，所有其他实现以相同的方式工作，学习如何处理RxSwift将使Rx.Net，RxJava或RxJS工作是一个简单的任务，只是一个事的语法语法。我可以说是基于哲学学习一次，应用到处。

现在是技术的时候了。

生产/观察实体

RAC 3.0有两个主要实体，Signal和SignalProducer，第一个发布事件，而不管用户是否连接，第二个需要开始实际产生信号/事件。这个设计是为了分离热和冷观察的乏味概念，这是很多开发人员的混乱的根源。这就是为什么差异可以减少到如何管理副作用。

在RxSwift中，Signal和SignalProducer转换为Observable，它可能听起来很混乱，但这两个实体在Rx世界中实际上是相同的。在RxSwift中的Observables的设计必须考虑它们是热还是冷，它可以听起来像不必要的复杂性，但一旦你了解它们如何工作(再次热/冷/热只是关于副作用，而订阅/观察)他们可以驯服。

在这两个世界中，订阅的概念基本上是一样的，RAC引入的是一个小小的差别，并且是在完成事件发送之前布置信号时的中断事件。
重述两者有以下类型的事件：

>接下来，计算新的接收值
>错误，计算错误并完成流，取消订阅所有观察者
>完成，将流标记为已完成取消订阅所有观察者

RAC另外中断，当信号在正确完成或错误完成之前发送。

手写

在RAC中，Signal / SignalProducer是只读实体，它们不能从外部管理，同样的事情是在RxSwift中的Observable。要将Signal / SignalProducer转换为可写实体，必须使用pipe()函数返回手动控制的项目。在Rx空间中，这是一个不同的类型，称为主题。

如果读/写概念听起来不熟悉，可以做一个很好的类比与Future / Promise。 Future是一个只读的占位符，如Signal / SignalProducer和Observable，另一方面，Promise可以手动完成，例如pipe()和Subject。

调度程序

这个实体在两个世界中都是相似的，相同的概念，但RAC是仅限于串行的，而RxSwift的特性也是并发调度器。

组成

组合是反应式编程的关键特征。组合流是两个框架的本质，在RxSwift中，它们也称为序列。

RxSwift中的所有可观察实体都是ObservableType类型，因此我们使用相同的运算符组成Subject和Observable的实例，而不需要任何额外的关注。

在RAC空间上，Signal和SignalProducer是两个不同的实体，我们必须在SignalProducer上解除，以便能够组合使用Signal实例生成的内容。这两个实体有自己的操作符，所以当你需要混合的东西，你必须确保某个运算符可用，在另一边你忘记了热/冷观察。

关于这部分，Colin Eberhardt总结得很好：

Looking at the current API the signal operations are mainly focussed on the ‘next’ event,allowing you to transform values,skip,delay,combine and observe on different threads. Whereas the signal producer API is mostly concerned with the signal lifecycle events (completed,error),with operations including then,flatMap,takeUntil and catch.

额外

RAC也有Action和Property的概念，前者是一种计算副作用的类型，主要与用户交互相关，后者在值改变时观察值以执行任务时很有趣。在RxSwift中，Action再次转换为Observable，这在RxCocoa中很好地显示，RxCocoa是针对iOS和Mac的Rx基元的集成。 RAC的属性可以在RxSwift中转换为Variable(或BehavIoUrSubject)。

重要的是要了解属性/变量是我们必须将命令式世界桥接到反应式编程的声明性本质的方式，因此有时是处理第三方库或iOS / Mac空间的核心功能时的一个基本组件。

结论

RAC和RxSwift是两个完全不同的野兽，前者在Cocoa空间有很长的历史，很多贡献者，后者是相当年轻，但依靠已经证明在其他语言如Java，JS或其他语言有效的概念， 。净。更好的决定是偏好。 RAC声称，热/冷可观察的分离是必要的，这是框架的核心特征，RxSwift称，它们的统一比分离更好，同样只是关于如何管理/执行副作用。

RAC 3.0似乎在分离热/冷可观测量的主要目标之上引入了一些意想不到的复杂性，比如中断的概念，在两个实体之间分割运算符，并引入一些命令性行为，例如开始产生信号。对于有些人来说，这些东西可能是一个很好的事情，甚至一个杀手的功能，对于一些其他人，他们可以是只是不必要或甚至危险。另一个要记住的是，RAC正试图尽可能跟上Cocoa约定，所以如果你是一个经验丰富的Cocoa Dev，你应该感到更舒适的工作，而不是RxSwift。

另一方面，RxSwift与所有的缺点像热/冷可观测，但也是好的东西，反应的扩展。从RxJS，RxJava或Rx.Net到RxSwift是一个简单的事情，所有的概念都是一样的，所以这使得材料很有趣，也许是你现在面临的同样的问题，已经解决了RxJava的人和解决方案可以重新应用考虑到平台。

哪一个必须被挑选绝对是一个偏好的问题，从客观的角度来看是不可能告诉哪一个更好。唯一的方法是发射Xcode，并尝试两个他们，并选择一个感觉更舒适的工作。它们是类似概念的2个实现，试图实现相同的目标：简化软件开发。