Reactive Programming with Swift

4 (2 reviews total)
By Cecil Costa
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction to Reactive Programming

About this book

Reactive programming helps you write applications that are more powerful and efficient. You can write more software, help more people, and create applications that scale. Reactive programming is a growing paradigm that we will help you set to work in Swift.

Reactive Programming with Swift guides you through migrating from the traditional way of developing to the new ReactiveCocoa framework, which uses Swift as its main programming language. You will learn how to develop with this framework, debug code, create unit tests, use additional frameworks, and convert a traditional framework into a ReactiveCocoa one.

Starting with a crash course on the fundamental concepts of Reactive programming, we’ll set you up so you’re ready to create reactive applications. We’ll then move on to topics such as Graphical events, Streaming, and Core data, which will help you dive deeper with advanced programming. The concept of switching your programming concepts from imperative to functional reactive programming will also be covered. By the end of this book, you will be able to successfully create highly functional apps using Swift.

Publication date:
April 2016


Chapter 1. Introduction to Reactive Programming

Every day, you'll find something new to explore in terms of computer programming languages. These can be in the form of a new programming language, framework, methodology, or even a new paradigm. You can work with all of these to solve a problem or improve a development process. Reactive programming is a new paradigm that is no exception to this. The philosophy behind this new paradigm is that an application needs to focus on what to do and not how to do it. This chapter introduces what this paradigm is about, where it came from, and what ReactiveCocoa is.

In this chapter we will cover:

  • What is reactive programming?
  • The history of reactive programming
  • Paradigms – imperative versus declarative
  • What is functional programming?
  • Choosing reactive programming
  • Swift – interactive, safe, and fast
  • ReactiveCocoa extensions
  • Migrating to ReactiveCocoa
  • The future of reactive programming

What is reactive programming?

Reactive programming is a computer programming paradigm that's based on the propagation of change. What does this mean? A short answer to this can be that when something changes (the value of a text field, variable value, and so on), other objects that depend on this value must be notified and react according to the new value.

