Replacing the Objective-C “Delegate Pattern” with ReactiveCocoa

“ReactiveCocoa”: is a library created by “GitHub”: that brings “Functional Reactive Programming” to Objective-C. It provides a number useful “features”: right out of the gate which gives a developer the power to observe, transform, merge, and filter signals that contain values.

More importantly, it has the power to build on top of and replace existing (and sometimes archaic) patterns used in Objective-C. One of the most common of these patterns is the “delegate pattern.”

h2. The Delegate Pattern

The delegate pattern is a pattern of delegating tasks to an object and potentially informing it of certain actions that are being taken. Here’s a typical example of the delegate pattern found in iOS programming:

- (void)viewDidLoad {
    UISearchBar *searchBar = [[UISearchBar alloc] initWithFrame: CGRectZero];
    self.searchController = [[UISearchDisplayController alloc] initWithSearchBar:self.searchBar contentsController:self];
    self.searchController.delegate = self;
    // Place it in view
    searchBar.delegate = self;

- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)text {
    self.searchResults = [self search: text];

- (void)searchDisplayControllerDidBeginSearch:(UISearchDisplayController *)searchController {
    self.isSearching = YES;

- (void)searchDisplayControllerDidEndSearch:(UISearchDisplayController *)searchController {
    self.isSearching = NO;

In this particular example, the object (presumably a UIViewController) is the delegate to both the UISearchBar and UISearchDisplayController. The _searchBar:textDidChange:_ delegate method updates the search results and the UISearchDisplayController delegate methods (_searchDisplayControllerDidBeginSearch_ and _searchDisplayControllerDidEndSearch_ respectively) track whether the search is currently active.

There are a couple of issues with this delegate approach:

# There is only ever one object that can subscribe to changes to the UISearchBar and UISearchDisplayController. All actions must go through the delegate.
# The act of searching is is scattered across three different callbacks.

h2. The ReactiveCocoa Toolbox

ReactiveCocoa has built-in helpers for creating signals from any selector on an object or protocol.

h3. rac_signalForSelector: and rac_signalForSelector:fromProtocol:

These two helpers will create a signal that is bound to a selector, such that any time that selector is invoked on the object it will send a new value through the signal.

h3. rac_liftSelector:withSignals:

This helper will “lift” a selector into “signal space” where the selector is invoked anytime the corresponding argument signals send a new value. The signals passed to the rac_liftSelector must match the number of arguments expressed by the selector.

h2. Replacing the Delegate Pattern

Now that we have familiarized ourselves with some of the more powerful aspects of ReactiveCocoa, we can replace the delegate pattern example with one that uses signals.

h3. UISearchBar

Instead of having to assign a delegate to the UISearchBar and implement searchBar:textDidChange:, let’s modify the UISearchBar so there is a signal representing changes to the text.

@implementation UISearchBar (RAC)
- (RACSignal *)rac_textSignal {
    self.delegate = self;
    RACSignal *signal = objc_getAssociatedObject(self, _cmd);
    if (signal != nil) return signal;
    /* Create signal from selector */
    signal = [[self rac_signalForSelector:@selector(searchBar:textDidChange:) 
                    fromProtocol:@protocol(UISearchBarDelegate)] map:^id(RACTuple *tuple) {
        return tuple.second;
    objc_setAssociatedObject(self, _cmd, signal, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
    return signal;

A new method had been added to UISearchBar (via Objective-C “categories”: that creates a signal from the selector searchBar:textDidChange: and maps the signal so that it only ever sends the text.

h3. UISearchDisplayController

In order to know whether the UISearchDisplayController is active or not, it requires that two delegate selectors are subscribed to: searchDisplayControllerDidBeginSearch: and searchDisplayControllerDidEndSearch:

@implementation UISearchDisplayController (RAC)
- (RACSignal *)rac_isActiveSignal {
    self.delegate = self;
    RACSignal *signal = objc_getAssociatedObject(self, _cmd);
    if (signal != nil) return signal;
    /* Create two signals and merge them */
    RACSignal *didBeginEditing = [[self rac_signalForSelector:@selector(searchDisplayControllerDidBeginSearch:) 
                                        fromProtocol:@protocol(UISearchDisplayDelegate)] mapReplace:@YES];
    RACSignal *didEndEditing = [[self rac_signalForSelector:@selector(searchDisplayControllerDidEndSearch:) 
                                      fromProtocol:@protocol(UISearchDisplayDelegate)] mapReplace:@NO];
    signal = [RACSignal merge:@[didBeginEditing, didEndEditing]];
    objc_setAssociatedObject(self, _cmd, signal, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
    return signal;

The implementation above does the following:

# Creates a signal from searchDisplayControllerDidBeginSearch: and maps it to YES.
# Creates a signal from searchDisplayControllerDidEndSearch and maps it to NO.
# Merges the two signals via RACSignal’s merge method where it sends the most recent signal value.

h3. Bringing it All Together

We can now replace the delegate pattern example above with this:

- (void)viewDidLoad {
  UISearchBar *searchBar = [[UISearchBar alloc] initWithFrame: CGRectZero];
  self.searchController = [[UISearchDisplayController alloc] initWithSearchBar:self.searchBar contentsController:self];
  RAC(self, searchResults) = [self rac_liftSelector:@selector(search:) withSignals:self.searchBar.rac_textSignal, nil];
  RAC(self, searching) = [[self.searchController rac_isActiveSignal] doNext:^(id x) {
      NSLog(@"Searching %@", x);

The search results are updated when the search bar’s text changes, and the search is marked as active when the search display controller is active. Moreover, if another object wanted to subscribe for changes, it wouldn’t have to go through a delegate — it could simply subscribe to the signal.

  • Chris Rittersdorf says:

    Would you have any interest in giving a talk about ReactiveCocoa at the GR CocoaHeads? I believe there would be significant interest in this topic.

    • Justin DeWind Justin DeWind says:

      Yeah, I would certainly be interested in discussing ReactiveCocoa at GR CocoaHeads. I think it would be a great topic to discuss since I think everyone should be using it. :-)

  • aceontech says:

    Extremely interesting! Been trying to implement this in a generic way myself, but couldn’t really make it work in the end. I’ll settle for implementing specific RAC categories like you have.

    Didn’t know about rac_signalForSelector:fromProtocol:, thanks for highlighting it.

  • Ruben Hansen-Rojas says:

    Yeah, but the delegate pattern isn’t designed to facilitate event subscription. The ReactiveCocoa implementation here is a functional drop-in replacement, yes. And it certainly does it well enough. But this is no longer a delegate pattern as intended by the UISearchDisplayDelegate protocol. Just nitpicking the use of the word “replace,” really.

    Otherwise, RAC looks pretty sweet.

    • Nick Weaver says:

      I totally agree. The introduction to FRP is nice however the example chosen does not look very promising. No doubt, you can do all kinds of things with categories and objc_g/setAssociatedObject to avoid subclassing, I am yet to be convinced of the readability of this delegate pattern replacement. I even see more complexity here.

  • Oliver Jones says:

    I’m sorry but all you’ve done here is replace a simple, flexible, well understood pattern (delegation) with a whole swag of complicated boilerplate for almost no benefit.

    While I understand the allure of FRP (and used it a bit when I was doing .NET) I have yet to see a compelling use case or example of it in Objective-C.

    • Justin DeWind Justin DeWind says:


      I think is a cynical view of the post. The purpose of the post was to ease individuals into FRP via a simple example using a pattern every Objective-C developer has used.

      Moreover, it was an opportunity to show how to elevate selectors into signals where the opportunities for improving other, more complicated, problems are boundless.

      Also, the delegate pattern is not very flexible or simple as complexity increases.

  • The delegate pattern is really nice, I think I’ll keep it.

  • Sergii says:

    Hi Justin, Thanks for the post.

    What about delegate methods with return values? For example:

    @protocol NSWindowDelegate
    - (BOOL)windowShouldClose:(id)sender;

    I’d like to transform this delegate method into a signal using rac_signalForSelector and specify return value?

    • Martin Hammarbrink says:


      To work with delegate methods with return values you have to create the delegate method manually and let it do the appropriate return value. Just found this out myself reading through the comments here.

  • Roy Mendoza says:

    Justin great post. Thanks for the concise brief explanation.

  • siyu says:

    When i build the example, There is a “Unknow type name ffi_cif and ffi_status” error for me.I don’t know how to fix the error. SOS

  • Jonathan Dang says:

    I think you should change your tutorial base on this issue to move delegate assign after rac_signalForSelector

  • Comments are closed.