Streams of values over time. Tailored for Swift.
☕️ Looking for Cocoa extensions?
🎉 Getting Started
ReactiveSwift offers composable, declarative and flexible primitives that are built around the grand concept of streams of values over time.
These primitives can be used to uniformly represent common Cocoa and generic programming patterns that are fundamentally an act of observation, e.g. delegate pattern, callback closures, notifications, control actions, responder chain events, futures/promises and key-value observing (KVO).
Because all of these different mechanisms can be represented in the same way, it’s easy to declaratively compose them together, with less spaghetti code and state to bridge the gap.
-
An overview of the semantics and example use cases of the ReactiveSwift primitives, including
Signal
,SignalProducer
,Property
andAction
. -
An overview of the operators provided to compose and transform streams of values.
-
How does ReactiveSwift relate to RxSwift?
An overview of how ReactiveSwift differs from RxSwift for Swift idiomaticity.
-
Interactive Form UI
ReactiveSwift includes a UI Examples playground, which demonstrates:
- how to build an interactive form UI with bindings, properties and
Action
s, with a live view in action. - how to use reactive primitives to implement the Model-View-ViewModel architectural pattern, with the View Model being the source of truth for the View.
- how to build an interactive form UI with bindings, properties and
-
Bindings and reactive extensions for Cocoa and Cocoa Touch frameworks are offered separately as ReactiveCocoa.
-
Contracts of the ReactiveSwift primitives, Best Practices with ReactiveSwift, and Guidelines on implementing custom operators.
ReactiveSwift supports macOS 10.9+, iOS 8.0+, watchOS 2.0+, tvOS 9.0+ and Linux.
If you use Carthage to manage your dependencies, simply add
ReactiveSwift to your Cartfile
:
github "ReactiveCocoa/ReactiveSwift" ~> 1.1
If you use Carthage to build your dependencies, make sure you have added ReactiveSwift.framework
, and Result.framework
to the "Linked Frameworks and Libraries" section of your target, and have included them in your Carthage framework copying build phase.
If you use CocoaPods to manage your dependencies, simply add
ReactiveSwift to your Podfile
:
pod 'ReactiveSwift', '~> 1.1'
If you use Swift Package Manager, simply add ReactiveSwift as a dependency
of your package in Package.swift
:
.Package(url: "https://github.com/ReactiveCocoa/ReactiveSwift.git", majorVersion: 1)
- Add the ReactiveSwift repository as a submodule of your application’s repository.
- Run
git submodule update --init --recursive
from within the ReactiveCocoa folder. - Drag and drop
ReactiveSwift.xcodeproj
andCarthage/Checkouts/Result/Result.xcodeproj
into your application’s Xcode project or workspace. - On the “General” tab of your application target’s settings, add
ReactiveSwift.framework
, andResult.framework
to the “Embedded Binaries” section. - If your application target does not contain Swift code at all, you should also
set the
EMBEDDED_CONTENT_CONTAINS_SWIFT
build setting to “Yes”.
We also provide a great Playground, so you can get used to ReactiveCocoa's operators. In order to start using it:
- Clone the ReactiveSwift repository.
- Retrieve the project dependencies using one of the following terminal commands from the ReactiveSwift project root directory:
git submodule update --init --recursive
OR, if you have Carthage installedcarthage checkout
- Open
ReactiveSwift.xcworkspace
- Build
Result-Mac
scheme - Build
ReactiveSwift-macOS
scheme - Finally open the
ReactiveSwift.playground
- Choose
View > Show Debug Area
If you need any help, please visit our GitHub issues or Stack Overflow. Feel free to file an issue if you do not manage to find any solution from the archives.
It targets Swift 3.1. The estimated schedule is WWDC 2017.
The primary goal of ReactiveSwift 2.0 is to take advantage of concrete same-type requirements introduced in Swift 3.1. As a result:
- A few single-implementation protocols were removed; and
Signal
andSignalProducer
operators were moved from the protocols to the concrete types.
These changes are source breaking, but are automatically or trivially migratable.
ReactiveSwift 2.0 has continued the work in polishing the APIs, preparing for the eventual API freeze for library resilience.
While the development would be Swift 3.2 and Swift 4.0 aware, ReactiveSwift 2.0 would not declare official support until Swift 3.2 and Swift 4.0 launch.
The official release for Swift 3.2 and Swift 4.0 is expected to be a minor 2.x release with full API compatibility.
ReactiveSwift 3.0 is expected to declare library ABI stability as it adopts generics features arriving in a later Swift 4 release, e.g. conditional conformance. There is no ETA for now.