To visualize it, let's take a look at an example. Imagine that you have a home automation application. Your application must react according to the device's state; for example, if the front door is open, your application must know that someone is coming in. Therefore, it can then switch on the light. When the light is switched on (it doesn't matter whether it is done because someone has opened the door or manually switched it on), the security camera must search for the person in the room and try to recognize them. If the person has not been recognized, the alarm should ring, but if the person is recognized, the alarm must react by shutting down. The following diagram explains this idea to you in a more visual way:

Keep in mind that everything works like a chain. When the lights are on, your application must also react by changing its switch state and icon, the camera preview button must be enabled, and so on.

Once you have understood the previous example, you will have a basic idea of what reactive programming is; however, you may think that this application can also be used without including reactive programming. You can, of course, do this, but the problem lies in how you do it.

The traditional style of programming is based on how to do things. This means that you have to create many observers, making development more difficult and fragile as you have to be aware of every part of the chain, especially when adding new requirements.

Reactive programming is based on a different way of development. Basically, you just have to create rules and when anything happens, the rules are to be followed. It is different from the traditional way as you have to think about how everything works and then create rules. Continuing with the previous example, in the traditional way of programming, you have to worry about whether the light switch icon is on the screen or not. Therefore, when you return to the screen where this icon shows up, you have to check its status using the viewDidAppear method. With reactive programming, you usually don't have to worry about this.

When developing on iOS, you have to remember a few patterns, such as MVC, KVO, and notifications, making the developer's life a bit complex as it is necessary to remember every detail of each pattern. This can include unsubscribing the observer using the deinit method. Reactive programming tries to merge these patterns and make everything work in the same way.

In a nutshell, an application can have a lot of states. With traditional programming, you have to be aware of all of these states, making development very complex and hard to follow. Reactive programming creates a new approach where the developer doesn't need to be worried about the complexity of states and their internal details; they just need to know the main idea behind the application flow. Here's one definition of reactive programming: it involves programming around data flows and the propagation of change.

This propagation of change is mainly based on two concepts, signals and streams, which are going to be explained in the upcoming chapters.

The history of reactive programming

Since the time that computers were invented, human beings have started looking for better ways of programming with the understanding that this would solve their problems. Some of the traditional problems in computer programming include performance, maintenance, development speed, and so on.

When some programming languages (mainly object-oriented programming languages) were being created with abstraction as their main feature, at that time it was very questionable because some people couldn't accept that hiding the internal implementation would create a better software. Nowadays, developers and companies understand that abstraction is important as most of the time, there is no sense developing at a very low-level. Besides this, a function or method implementation can be changed completely without changing its header or class definition.

In the 90s, design patterns were presented to the world in a book called Design Patterns, written by the "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) by Pearson. The idea behind these patterns was to create templates that could speed up development and make software maintenance easier. An example of a famous design pattern is  (Model-View-Controller (MVC).

The MVC pattern could also mean Massive View Controller; therefore, a new pattern had to be created. Microsoft created a new pattern called Model-View-ViewModel (MVVM) in the late noughties. This pattern was based on binding data with a view.

After MVVM was created, Microsoft created a framework called (Reactive Extensions (Rx). The idea behind this framework was to make it possible to perform reactive programming with .NET mainly by propagating it with the changes made using LINQ. This is the reason why searching for reactive programming on the Internet might take you to some websites that use the following logo:

Nowadays, you can develop software using reactive programming in different languages; for example, you can use ReactiveX and Rx.PHP if you develop on PHP, RxPY if you develop on Python, or even Reflex if you develop on Perl.


Some frameworks are based on Rx and some are not. Before using a specific reactive framework for your programming language, it is a good idea to check its features and other users' opinions. Remember that reactive programming is a relatively new programming concept; therefore, some frameworks are still quite young.


Paradigms - declarative versus imperative

When we talk about programming, it is mostly understood that we are talking about the imperative paradigm, where a developer tells the machine how to perform a task step by step. C, for example, is an imperative programming language as you have to write every instruction in order to retrieve the desired result.

The declarative paradigm, in contrast, tells you that you have to code what you want in order to make the machine do what you want it to do, but it doesn't matter how you do this. You can look at SQL as a declarative programming language as you don't really know how data is stored. All you have to do is write a statement, such as the SELECT statement, and then you receive your result.

For a more visual result, let's compare some code: one using the imperative paradigm and the other one using the declarative paradigm. Imagine that you want to apply VAT to the prices that are in an array using imperative programming. To do this, you may have to iterate through every element in the array and remember some details; for example, an array in Swift starts at position 0, and the count property is beyond the bounds of the array. Have a look at the following code:

let prices:[Double] = [10, 8.1, 20.15] 
var pricesVAT:[Double] = [Double]() 
for i in 0..<prices.count { 
    var newPrice:Double = prices[i] * 1.2 

Now, let's create the equivalent code to this using the declarative programming approach. Basically, we are going to use the map function to make the final code more readable:

var pricesVAT = [10, 8.1, 20.15].map { (element) -> Double in 
    return element * 1.2 

In the preceding code, we just describe what we want to do, rather than how to do it, how an array works, and so on.

If you've understood the difference between the code, remember that reactive programming is a branch of declarative programming. This means that it can be simple for a new developer or a bit hard for a developer who has been working with imperative programming for a long time.


If you explore declarative programming and reactive programming further, you will see that between them there's another category called dataflow.

This paradigm is based on values that change over time. A typical example of this is the comparison of variables with a spreadsheet. Let's assume we have the following code:

var a = 9 
var b = 15 
var c = a + b 

As you see, the value of variable c is 24. What happens to the value of variable c if we change the value of a or b? The answer, as you know, is: it remains the same. Let's pretend that our application has a shopping cart: variables a and b represent the prices of two products and c is the amount to be paid. Variables a and b can change their value over time: this can be due to a change in product, discount voucher, or some other reason. In such a case, we have to remember to update the value of variable c, which can make development a bit fragile.

Now, let's visualize this sample on a spreadsheet. Let's add value 9 to cell A1 and 15 to cell B1. These cells, therefore, represent variables a and b from our previous code. Cell C1 has a formula that represents the sum of A1 with B1, something that looks like this: C1=A1+B1. Any changes made in A1 or B1 will automatically update the result of C1, and if any other cells reference C1, they will also be updated. The following screenshot shows this example in a visual way:

After comparing the first code with this spreadsheet example, you can now understand what dataflow is all about. Today's applications change values very frequently over a period of time. This can be because a device has changed its state (it's lost a network connection, for example), some information was received from the network, an animation has finished, and so on. Each of these events may change the application's status and update the UI.

Some people think that declarative programming has a lower rate of performance than imperative programming, but the reality is a bit different. Let's perform some benchmarking to check which one is faster. Create a new, single view project, and add the following code to the viewDidLoad method:

    override func viewDidLoad() { 
        let array1:[Double] = [9,15.5, 3, 18, 7.9, 5.5, 2.2, 1.89, 995, 123.3, 4, 6.2, 12.12, 7,45, 6.61, 7.1, 2.9, 3.5, 52.1, 90, 82.2] 
        var array2:[Double] 
        let start = CFAbsoluteTimeGetCurrent() 
        array2 = [Double]() 
        for i in 0..<array1.count { 
            let element = array1[i] * 3.3 
        print(CFAbsoluteTimeGetCurrent() - start) 

Execute this code, and take note of the execution time when it's in imperative mode. On a MacBook Pro with a 2.6 GHz i5 processor, it took 0.000124990940093994 seconds. Now, update the code to be a declarative one by replacing your current code with the highlighted one:

    override func viewDidLoad() { 
        let array1:[Double] = [9,15.5, 3, 18, 7.9, 5.5, 2.2, 1.89, 995, 123.3, 4, 6.2, 12.12, 7,45, 6.61, 7.1, 2.9, 3.5, 52.1, 90, 82.2] 
        var array2:[Double] 
        let start = CFAbsoluteTimeGetCurrent() 
        array2 ={ (element) -> Double in 
            return element * 3.3 

        print(CFAbsoluteTimeGetCurrent() - start) 

Execute the code again using the same simulator, and take note of the execution time. Using the machine and simulator we saw previously, it took 0.0000889897346496582 seconds.

Why? The reason for this is that a declarative function might be optimized by the compiler or built-in libraries, while when using an imperative function, you have to optimize yourself.

This reasoning behind this is simple logic: if you compare the execution of a SQL SELECT statement with code that's built from scratch you can think about which one has a better performance. How long does the SELECT statement take to filter 50,000 records from a table of 1,000,000 records? How long would it take if you had to write an equivalent filter using imperative programming?


What is functional programming?

Once you read up on reactive programming, you will also find something called functional reactive programming (FRP). Functional programming is a declarative programming paradigm that avoids the changing of variable status and mutable data.

Functional programming has a few features, such as first-class functions (you can send functions as arguments, like you do in Haskell), immutable data, reducing, pipelining, recursing, currying (functions with multiple parameters), and monads. However, some authors prefer describing it as programming with functions that have no side effects, which means that a function doesn't change any data outside of it.

Let's take a look at a sample of nonfunctional programming for a better understanding. Have a look at the following code, and pay attention to how it changes an external value:

func changeSingletonValue(){ 
    let singleton = Singleton.instance() 
    singleton.setValue("New Value", forKey: "MyKey") 

This code is a side effect, and this is what you have to try to avoid when using functional programming; try to use more deterministic functions that don't use global variables.

Using methods, such as map (as we saw in a previous sample), reduce, sort, filter, and other samples of functional programming, ensures that you send functions as arguments and don't use external stuff.

To sum up, there are frameworks that are reactive but not based on functional programming, and there are other frameworks, such as ReactiveCocoa, that are reactive and functional.

Choosing reactive programming

One difficult question you may ask yourself is, "When do I have to use reactive programming?" Basically, there is no right or wrong answer to this question; however, there are some questions that you have to ask yourself. If your application (or framework) needs to synchronize asynchronous calls, if you would like to merge different patterns (MVC, KVO, notifications, and so on) into one, or if your application needs to check a lot of rules before before performing some operations, reactive programming is probably right for you.

Different industries have started using reactive programming, such as the robotics industry, the health industry, the tourism industry, the gaming industry, and even traditional mobile applications that need to use different asynchronous features. These may include GPS and other sensors.

Another good news about using reactive programming, and in this case, ReactiveCocoa, is that it is ready for failures. When using imperative languages, such as C or Pascal, the developer needs to check for errors very frequently and changing the application status can be a hard task. Object-oriented programming (OOP) usually works with exception propagation, which is a better approach, but it can sometimes also be hard to use. ReactiveCocoa usually considers two calls when trying to perform a task: the first one deals with how to react in case of success, and the second deals with how to react in case of an error.

When should you not use reactive programming? This is hard to answer. There may not be a particular reason for not using reactive programming. Only if it conflicts with any other library that's used on your project should you not consider using it.


Swift - interactive, safe, and fast

The Swift programming language was announced by Apple in the middle of 2014. The idea was to create a new programming language that would replace Objective-C. This way, it could have a cleaner and safer language without the limitation of retaining C's language syntax. This new programming language needed to be compatible with Objective-C as they would basically share the same space for a long time; however, Swift borrows some features from other programming languages (such as Haskell), allowing you to program more like a functional paradigm.

Swift is now open source; this means that more people can improve this language by adding new features, fixing bugs, and optimizing it. One point of view is that it is good that this language is continuously evolving, but on the other hand, the syntax also changes frequently. If you check the first Worldwide Developers Conference (WWDC) 2014 when Swift was first announced, you will see a few features, such as the following ones, that are out of date:

Some people say that Apple will stop supporting Objective-C soon or later, and other people say that there will be features that are available only for Swift. This actually already holds true for a protocol-oriented feature, for example. It doesn't matter whether these rumors are true or not. It is very clear that Apple will be focusing more on Swift than Objective-C from now on.

Keeping this fact in mind, take care when updating Xcode to ensure that the version of ReactiveCocoa is compatible with the newest version of Swift. In case of compiler errors, remember that you can always try to update your project and the ReactiveCocoa framework by clicking on the Edit menu, opening the Convert option, and then selecting the To Latest Swift Syntax... submenu, as shown in the following screenshot:

If you have problems with ReactiveCocoa and the new version of Swift, first check whether there is a new version of the framework before trying to fix it by yourself.

There are different ways to program with Swift; therefore, it is considered a multiparadigm programming language. FRP with Swift requires knowledge about closures more than using a target-action pattern, which is based on the selector of object methods.


The ReactiveCocoa project

Since the time reactive programming has increased in popularity, a variety of languages have started their own framework that allows programmers to develop using reactive programming; Swift is no exception to this. This project was created by Josh Abernathy and Justin Spahr-Summers, two GitHub employees who realized tha GitHub client on Mac had many network calls and they could solve some bugs related to it in a different way. The authors of ReactiveCocoa define it as a Cocoa framework that helps compose and transform streams of values. This project, also called RAC, has the following image as its logo:

This project was started in March 2012 by Josh Abernathy. As Swift did not exist at the time, it was developed for Objective-C. After the popularity of the Swift programming language, a new branch was created and ReactiveCocoa was then ported to Swift. When the process was completed, version 3.0 of ReactiveCocoa was released with Swift as its main language.

If you still have projects that use Objective-C and you would like to use ReactiveCocoa, don't worry: you can still do this as Swift and Objective-C can exchange calls between each other. You can read more about this bridging at

An alternative to using ReactiveCocoa is RxSwift. The main difference between them is that RxSwift was a port of Microsoft Rx to the Swift programming language. ReactiveCocoa was inspired by Rx; however, it is an independent project, and the idea does not revolve around the porting of Rx.

ReactiveCocoa extensions

Is ReactiveCocoa alone? No, it is not. Today, there are many frameworks that are based on ReactiveCocoa; thus, you don't have to worry about whether the required frameworks are compatible with ReactiveCocoa. They are probably third-party extensions of your frameworks already.

In Chapter 5, Enhance Your Application Using RAC Extensions, you will learn how to use ReactiveCoreData (RCD), a framework that combines Core Data with ReactiveCocoa; however, this is not the only framework that's based on the idea behind ReactiveCocoa. Here are a few frameworks that are based on ReactiveCocoa.

  • ReactiveCocoaLayout (RCL): This describes a way of creating layouts with code in a reactive way. This project is still in the alpha phase, and some people have complained that everything you do is based on code, not on Interface Builder (IB). However, for people who think that code is everything, it might be a great solution. Check out this project at
  • ReactiveAnimation: This is a framework to create animations for iOS and OS X. You will find a good example of it for Mac. For more information on this framework, visit
  • ReactiveCocoaIO: This is a file manager that's based on reactive programming. This framework replaces NSFileManager, and because it works in an asynchronous way, it is supposed to be faster. For more information on this framework, take a look at

Migrating to ReactiveCocoa

A question you might ask yourself is, "How painful is it to migrate to ReactiveCocoa?" This, of course, depends on the size of your project, its complexity, structure, and and so on; however, there are some rules that you can follow to make it easier.

The process of converting an application code into an application that's developed with ReactiveCocoa is called RACify. This process has no restrictive rule. What you have are some steps that you can follow to create the right type of signal or stream.

We are going to learn more about this process in Chapter 7, Testing Your Application, where we are going to take a framework and convert it into one that uses ReactiveCocoa.


The future of reactive programming

Reactive programming is a relatively new paradigm; therefore, not every project uses it. However, it is now being accepted by a lot of new real-world projects.

Imagine that day by day, applications are becoming more complex for different reasons: smartphones are more powerful now, they come with a lot of sensors, and working with asynchronous calls is becoming increasingly common.

When smartphones first started gaining popularity with the first iPhone and a few Android devices, their applications were very simple, and some sensors weren't too accurate. Nowadays, however, companies have started investing in mobile applications, and you can, for example, request a taxi with your smartphone, make payments by replacing your credit card, use your phone as a boarding pass, and so on.

So, what's coming up next in terms of smartphones? You'll see a lot more features, and something that has just started gaining popularity is the Internet of Things (IoT), a concept that allows you to control home devices through your phone, as represented in the following figure:

This new concept, as you can imagine, works very asynchronously. You can try it out for yourself using the HomeKit framework. This type of development can be controlled through a simple application; however, when it progresses into becoming a complex application, you might need a better methodology in place. Reactive programming is considered the perfect framework for developing this kind of an application.

Health sensors may also be the next generation of new sensors on devices. The Apple Watch already comes with a heartbeat sensor, which submits information to your phone, and you can access it through the HealthKit. This information can also be accessed asynchronously, especially if you can compare it with data on the Internet.

A health application is a good example of an application that can be used with reactive programming. Every time, a user's health information changes, the application reacts in a different way, displaying accurate diagnostics:

What about learning? Or better yet, e-learning? Believe it or not, there will come a time when we will have to explain to our children that when we were young, we had to physically go to school. Imagine an application that teaches you how to play the piano at home with other remote students. In such a case, many asynchronous calls can be made: when you press or release a key on your piano, signals are sent to your device while it synchronizes with other students and the individual scores.



In this chapter, we learned what functional reactive programming is, where it comes from, and the advantages of using it. Now, you can appreciate that this new paradigm has had a long history, but it started out as a mature concept not too long ago.

This type of programming paradigm is trending these days as it fits the needs of the applications of today. This also makes the jobs of developers a lot easier easier.

Now that you have a better idea about reactive programming and ReactiveCocoa, be prepared because we are going to start working with the two. Don't worry if you think that some concepts look different because actually they are.

About the Author

  • Cecil Costa

    Cecil Costa, also know as Eduardo Campos in Latin countries, is a Euro-Brazilian freelance developer who has been learning about computers since getting his first PC 286 in 1990. From then on, he kept learning about programming languages, computer architecture, and computer science theory. Learning is his passion as well as teaching; this is the reason why he worked as a trainer a books author. He has been giving on-site courses for companies such as Ericsson, Roche, TVE (a Spanish television channel), and lots of other companies. He is also the author of the book Swift Cookbook first edition, Swift 2 Blueprints and Reactive Swift Programming. Nowadays, Cecil Costa teaches through online platforms, helping people from every part of the world. In 2008, he founded his own company, Conglomo Limited (, which offers development and training programs both on site and online. Over his professional career, he has created projects by himself and also worked for different companies, from small to big ones, such as IBM, Qualcomm, Spanish Lottery, and DIA%. He develops a variety of computer languages (such as Swift, C++, Java, Objective-C, JavaScript, Python, and so on) in different environments (iOS, Android, Web, Mac OS X, Linux, Unity, and so on) because he thinks that a good developer needs to learn every kind of programming language to open his mind, and only then will he really know what development is. Nowadays, Cecil is based in the UK, where he is progressing in his professional career, working as an iOS Team Lead. I would like to thank mr George Boole for making everything true or false and to Leonard Kleinrock for creating the idea of internet.

    Browse publications by this author

Latest Reviews

(2 reviews total)
Interesting read - reactive is a great idea, if tough to learn
Very good introduction to the subject.
Book Title
Access this book, plus 7,500 other titles for FREE
Access now