ReactiveCocoa 5: the beginning may be a most painful upgrade

RAC 5 has changed dramatically compared to 4, not only by the impact of the 3 major swift upgrades, but RAC has also dramatically adjusted its own project structure. This adjustment is to split RAC into four libraries: ReactiveCocoa, ReactiveSwift, ReactiveObjC, and ReactiveObjCBridge.


RAC’s attention now focuses on the Swift and UI layers, merging the original extension library Rex, which is based on the RAC oriented UI layer, into the RAC.

The main effort of RAC 3 and 4 is to recreate a responsive programming library around Swift. Because this part of the core API is already mature, it’s now focused on providing some of the better extensions for AppKit and UIKit.


In fact, the core code associated with the Swift platform in RAC was extracted separately into a new framework: ReactiveSwift.

Swift is growing fast and growing into a cross platform language. After extracting only code related to Swift, ReactiveSwift can be used on other platforms, not just in CocoaTouch and Cocoa.


In RAC 3 and 4, RAC also contains the OC code in RAC 2. Now this part of the code is moved to ReactiveObjC.

The reason for this is that the two libraries, though having the same core programming paradigm, are actually completely independent of the two sets of API. In actual use, RAC 4 and RAC 2 are completely different groups of two users, and the maintenance team is actually the two group. Mixing in a library before also adds to the complexity of the management. After splitting, you can also maintain ReactiveObjC more freely.


After splitting the libraries of Swift and OC, the problem is that not all libraries are pure OC and Swift. A large portion of the project is in the process of migrating OC to Swift, where Swift may be called in RAC 2, based on OC written in API. In order to solve this part of the user’s problems, so with ReactiveObjCBridge.

What are you going to introduce in the project now?

If you’re just a pure swift project, you continue using ReactiveCocoa. But RAC relies on ReactiveSwift, which means you’re introducing two libraries.

If your project is a pure OC project, you need to use ReactiveObjC. This library contains all of the original RAC 2 code.

If your project is swift and OC mixed, you need to quote ReactiveCocoa and ReactiveObjCBridge. But ReactiveObjCBridge relies on ReactiveObjC, so you’re introducing 4 libraries.

API renamed

This part of it gives me the feeling of breathing pain. Many API needs to be searched again, and the naming has changed.

One direction is reference, and RxSwift takes the namespace of reactive. Such as:

Let appearing view.reactive.trigger (for: = #selector (viewWillAppear (_:)) = object.reactive.values (let) producer forKeyPath: #keyPath (key))

API is all behind reactive. No longer the original rac_xx.

Some of the attributes associated with UI have also been named and may be affected by rex. Such as:

The original is rac_text viewModel.searchString / / < button.reactive.pressed = textField.reactive.textValues ~ CocoaAction (viewModel.commit)

The property of the life cycle lifetime is also added. Such as:

Signal.take (during:, object.reactive.lifetime)

When the object is recycled, the signal stops taking value.


Let us live with smile.

ReactiveCocoa 5: the beginning may be a most painful upgrade

Welcome to my micro-blog: @ no tales of Zhuo classmates

Related links:
, RAC, change, log