This is not a tutorial article on a particular library for reactive programming in Swift. Instead, the author wants to figure out why and in what scenarios it’s worth using.

Improving code readability

Everyone knows about the nightmarish closures in Swift. Because of the nature of mobile development, asynchronous processes must be called in time. This used to be done with closures. Some of you may still use closures to do this, and that’s fine.

But one day you will run into nested closures. And the nightmare will begin. Reading and editing nested closures is a pain. Everyone understands that.

So how does reactive programming in Swift help reduce this pain?

You can chain observables using functions: map, flatMap and flatMapLatest. This way you can process queries simultaneously without bothering to read nested closures.

So it’s very useful to spend time making your code clearer and more readable.

This does not mean that you should stop using closures altogether. However, by using closures along with the reactive library of your choice, you can make your code more readable.

Help with event handling

In a general iOS development scenario, you need to react to events from different parts of the app. For example, someone changed their name in one controller, and you need to update it in another.

There are several scripts for such cases: delegates, notifications, and key-value pairs. Each of them works pretty well. But the reactive approach has a lot to offer.

First, reactive programming can simplify working with these scripts. All you need to do is create an observer or subject and subscribe to it. Then, every time the observer spawns an object, all the subscribers will know about it.

You can subscribe to the subject from the first controller anywhere in the program. And then use myObject for your own purposes. For example, you can skip the first two objects. You can use skip function to do that. And as I said before, you can combine the two objects using the merge and zip functions.

Make the code more modular

One of my any reactive programming features is to pass observable as variables. For example, you can pass a network request to another object and execute it when needed. This makes the code more readable and modular.

Let’s say you have controllers that need a specific type. You can use any network request with them whose observers spawn objects of the right type.

I always use this when I need overused controllers to display data to the user. Let’s take an application similar to Instagram, where you have a post object and a screen where those posts are displayed. You need to display posts from one user or the other on the same screen. Since this is most likely done with network requests, you can create the request as observable and pass it to the controller. The controller will do the rest.

Thus, the advantage here is modularity and versatility. This one controller can be reused any time you need to display a list of messages. And all you have to do is pass it to the controller. The controller will do the rest.