What are the Advantages of using PromiseKit rather than RxSwift Single trait

📚 Official Books Advanced iOS App Architecture
1

If you use the RxSwift ‘Single’ trait you get a single return value instead of a stream of values. And PromiseKit could be removed and there wouldn’t be an additional dependency.

But I don’t really know if there is any advantage of using PromiseKit Instead.

2 Likes
2

@rcach @jab2109 Can you please help with this when you get a chance? Thank you - much appreciated! :]

3

Hi @itspecialists. :+1: Single is definitely an alternative to using promises. It’s a bit more nuanced than that, but it does boil down to preference. I’ll drop a more thorough response in a couple of weeks. Apologies for the quick reply, I’m currently wrapping up writing for the book. Cheers!

2 Likes
4

I still want to know the reason for this. Can you arrange some times to answer this? Thanks

5

Hi @tuanback, thanks for reaching out; apologies for the delay.

Your absolutely right. Every asynchronous chain we discuss in the book could be replaced by Singles and flap maps. And as you mentioned, the benefit is a reduction in dependencies. This is a great option if your team is going all-in on Rx. The good thing is, whether you’re using promise chains or Single chains, the architectural structures that we cover in the book wouldn’t change.

I believe there’s no ‘correct’ way to approach modeling asynchrony. The decision should be based on tradeoffs. In the book, we chose to share a different approach. It’s the approach that has worked well for me and the teams I’ve worked with. I’ve faced a couple of challenges when trying to go all-in on Rx. For me, promise chains have been easier to read and work with than Rx chains. They’re easier to debug and reason about. But that’s my experience and that’s why I think this comes down to preference. Asynchrony is hard and is often the source of hard-to-fix bugs. If I can use a simple tool for 80% of the asynchrony code I need to write, I’d rather use the simple tool. The downside to this approach is that you still need to model streams of values over time. And for that, you’d want to use something like RxSwift, ReactiveSwift or Combine. So, you still have to learn a reactive framework. The difference is how often you need to reason and debug with reactive vs non-reactive frameworks. The idea is that you pay the learning cost only once but you pay the cognitive overhead every time you use a complex tool.

So I’d say the benefits to using PromiseKit are:

  • Ease of use (easy to reason about and easy to debug) for 50-80% of typical iOS asynchrony needs
  • Default threading model that is usually what you want

The downsides are:

  • Paying the learning curve for both promise and stream based frameworks
  • Additional dependency (although PromiseKit is a really small library)

You’re likely to encounter promise APIs, especially in other platforms. So I think it’s worth learning promises whether or not you plan on using them and it might be worth experimenting a bit with the two framework approach so that you can see the differences for yourself and make the decision that’s best for you and your team. Hope this helps. If there’s anything that wasn’t clear or if you have any follow up questions please don’t hesitate to ask. Cheers.

2 Likes