First, thanks for reading.

Second, I’m obviously not going to tell you that RxSwift doesn’t require a certain level of mastery.

That said, everything in software does, and really the only thing that separates, say, RxSwift from Swift generics, is that today Swift developers are more likely to encounter generics and use them, and as such have little choice but to learn them and embrace the concepts.

Which brings up the point you mentioned: There’s no doubt that Combine and SwiftUI are the future… which is true.

Combine is baked deeply into SwiftUI, as it’s the core signaling mechanism that enable state and object bindings. SwiftUI not only encourages its use, it requires it.

Apple in particular, and the development community in general, have experimented quite a bit with ways of communicating state: KVO, delegates, target/action, closures… you name it. And yet they’ve bypassed those and have chosen the Reactive publish/subscribe event-stream/operator model to power their newest technologies.

So when I say that it’s a vindication of RxSwift, I’m not discussing the library per se, but the very same reactive principles that are behind Combine and RxSwift, RxJS,, RxJava, RxKotlin, and behind the many other platforms and systems to which Rx has been extended and embraced.

It’s true that there’s little need to use a third party library like Alamofire… today. That was less true just a few years ago and even more so when it was AFNetworking and the built-in iOS network support was sorely lacking.

Apple has effectively baked-in much of Alamofire’s concepts and ease-of-use, which means we no longer need that particular 3rd-party library, and they’ve done the same with RxSwift and Combine.

I see every evolution in software development: procedure programming, OOP, component-oriented programming, functional programming, reactive programing, declarative programming, and so on, as course corrections meant to avoid the shoals and reefs and the many other hazards about which we’ve learned during our journeys.

Some of those evolutions might add another level of complexity to our straight-line journey, and to return to one of your points, they may, in fact, make tracking down some particular bug much, much harder.

But I take solace in the fact that each evolution also tends to eliminate entire classes of bugs from our code.

That’s the same for minor evolutions as well. ARC cut iOS memory leak issues by 85%. Swift’s optionals, to pick another one, cut the number of null-pointer exception errors in half. Yep, tracking down a specific retain cycle may be more difficult today, but at least your code isn’t riddled with hundreds of other errors lying in wait to ambush your users.

I guess I’m saying that my main goal isn’t easy-to-debug code… it’s code with no bugs whatsoever. ;)

At any rate, I appreciate your thoughts, and again, thanks for reading, and especially for taking the time to write.