Reactive extensions to Cocoa frameworks, built on top of ReactiveSwift.

Overview

ReactiveCocoa

Reactive extensions to Cocoa frameworks, built on top of ReactiveSwift.

Join the ReactiveSwift Slack community.


Carthage compatible CocoaPods compatible SwiftPM compatible GitHub release Swift 5.1 platforms

⚠️ Looking for the Objective-C API?

🎉 Migrating from RAC 4.x?

🚄 Release Roadmap

What is ReactiveSwift?

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.

For more information about the core primitives, see ReactiveSwift.

What is ReactiveCocoa?

ReactiveCocoa wraps various aspects of Cocoa frameworks with the declarative ReactiveSwift primitives.

  1. UI Bindings

    UI components expose BindingTargets, which accept bindings from any kind of streams of values via the <~ operator.

    // Bind the `name` property of `person` to the text value of an `UILabel`.
    nameLabel.reactive.text <~ person.name

    Note: You'll need to import ReactiveSwift as well to make use of the <~ operator.

  2. Controls and User Interactions

    Interactive UI components expose Signals for control events and updates in the control value upon user interactions.

    A selected set of controls provide a convenience, expressive binding API for Actions.

    // Update `allowsCookies` whenever the toggle is flipped.
    preferences.allowsCookies <~ toggle.reactive.isOnValues
    
    // Compute live character counts from the continuous stream of user initiated
    // changes in the text.
    textField.reactive.continuousTextValues.map { $0.characters.count }
    
    // Trigger `commit` whenever the button is pressed.
    button.reactive.pressed = CocoaAction(viewModel.commit)
  3. Declarative Objective-C Dynamism

    Create signals that are sourced by intercepting Objective-C objects, e.g. method call interception and object deinitialization.

    // Notify after every time `viewWillAppear(_:)` is called.
    let appearing = viewController.reactive.trigger(for: #selector(UIViewController.viewWillAppear(_:)))
    
    // Observe the lifetime of `object`.
    object.reactive.lifetime.ended.observeCompleted(doCleanup)
  4. Expressive, Safe Key Path Observation

    Establish key-value observations in the form of SignalProducers and DynamicPropertys, and enjoy the inherited composability.

    // A producer that sends the current value of `keyPath`, followed by
    // subsequent changes.
    //
    // Terminate the KVO observation if the lifetime of `self` ends.
    let producer = object.reactive.producer(forKeyPath: #keyPath(key))
    	.take(during: self.reactive.lifetime)
    
    // A parameterized property that represents the supplied key path of the
    // wrapped object. It holds a weak reference to the wrapped object.
    let property = DynamicProperty<String>(object: person,
                                           keyPath: #keyPath(person.name))

But there are still more to be discovered and introduced. Read our in-code documentations and release notes to find out more.

Getting started

ReactiveCocoa supports macOS 10.9+, iOS 8.0+, watchOS 2.0+, and tvOS 9.0+.

Carthage

If you use Carthage to manage your dependencies, simply add ReactiveCocoa to your Cartfile:

10.1 ">
github "ReactiveCocoa/ReactiveCocoa" ~> 10.1

If you use Carthage to build your dependencies, make sure you have added ReactiveCocoa.framework and ReactiveSwift.framework to the "Linked Frameworks and Libraries" section of your target, and have included them in your Carthage framework copying build phase.

CocoaPods

If you use CocoaPods to manage your dependencies, simply add ReactiveCocoa to your Podfile:

pod 'ReactiveCocoa', '~> 10.1'

Swift Package Manager

If you use Swift Package Manager, simply add ReactiveCocoa as a dependency of your package in Package.swift:

.package(url: "https://github.com/ReactiveCocoa/ReactiveCocoa.git", branch: "master")

Git submodule

  1. Add the ReactiveCocoa repository as a submodule of your application’s repository.
  2. Run git submodule update --init --recursive from within the ReactiveCocoa folder.
  3. Drag and drop ReactiveCocoa.xcodeproj and Carthage/Checkouts/ReactiveSwift/ReactiveSwift.xcodeproj into your application’s Xcode project or workspace.
  4. On the “General” tab of your application target’s settings, add ReactiveCocoa.framework and ReactiveSwift.framework to the “Embedded Binaries” section.
  5. If your application target does not contain Swift code at all, you should also set the EMBEDDED_CONTENT_CONTAINS_SWIFT build setting to “Yes”.

Have a question?

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.

Release Roadmap

Current Stable Release:
GitHub release

In Development

Plan of Record

ABI stability release

ReactiveCocoa is expected to declare library ABI stability when Swift rolls out resilience support in Swift 5. Until then, ReactiveCocoa will incrementally adopt new language features.

Comments
  • Request - ReactiveCocoa chat room

    Request - ReactiveCocoa chat room

    Would like to be able to congregate with others using and learning ReactiveCocoa. Of course I could just join/create the channel on freenode if you guys don't want to do a sort of 'official' room.

    question 
    opened by bobspryn 120
  • Remove property subjects, refactor bindings

    Remove property subjects, refactor bindings

    This is a sweeping refactor of the property subject and binding code, to simultaneously solve a few different problems:

    1. Duplicated implementation logic
    2. Confusion about which side bindings go on, how many you need to create to do things, etc.
    3. ~~Confusion about how bindings don't echo values sent to them~~
    4. Complexity from supporting N-way bindings

    Still a huge work-in-progress, but I'd love feedback on the API. In particular, are the separate endpoint properties useful?

    @Coneko @andymatuschak

    opened by jspahrsummers 70
  • RACDC 2014

    RACDC 2014

    We're gonna host a day of ReactiveCocoa talks and Q&A at the GitHub office during WWDC week this year.

    The current plan is to do it on Tuesday, June 3rd, with a rough agenda like the following (as suggested by @dannygreg):

    • Late(ish) start - ~11am
    • Brief kickoff talk (I'll do a quick overview of the day)
    • 2 or 3 talks (each ~ 30 mins)
    • Lazy Lunch
    • Panel and QA discussion
    • Social/"networking" time

    We'll have a proper event invitation coming soon, to which you can RSVP. However, we'd like to solicit talks from RAC collaborators.

    Would anyone from @ReactiveCocoa/reactivecocoa be interested in speaking?

    question 
    opened by jspahrsummers 60
  • The Great Swiftening (a.k.a. the new 3.0)

    The Great Swiftening (a.k.a. the new 3.0)

    Resolves #1365 and #1366. Per my comments in #1369, this is intended to be a long-running branch that will eventually become RAC 3.0, supplanting the current 3.0-development work.

    To get us started, I basically just subtree merged jspahrsummers/RxSwift into here, then bridged several RAC classes back and forth.

    opened by jspahrsummers 59
  • Replace ColdSignal and HotSignal with SignalProducer and Signal

    Replace ColdSignal and HotSignal with SignalProducer and Signal

    After the long discussion in #1650, I invited @NachoSoto, @andymatuschak, and @kastiglione to talk more in-depth about the Swift APIs, and specifically where they need improvement.

    We had a really, really great brainstorming session, and this is the result. The good news is that we all feel pretty good about this direction, and the bad news is that everything is getting rewritten again. :trollface:

    The important bits are documented on the types themselves, but here’s the handy Quick Start guide of the proposed changes:

    1. HotSignal<T> will be replaced by Signal<T>. Besides the name change, these signals can now send Error and Completed events. This avoids a lot of the lifecycle weirdness that has come up with a value-only HotSignal.
    2. ColdSignal<T> will be replaced by SignalProducer<T>. As the name implies, a signal producer creates Signals (via the start method). You can kind of think of the relationship as something like:
      • SignalProducer : Signal :: RACSignal : subscription
      • SignalProducer : Signal :: class : instance
    3. Most of the basic operators are written in terms of Signal, but can be lifted to apply to SignalProducer instead.
    4. Operators that benefit from “cold” semantics, like retry and repeat, are written in terms of SignalProducer.

    The advantages here are:

    • The relationship between “hot” and “cold” signals is now much more explicit and well-defined. A “cold” signal (a producer) creates “hot” signals, each of which represents a “subscription” (in RAC 2.x terms).
    • Many operators only have to be written once, in terms of Signal, and can be lifted to the SignalProducer level.
    • The semantics and/or difficulties of converting between “hot” and “cold” are more obvious, I think. You don’t need to swap between them on the fly, because they mean different things.
    • Signal lifetime is now consistent, and completely defined by the event stream. Signal producers don’t do anything special—they really are just value types, and don’t encode any information about lifetime.

    I’ll also make some notes in the changes below, to explain more specific things. Please leave feedback if you have it! :bow:

    opened by jspahrsummers 56
  • RACDC 2015

    RACDC 2015

    Just like last year and the year before, we want to do some kind of RAC community event during WWDC week (June 8–12).

    We don't know what, though, or when. Did you particularly like either of the previous formats, or any aspects of them? Do you have any ideas for something new we should try?

    I'd love to hear your thoughts! :pray:

    /cc @ReactiveCocoa/reactivecocoa

    question 
    opened by jspahrsummers 53
  • Cocoa extensions from Rex.

    Cocoa extensions from Rex.

    Changes

    General

    • [x] Updated for Swift 3.0 GM.
    • [x] A standalone rac_signalForSelector port.
    • [x] ~~Hide the ReactiveCocoaPrivate module.~~
    • [x] Adopted BindingTarget for all non-observable key paths.
    • [x] Update the documentation.

    The Reactive proxy

    • [x] Moved all extension method and properties to Reactive.
    • [x] Point to a new ReactiveSwift (pre-)release with Reactive.

    CocoaAction

    • [x] Consolidated the API of CocoaAction.
    • [x] Parameterized CocoaAction with an assumed sender type.

    Control bindings and values

    • [x] Extensions for NSControl.
    • [x] Text controls now expose an end-of-editing signal by default, with continuous counterparts added.
    • [x] Control values are split into a pair of binding target and signal.
    • [x] UIControl.reactive.trigger(for:) for all UIControlEvents.

    Blocked by:

    • [x] Reactive. https://github.com/ReactiveCocoa/ReactiveSwift/pull/51
    • [x] Scheduler in BindingTarget. https://github.com/ReactiveCocoa/ReactiveSwift/pull/49
    • [x] API Design: Exposing the control values. https://github.com/ReactiveCocoa/ReactiveCocoa/issues/3229
    • [x] API Design: Control Binding API for Actions. https://github.com/ReactiveCocoa/ReactiveCocoa/issues/3233

    Review

    • [x] @mdiep
    • [x] @NachoSoto
    • Others
    opened by andersio 48
  • How do I cancel the work of inner producers?

    How do I cancel the work of inner producers?

    Let's say I have parallel work I want to do, such as downloading multiple images. Each of these downloads is represented by a SignalProducer. I create them and flatten them using the Merge strategy. When I start the outer producer and get a disposable I expected that disposing of that would also dispose of the inner producers. What actually happens is that after disposal, my outer producer stops receiving events, but the actual work being done by the inner producers continues, because they have not been disposed.

    How do I get the actual work being done by the inner producers to stop? Here's some test code that illustrates the scenario:

    func producerOfValues(values: [String]) -> SignalProducer<String, NoError> {
        return SignalProducer<String, NoError> {observer, disposable in
            for value in values {
                sleep(1)
                print("doing work: \(value)")
                sendNext(observer, value)
                if disposable.disposed { // 'disposed' is never true
                    print("producer disposed")
                    break
                }
            }
            sendCompleted(observer)
        }
    }
    
    let (signal, sink) = SignalProducer<SignalProducer<String, NoError>, NoError>.buffer(2)
    let flattened = signal.flatten(.Merge)
    
    let letterProducer = producerOfValues(["a", "b", "c"])
    let numberProducer = producerOfValues(["1", "2", "3"])
    
    sendNext(sink, letterProducer.startOn(QueueScheduler()))
    sendNext(sink, numberProducer.startOn(QueueScheduler()))
    sendCompleted(sink)
    
    let disposable = flattened.startWithNext {
        print($0)
    }
    disposable.dispose()
    

    Output:

    doing work: a
    doing work: 1
    doing work: b
    doing work: 2
    doing work: c
    doing work: 3
    
    bug help wanted 
    opened by bdolman 48
  • Visual Identity Refresh for 4.0

    Visual Identity Refresh for 4.0

    I've been meaning to open this issue for a while, but kept finding excuses, mainly the fact that 3.0 was far from release. That is no longer the case now.

    Basically, I'd like to spearhead an effort to revamp the visual identity of RC and hopefully be done with that in time with the 3.0 final release.

    For reference, here is the current logo/color palette: screenshot-2015-07-19-1

    I've played with the concept below a while ago, but I restarted from scratch recently after having talked to @jspahrsummers during WWDC.

    screenshot-11-14-1

    Here are some of the recent sketches to get the creative juices flowing:

    screenshot-2015-07-19

    I'll be detailing the rest of the process in this thread.

    enhancement 
    opened by kaishin 43
  • <RACStream> monad, RACSequence

    monad, RACSequence

    #89

    Added a lazy RACSequence class, and abstracted common APIs between it and <RACSubscribable> into a new <RACStream> protocol. I'm definitely open to better names for these guys.

    RAC should be tagged before this gets merged in.

    opened by jspahrsummers 38
  • The future of RAC 3.0

    The future of RAC 3.0

    Given recent developments, how much should we allow ourselves to disregard backwards compatibility in our next release?

    Is there any part of the RAC contract you would like to change or get rid of?

    For example I would like to take a much more relaxed approach to evaluation, like Rx with its "you cannot assume anything about what scheduler your blocks run on unless you specify a scheduler" caveat.

    On one side it would allow us to optimize for certain use cases much more aggressively, but even better it would promote functional purity when using the framework. What I want is for the lack of strict evaluation semantics not to force users of the framework to do their own serialization and rescheduling of the blocks, but rather to allow them to not care about when, where and how the blocks are executed, because the blocks would be pure functions.

    I realize this can't be done because even in Swift there is no way to specify side effects or lack thereof in the type, or even thread-safety or atomicity, so I'm not suggesting we do this since it would be very confusing for the users, it's just an example of what I mean by changes in the contract.

    I'm sure someone has more reasonable ideas on the matter.

    question 
    opened by Coneko 37
  • Current version can't be compiled with the latest ReactiveSwift version

    Current version can't be compiled with the latest ReactiveSwift version

    Recently ReactiveSwift min deployment targets were bumped in a minor release. So now ReactiveCocoa has min iOS deployment target iOS 9 but it has ReactiveSwift ~> 7.0 that resolves to the new ReactiveSwift 7.1 that has min deployment target iOS 10. As a result I'm getting

    - ERROR | [iOS] xcodebuild:  ReactiveCocoa/ReactiveCocoa/AnyObject+Lifetime.swift:2:8: error: compiling for iOS 9.0, but module 'ReactiveSwift' has a minimum deployment target of iOS 10.0
    

    Could you please bump ReactiveCocoa min deployment targets to make it compatible with the ReactiveSwift 7.1

    opened by Vyazovoy 1
  • Cannot remove an observer <RACKVOProxy 0x280264940> for the key path because it is not registered as an observer.">

    Cannot remove an observer for the key path "unit" from because it is not registered as an observer.

    Code:

    [self.hgWorkStyleDisposable dispose];

    self.hgWorkStyleDisposable = [[[RACSignal combineLatest:@[RACObserve(devicedata_weak_, PK_workStyle),RACObserve(devicedata_weak_, hgDetailModel.settings.unit)]] deliverOnMainThread] subscribeNext:^(RACTuple * _Nullable x) {
    } ];
    

    Error #0 Thread NSRangeException Cannot remove an observer <RACKVOProxy 0x280264940> for the key path "unit" from <HGConfigureModel 0x280d25050> because it is not registered as an observer.

    Stack:

    CoreFoundation ___exceptionPreprocess + 164

    4 Foundation -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:] + 196 5 ReactiveObjC -[RACKVOTrampoline dispose] (RACKVOTrampoline.m:84) 6 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 7 ReactiveObjC __69-[NSObject(RACKVOWrapper) rac_observeKeyPath:options:observer:block:]_block_invoke.17 (NSObject+RACKVOWrapper.m:195) 8 ReactiveObjC -[RACDisposable dispose] (RACDisposable.m:82) 9 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 10 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 11 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 12 ReactiveObjC __69-[NSObject(RACKVOWrapper) rac_observeKeyPath:options:observer:block:]_block_invoke.17 (NSObject+RACKVOWrapper.m:195) 13 ReactiveObjC -[RACDisposable dispose] (RACDisposable.m:82) 14 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 15 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 16 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 17 ReactiveObjC __69-[NSObject(RACKVOWrapper) rac_observeKeyPath:options:observer:block:]_block_invoke.17 (NSObject+RACKVOWrapper.m:195) 18 ReactiveObjC -[RACDisposable dispose] (RACDisposable.m:82) 19 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 20 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 21 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 22 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 23 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 24 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 25 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 26 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 27 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 28 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 29 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 30 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 31 PetKit -[PKHomeK2CollectionViewCell handleForReuseCell] (PKHomeK2CollectionViewCell.m:84) 32 PetKit -[PKHomeDeviceBaseCollectionCell prepareForReuse] (PKHomeDeviceBaseCollectionCell.m:36)

    opened by zhenghaonagehao 0
  • Allow NSObject.reactive.signal to also intercept and return the 'return' value of the executed selector.

    Allow NSObject.reactive.signal to also intercept and return the 'return' value of the executed selector.

    Added the includeReturnValue to reactive.signal(for selector: Selector)

    NSObject.reactive.signal(for selector: Selector, includeReturnValue: Bool = false)

    Will add a return value to the end of the array, for each value of the Signal. If the selector does not return a value, than the flag is ignored and no value is appended to the array.

    Checklist

    • [x] Updated CHANGELOG.md.
    opened by mishagray 1
  • DelegateProxy revamp

    DelegateProxy revamp

    1. Methods would now be automatically implemented. Subclassing is no longer necessary.

    2. DelegateProxy can now be constructed through NSObject.reactive.proxy(forKey:).

    3. Fixed a memory leak due to the use of forwardingTarget(for:) as the fast path of delegate call forwarding.

    4. More DelegateProxy test cases.

    Usage

    extension Reactive where Base: UITableView {
        var proxy: DelegateProxy<UITableViewDelegate> {
            return proxy(forKey: #keyPath(UITableView.delegate))
        }
    }
    

    To-do

    • [x] Evaluate the behaviour of protocols with non-void-returning required methods.
    • [x] Documentations and Implementation Notes.
    • [x] Share implementation with method Interception.
    opened by andersio 8
  • [WIP] User Interface Recipes

    [WIP] User Interface Recipes

    Please note that this document is very much a work in progress. Some things that I've left to do:

    • [ ] Remove the dependency on https://github.com/neilpa/Rex
    • [ ] Produce an actual example project. (Much of the below code was typed "raw" into my text editor, and likely won't compile.)
    • [ ] Get feedback from people who have been doing this much longer
    • [ ] Fix the TODOs

    There really isn't any sort of "canonical document" for creating UI code using ReactiveCocoa, and that's probably due to the fact that it's difficult to find a single approach or "recipe" that applies to all scenarios. In my own work on Capo and FuzzMeasure over the past 6 months I have found so many different scenarios and examples that forced me to repeatedly question what I was doing.

    Just when I think that I have an approach figured out, I find another handful of new challenges when I move to another part of the UI to work on. For instance, when I built a lot of iOS UI code I found that it was very easy to build static UIs for UITableViewCells and use ViewModels to ensure that I encapsulate the presentation behavior.

    Once I moved to editable controls for the Neptune UI I faced a whole new set of challenges when trying to get values propagated from my ViewModel down into my audio engine, and encapsulating a live-updating visualization (that wasn't needlessly updating the screen while playback wasn't active, also!)

    I feel that this collection of "Recipes" for various UI patterns would be extremely helpful to people that are new to ReactiveCocoa, and folks that might be looking for ideas when discovering new challenges that they haven't faced before.

    opened by liscio 5
Releases(12.0.0)
  • 12.0.0(Nov 20, 2021)

    This is the first release of ReactiveCocoa 12.0.

    Change

    1. This is a matching release for ReactiveSwift 7.0, which contained minor ABI and source breaking changes.
    Source code(tar.gz)
    Source code(zip)
  • 11.2.2(Sep 7, 2021)

    This is a patch release of ReactiveCocoa 11.2.

    Changes

    1. Building from Xcode project no longer warns about use of deprecated class keyword usage. (#3726, kudos to @michalsrutek)
    2. Updated Carthage xcconfig dependency to 1.1 for proper building arm64 macOS variants. (#3728, kudos to @iby)
    Source code(tar.gz)
    Source code(zip)
  • 11.2.1(Apr 23, 2021)

    This is a patch release of ReactiveCocoa 11.2.

    Change

    1. Fixed missing Foundation import when building with SPM in Xcode 12.5. (#3725, kudos to @TimPapler)
    Source code(tar.gz)
    Source code(zip)
  • 11.2.0(Mar 16, 2021)

    This is the second minor release of ReactiveCocoa 11.

    Changes

    1. Requires ReactiveSwift 6.6.0 or later.
    2. The minimum deployment target for iOS has been raised consistently to 9.0 across all integration mediums.
    Source code(tar.gz)
    Source code(zip)
  • 11.1.0(Mar 8, 2021)

  • 11.0.0(Jun 16, 2020)

  • 10.3.0(May 11, 2020)

    Changes

    1. Don't include code which uses unavailable classes (like NSSlider) when targeting macOS Catalyst. (#3698, kudos to @nkristek)
    2. Fixed watchOS build issues. (#3703, kudos to @JaviSoto)
    Source code(tar.gz)
    Source code(zip)
  • 10.2.0(Jan 7, 2020)

    Changes

    1. Update ReactiveSwift to 6.2.
    2. Support for Swift Package Manager (#3692, #3676 & #3693, kudos to @fabio-cerdeiral-ck, @sharplet and @simba909)
    Source code(tar.gz)
    Source code(zip)
  • 10.1.0(Sep 26, 2019)

    This is the first minor release of ReactiveCocoa 10. It supports Swift 5.0 (Xcode 10.2/Xcode 10.3) and Swift 5.1 (Xcode 11).

    Changes

    • Update dependencies so ReactiveCocoa can be used with Xcode 11 (#3677, kudos to @olejnjak)

    Bugfixes

    • Fix crashes of NSObject.signal(for:) and NSObject.producer(for:) with Objective-C enums (#3667, kudos to @gfontenot)

    Additions

    • Add a binding target for the barTintColor of UINavigationBar (#3675, kudos to @rehatkathuria)
    • Add reactive extensions for standard WatchKit interface objects. (#3670, kudos to @tdimeco)
    Source code(tar.gz)
    Source code(zip)
  • 10.0.0(Apr 27, 2019)

    This is the first release of ReactiveCocoa 10.0. It supports Xcode 10.2 and Swift 5.0.

    Changes

    1. Update ReactiveSwift to 6.0.
    2. Remove dependency on antitypical/Result.

    Migration notes

    • If you have used Result only as dependency of ReactiveSwift, remove all instances of import Result, import enum Result.NoError or import struct Result.AnyError and remove the Result Framework from your project.
    • Replace all cases where NoError was used in a Signal or SignalProducer with Never
    • Replace all cases where AnyError was used in a Signal or SignalProducer with Swift.Error
    Source code(tar.gz)
    Source code(zip)
  • 9.0.0(Mar 28, 2019)

    This is the first release of ReactiveCocoa 9.0. It requires Swift 4.2 or above and supports Xcode 10.2/Swift 5.0.

    Improvements

    • UITextField and UITextView text and attributedText values non-optional. (#3591, kudos to @Marcocanc)

    Additions

    • KVO observations can now be made with Smart Key Path in Swift 3.2+, using producer(for:) and signal(for:) available on NSObject.reactive. (#3491, kudos to @andersio)
    • Binding target for UIApplication.applicationIconBadgeNumber (#3589, kudos to @cocoahero).
    • An extension for NSView.alphaValue. (#3636, kuds to @eimantas)
    • An extension for NSView.isHidden. (#3634, kudos to @eimantas)
    Source code(tar.gz)
    Source code(zip)
  • 8.0.2(Oct 20, 2018)

    This is the second patch release of ReactiveSwift 8.0. It supports Swift 4.1 (Xcode 9.4) and Swift 4.2 (Xcode 10).

    Carthage compatibility

    A build configuration related issue blocking Carthage builds has been resolved.

    Change

    1. ReactiveMapKit has now platform specific build targets and schemes. (#3625, kudos to @andersio)
    Source code(tar.gz)
    Source code(zip)
  • 8.0.1(Oct 6, 2018)

    This is a patch release of ReactiveSwift 8.0. It supports Swift 4.1 (Xcode 9.4) and Swift 4.2 (Xcode 10).

    CocoaPods compatibility

    The pod spec has been annotated with the language mode ReactiveCocoa is supposed to be built in (Swift 4.1). This should resolve issues when using ReactiveCocoa via CocoaPods with projects in Swift 4.2 mode.

    Bugfix

    1. Fixed an issue of SignalProducer.take(duringLifetimeOf:) incorrectly retaining its argument. (#3615, kudos to @andrei-kuzma)

    Additions

    1. Add extensions for several properties on WKInterfaceLabel and WKInterfaceButton. (#3616, kudos to @yoching)
    2. Add swift_version to podspecs (#3622, kudos to @olejnjak)
    3. Introduce Lifetime.of(_:) which retrieves the lifetime of any Objective-C or Swift native object. (#3614, kudos to @ra1028)
    Source code(tar.gz)
    Source code(zip)
  • 8.0.0(Jul 25, 2018)

    This is the first release of ReactiveCocoa 8.0. It supports Swift 4.1 (Xcode 9.4) and preliminarily Swift 4.2 (Xcode 10).

    Change

    1. Requires ReactiveSwift 4.0.

    Additions

    1. Add support for Cocoapods 1.5.0 static frameworks (#3590, kudos to @mishagray)
    2. Add becomeFirstResponder and resignFirstResponder extensions to UIResponder. (#3585, kudos to @Marcocanc)
    3. Added title binding target to UIViewController (#3588, kudos to @cocoahero).
    4. Added several trigger signals for view lifecycle events to UIViewController (#3588, kudos to @cocoahero).
    5. Add extensions for several properties on UIBarButtonItem (#3586, kudos to @asmallteapot).
    Source code(tar.gz)
    Source code(zip)
  • 8.0.0-rc.1(Jul 4, 2018)

    This is the first release candidate of ReactiveCocoa 8.0. It supports Swift 4.1 (Xcode 9.4) and preliminarily Swift 4.2 (Xcode 10).

    Change

    1. Requires ReactiveSwift 4.0 Release Candidate 2.

    Additions

    1. Add support for Cocoapods 1.5.0 static frameworks (#3590, kudos to @mishagray)
    2. Add becomeFirstResponder and resignFirstResponder extensions to UIResponder. (#3585, kudos to @Marcocanc)
    3. Added title binding target to UIViewController (#3588, kudos to @cocoahero).
    4. Added several trigger signals for view lifecycle events to UIViewController (#3588, kudos to @cocoahero).
    Source code(tar.gz)
    Source code(zip)
  • 7.2.0(Apr 8, 2018)

    This is the second minor release of ReactiveCocoa 7. It requires ReactiveSwift 3.1, and supports Swift 3.2, 4.0 and 4.1.

    Changes

    1. Mitigated a compilation issue specific to Swift 4.1. (#3583)

    2. Fixed a compilation issue related to SR-7299. (#3580)

    3. Improved the interoperability of method interception. (#3570, kudos to @andersio)

    Additions

    1. Add showsCancelButton, textDidBeginEditing and textDidEndEditing extensions to UISearchBar (#3565, kudos to @banjun)

    2. NotificationCenter.reactive.keyboard(_:) for system keyboard notification by the event types. (#3566, kudos to @ra1028)

    3. Add extensions for several properties on UINavigationItem (#3576, kudos to @asmallteapot).

    Source code(tar.gz)
    Source code(zip)
  • 7.1.0(Jan 13, 2018)

    This is the first release of ReactiveCocoa 7.1. It requires ReactiveSwift 3.1, and supports Swift 3.2 and Swift 4.0.

    Change

    1. Requires ReactiveSwift 3.1.

    2. Fix an issue preventing ReactiveCocoa from being built with the Swift 3.2 language mode. (#3556)

      This issue might affect only users with CocoaPods 1.3.1 and earlier. For Carthage and the Xcode Project users, ReactiveCocoa is always built with the Swift 4.0 language mode.

    Addition

    1. Added reactive extension for AppKit's NSTextView. (#3549, kudos to @Palleas)
    Source code(tar.gz)
    Source code(zip)
  • 7.1.0-rc.2(Dec 24, 2017)

    This is the second release candidate of ReactiveCocoa 7.1. It requires ReactiveSwift 3.1, and supports Swift 3.2 and Swift 4.0.

    Change

    1. Fix an issue preventing ReactiveCocoa from being built with the Swift 3.2 language mode. (#3556)

      This issue might affect only users with CocoaPods 1.3.1 and earlier. For Carthage and the Xcode Project users, ReactiveCocoa is always built with the Swift 4.0 language mode.

    Source code(tar.gz)
    Source code(zip)
  • 7.1.0-rc.1(Dec 23, 2017)

  • 7.0.1(Nov 24, 2017)

    This is the first maintenance release of ReactiveCocoa 7.0. It supports Swift 3.2 and Swift 4.0.

    Bugfix

    1. Fixed DynamicProperty for optional properties. (#3548, kudos to @iv-mexx)

    Additions

    1. Added tintColor binding target to UIView. (#3542, kudos to @iv-mexx)

    2. Made makeBindingTarget available on Reactive extensions on all objects, not just NSObject. (#3545, kudos to @Burgestrand)

    Source code(tar.gz)
    Source code(zip)
  • 7.0.0(Nov 17, 2017)

    This is the first release of ReactiveCocoa 7.0. It supports Swift 3.2 and Swift 4.0.

    Breaking Change

    1. ReactiveCocoa 7.0 requires ReactiveSwift 3.0 (release note).

    2. DynamicProperty no longer emits optionals. (#3461, kudos to @andersio)

      It now caches the latest value so that even if the underlying object has deinitialised, it would still be able to provide access.

    3. MapKit reactive bindings have been moved to a new ReactiveMapKit framework. (#3524)

      Sources that use the MapKit bindings are now required to import ReactiveMapKit.

      For all Xcode project users (including Carthage), targets need to be configured to link against ReactiveMapKit.

      For CocoaPods users, your Podfile needs to be updated too, since the framework is offered as a standalone pod.

      pod "ReactiveMapKit", "7.0.0-alpha.1"
      

    Change

    1. ReactiveCocoa is now compatible with the Swift 4.0 language mode, in addition to the Swift 3.2 compatibility mode. (#3526, kudos to @andersio)

    Addition

    1. New convenience:Property(object:keyPath:). (#3461, kudos to @andersio)

      A read-only version of DynamicProperty. Note that this variant is just for untyped key path.

    2. Subscripting reactive with a key path now yields a corresponding BindingTarget under Swift 3.2+. (#3489, kudos to @andersio)

      Example:

      label.reactive[\.text] <~ viewModel.title
      
    3. UISearchBar has gained more reactive bindings and signals. (#3531, kudos to @andersio)

      Signals: Search Button Clicked, Bookmark Button Clicked, Results List Clicked, Selected Scope Button Index

      Binding Target: Selected Scope Button Indices.

    Source code(tar.gz)
    Source code(zip)
  • 7.0.0-rc.1(Oct 31, 2017)

    This is the second alpha release of ReactiveCocoa 7.0. It supports Swift 3.2 and Swift 4.0.

    Breaking Change

    1. DynamicProperty no longer emits optionals. (#3461, kudos to @andersio)

      It now caches the latest value so that even if the underlying object has deinitialised, it would still be able to provide access.

    Addition

    1. New convenience:Property(object:keyPath:). (#3461, kudos to @andersio)

      A read-only version of DynamicProperty. Note that this variant is just for untyped key path.

    2. UISearchBar has gained more reactive bindings and signals. (#3531, kudos to @andersio)

      Signals: Search Button Clicked, Bookmark Button Clicked, Results List Clicked, Selected Scope Button Index

      Binding Target: Selected Scope Button Indices.

    Source code(tar.gz)
    Source code(zip)
  • 7.0.0-alpha.2(Oct 20, 2017)

    This is the second alpha release of ReactiveCocoa 7.0. It supports Swift 3.2 and Swift 4.0.

    Changes

    1. Requires ReactiveSwift 3.0.0 alpha 1.

    2. ReactiveCocoa is now compatible with the Swift 4.0 language mode, in addition to the Swift 3.2 compatibility mode. (#3526, kudos to @andersio)

    Source code(tar.gz)
    Source code(zip)
  • 7.0.0-alpha.1(Oct 7, 2017)

    This is the first alpha release of ReactiveCocoa 7.0. It targets Swift 3.1, Swift 3.2 and Swift 4.0.

    ReactiveMapKit

    1. MapKit reactive bindings have been moved to a new ReactiveMapKit framework. (#3524)

      Sources that use the MapKit bindings are now required to import ReactiveMapKit.

      For all Xcode project users (including Carthage), targets need to be configured to link against ReactiveMapKit.

      For CocoaPods users, your Podfile needs to be updated too, since the framework is offered as a standalone pod.

      pod "ReactiveMapKit", "7.0.0-alpha.1"
      

    Special Note on CocoaPods compatibility

    As at October 2017, CocoaPods has yet to officially support projects with mixed Swift language modes.

    If you fail to build ReactiveCocoa with CocoaPods, you must apply a workaround to override SWIFT_VERSION of ReactiveCocoa as Swift 3.2.

    Visit https://github.com/CocoaPods/CocoaPods/issues/6791 for more information.

    Source code(tar.gz)
    Source code(zip)
  • 6.1.0-alpha.2(Sep 21, 2017)

    This is the second alpha release of ReactiveCocoa 6.1. It targets Swift 3.1, Swift 3.2 and Swift 4.0.

    Change

    1. Improved CocoaPods compatibility when working with Swift 4 projects.
    Source code(tar.gz)
    Source code(zip)
  • 6.0.2(Sep 21, 2017)

    This is the second maintenance release of ReactiveCocoa 6.0. It targets Swift 3.1, Swift 3.2 and Swift 4.0.

    Changes

    1. Disabled code coverage data to allow app submissions with Xcode 9.0 (see https://github.com/Carthage/Carthage/issues/2056, kudos to @NachoSoto)

    2. Improved CocoaPods compatibility when working with Swift 4 projects.

    Source code(tar.gz)
    Source code(zip)
  • 6.1.0-alpha.1(Sep 16, 2017)

    This is the first alpha release of ReactiveCocoa 6.1. It targets Swift 3.1, Swift 3.2 and Swift 4.0.

    Change

    1. Disabled code coverage data to allow app submissions with Xcode 9.0 (see https://github.com/Carthage/Carthage/issues/2056, kudos to @NachoSoto)

    2. Updated to ReactiveSwift 2.1.0 alpha 2.

    Additions

    1. Added cancelButtonClicked signal to UISearchBar.

    2. Subscripting reactive with a key path now yields a corresponding BindingTarget under Swift 3.2+. (#3489, kudos to @andersio)

      Example:

      label.reactive[\.text] <~ viewModel.title
      
    Source code(tar.gz)
    Source code(zip)
  • 6.0.1(Aug 16, 2017)

    This is the first maintenance release of ReactiveCocoa 6.0. It targets the Xcode 8.3 SDK and Swift 3.1, with preliminary support of the Xcode 9 SDK, Swift 3.2 and Swift 4.0.

    Changes

    1. [Xcode 9 beta 5] Fixed an issue causing infinite recursion in the Swift runtime. (#3498, kudos to @andersio)

    2. Update ReactiveSwift to 2.0.1.

      https://github.com/ReactiveCocoa/ReactiveSwift/releases/tag/2.0.1

    Source code(tar.gz)
    Source code(zip)
  • 6.0.0(Jul 21, 2017)

    This is the sixth major release of ReactiveCocoa. It supports Swift 3.1 (Xcode 8.3), and preliminarily supports Swift 3.2 and Swift 4.0 (Xcode 9).

    Hightlight

    ReactiveSwift 2.0

    Please refer to the ReactiveSwift 2.0 release note for more details.

    Changes

    1. NSObject reactive extensions now work in generic environments that are limited to NSObjectProtocol. (#3484, kudos to @nickdomenicali)

    2. UIButton.reactive.pressed now reacts to the primaryActionTriggered control event, instead of touchUpInside, on iOS 9.0+ and tvOS 9.0+. (#3480, kudos to @andrei-kuzma)

    Additions

    1. New reactive extension for UIScrollView: scrollsToTop. (#3481, kudos to @Qata)

    2. New reactive extension: UITextField.reactive.selectedRangeValues. (#3479, kudos to @Igor-Palaguta)

    Source code(tar.gz)
    Source code(zip)
  • 6.0.0-rc.3(Jul 12, 2017)

    This is the third release candidate of ReactiveCocoa 6.0. It targets Swift 3.1 with preliminary support of Swift 3.2 and Swift 4.0.

    Changes

    1. Updated for ReactiveSwift 2.0.0 Release Candidate 3.
    Source code(tar.gz)
    Source code(zip)
Owner
A framework for composing and transforming streams of values
null
RxReduce is a lightweight framework that ease the implementation of a state container pattern in a Reactive Programming compliant way.

About Architecture concerns RxReduce Installation The key principles How to use RxReduce Tools and dependencies Travis CI Frameworks Platform Licence

RxSwift Community 125 Jan 29, 2022
A New, Modern Reactive State Management Library for Swift and SwiftUI (The iOS implementation of Recoil)

RecoilSwift RecoilSwift is a lightweight & reactive swift state management library. RecoilSwift is a SwiftUI implementation of recoil.js which powered

Holly Li 160 Dec 25, 2022
RxXRepository: reactive extension for XRepository

RxXRepository is reactive extension for XRepository. This extension allows imple

Sashko Potapov 1 Jan 6, 2022
Spin aims to provide a versatile Feedback Loop implementation working with the three main reactive frameworks available in the Swift community (RxSwift, ReactiveSwift and Combine)

With the introduction of Combine and SwiftUI, we will face some transition periods in our code base. Our applications will use both Combine and a thir

Spinners 119 Dec 29, 2022
Cocoa framework and Obj-C dynamism bindings for ReactiveSwift.

Reactive extensions to Cocoa frameworks, built on top of ReactiveSwift. ⚠️ Looking for the Objective-C API? ?? Migrating from RAC 4.x? ?? Release Road

null 20k Jan 8, 2023
Reflection based (Dictionary, CKRecord, NSManagedObject, Realm, JSON and XML) object mapping with extensions for Alamofire and Moya with RxSwift or ReactiveSwift

EVReflection General information At this moment the master branch is tested with Swift 4.2 and 5.0 beta If you want to continue using EVReflection in

Edwin Vermeer 964 Dec 14, 2022
Set of useful extensions for ReactiveSwift & ReactiveCocoa

ACKReactiveExtensions ACKReactiveExtensions is set of useful extensions for ReactiveCocoa you could use in your apps. Currently we have extensions for

Ackee 17 Aug 12, 2022
Reflection based (Dictionary, CKRecord, NSManagedObject, Realm, JSON and XML) object mapping with extensions for Alamofire and Moya with RxSwift or ReactiveSwift

EVReflection General information At this moment the master branch is tested with Swift 4.2 and 5.0 beta If you want to continue using EVReflection in

Edwin Vermeer 964 Dec 14, 2022
Model framework for Cocoa and Cocoa Touch

Mantle Mantle makes it easy to write a simple model layer for your Cocoa or Cocoa Touch application. The Typical Model Object What's wrong with the wa

null 11.3k Dec 31, 2022
Adding ruby style each iterator to Cocoa/Cocoa touch Swift Array and Range classes, And Int.times{} to Int class

Collection-Each Adding ruby style each iterator to Cocoa/Cocoa touch Swift Array, Dictionary and Range classes, and Int.times ###Why? Array/Dictionary

Omar Abdelhafith 65 Jun 9, 2018
Reactive WebSockets - A lightweight abstraction layer over Starscream to make it reactive.

RxWebSocket Reactive extensions for websockets. A lightweight abstraction layer over Starscream to make it reactive. Installation RxWebSocket is avail

Flávio Caetano 57 Jul 22, 2022
A Swift package for rapid development using a collection of micro utility extensions for Standard Library, Foundation, and other native frameworks.

ZamzamKit ZamzamKit is a Swift package for rapid development using a collection of micro utility extensions for Standard Library, Foundation, and othe

Zamzam Inc. 261 Dec 15, 2022
Swift JSExport extensions for macOS system frameworks

framework-bridge Swift JSExport extensions for macOS system frameworks. Progress Foundation AppKit Usage Swift import JavaScriptCore import FrameworkB

John Susek 0 Dec 13, 2021
Allows users to pull in new song releases from their favorite artists and provides users with important metrics like their top tracks, top artists, and recently played tracks, queryable by time range.

Spotify Radar Spotify Radar is an iOS application that allows users to pull in new song releases from their favorite artists and provides users with i

Kevin Li 630 Dec 13, 2022
RavynOS File manager built in Cocoa/Appkit and ObjC

Filer A file manager and re-implementation of macOS's Finder. A key component of ravynOS, Filer is the first application you see after you start ravyn

RavynSoft 8 Oct 3, 2022
A reactive, card-based UI framework built on UIKit for iOS developers.

CardParts - made with ❤️ by Intuit: Example Requirements Installation Communication & Contribution Overview Quick Start Architecture CardsViewControll

Intuit 2.5k Jan 4, 2023
A reactive wrapper built around UIImagePickerController.

RxMediaPicker RxMediaPicker is a RxSwift wrapper built around UIImagePickerController consisting in a simple interface for common actions like picking

RxSwift Community 180 Apr 24, 2022
Queuer is a queue manager, built on top of OperationQueue and Dispatch (aka GCD).

Queuer is a queue manager, built on top of OperationQueue and Dispatch (aka GCD). It allows you to create any asynchronous and synchronous task easily, all managed by a queue, with just a few lines.

Fabrizio Brancati 1k Dec 2, 2022
Zip - A Swift framework for zipping and unzipping files. Simple and quick to use. Built on top of minizip.

Zip A Swift framework for zipping and unzipping files. Simple and quick to use. Built on top of minizip. Usage Import Zip at the top of the Swift file

Roy Marmelstein 2.3k Jan 3, 2023
A swift network profiler built on top of URLSession.

By Xmartlabs SRL. Introduction Xniffer is a non-intrusive framework for intercepting outgoing requests and their responses between your app and any ex

xmartlabs 498 Dec 24, 2022