Finally, Apple!

But wait… What if I have no idea what FRP is?

Well… I would say it is a good opportunity to find out ????.

Basically, dealing with Functional Reactive Programming (FRP) let’s you worry less about managing data and allows you to concentrate on how your apps should work. Here are some of the points that describe the meaning of “worry less about managing data”:

• The parts of your app might be affected.
• The amount of the (“tedious” in some cases) boilerplate code that you might need to implement (Hello Delegates, Targets-Actions, KVOs …!).
• Caring about synchronous/asynchronous changes, and how to connect their impact to the default app’s data flows.

Additionally, it might be worth mentioning that when comparing FRP with the usual standard approach(es), most of the time you’ll need to write less code to achieve the same results; It’s about performing things “declaratively”.

Less code?!

To clarify, take a look at one of the most popular cases we might achieve in our apps, which is dealing with multiple asynchronous calls. Obviously, we should think about one of the concurrency techniques, one of the proper choices would be the GCD DispachGroup. Whether the tasks are on the same queue or on different queues, we are still able to observe the execution and completion of them in the group. Example:

 

<let queue = DispatchQueue(label: “reverseDomain”, attributes: .concurrent) let group = DispatchGroup() queue.async (group: group) { performAsync01() } queue.async (group: group) { performAsync02() } queue.async (group: group) { performAsync03() } group.notify(queue: DispatchQueue.main) { // tasks executions are finished }

 

Keep in mind that the output of the asynchronous task might be a returned value, therefore, in addition to the above code, we might need to declare an instance variable to set the returned value in order to access it.

So, what about Combine?

 

let myPublisher = Publishers.Zip3(photoSubject, stringSubject, voidSubject) myPublisher.sink { (asset, string, _) in // tasks executions are finished // additionally, we can directly access the tasks (subjects) outputs }

 

Note that photoSubject , stringSubject and voidSubject are predefined Subjects (which are basically Publishers). We just applied zipping for the upstream publishers by using Zip3, and that’s all! The beauty of it is not only about the amount of code that has been written, it’s also about the used paradigm for achieving such task.

Moreover, by the time you’ll work with publishers, you’ll find out that there are many useful operators to act on the received value(s) from publishers and republish them, its awesome!

What does it mean to me as a developer?

We can see that we’ll have a chance (and it might be the only required way in the future) to change the used approaches for developing our iOS apps by using these provided frameworks. Some of the developers are keen to learn it, some of them are getting bored of having to keep dealing with all this new stuff, and the rest are just like: “yeah whatever…”.

Although I won’t say that learning and working with Combine is a must (at least for now), whether we like it or not, you should keep in mind that it exists. Perhaps we’ll see in the near future a new generation of iOS developers who only know how to settle things with Combine and nothing else! Is it possible?!

Us, the old generation.

Furthermore, you might have heard of the theory of:

In order to apply an alternative architectural design pattern such as MVVM, I have to know the “reactive programming” thing.

It doesn’t have to be absolutely correct, but it makes sense! That’s because applying a pattern such as MVVM appropriately requires two-way data binding, which is painful without following the reactive programming approach to achieve it.

By the way, am I allowed to use Combine without using SwiftUI?

Yes, you are not limited to use Combine only with SwiftUI. You can use Combine framework with UIKit, which means that you are able to build the UI part of your application as you usually do meanwhile leveraging Combine. Rejoice!

Additionally, the good news to mention is that there is a compatibility between the Foundation framework and Combine framework. Citing from Combine documentation:

Several Foundation types expose their functionality through publishers, including Timer, NotificationCenter, and URLSession. Combine also provides a built-in publisher for any property that’s compliant with Key-Value Observing.

You can combine the output of multiple publishers and coordinate their interaction. For example, you can subscribe to updates from a text field’s publisher, and use the text to perform URL requests. You can then use another publisher to process the responses and use them to update your app.

This means that it will make our lives easier when it comes to dealing with some of the Foundation types with Combine. I personally hope that we’ll see more of it in the future.

And finally:

As I mentioned before in the SwiftUI article, a declarative paradigm is already popular. Even if it’s new to you, working with it will not only be reflected on your iOS development knowledge, but it will definitely expand your general programming skills, as well as your problem solving skills. When it comes to iOS development, the beauty of it is that we have more dynamic facilities to achieve the desired patterns and approaches, it’s more like “learn it once, apply it anywhere”.

Thanks for reading!

Written by: Ahmad Fayyas

Bio: Full-time iOS developer. If I’m not in front of my PC coding or playing video games, you can find me hanging out with friends, lifting some weights or sleeping!

*Opinion disclaimer: Please note that the views, thoughts, and opinions expressed in the article above belong solely to the author, and not necessarily to Aspire as an organization.