3

Context: My team is starting a new medium size Swift project (of around 20 MM) and I am thinking to develop it in RxSwift. One of my managers suspects that once he had a bad experience about debugging on Reactive Programming so he suggests to avoid RxSwift and go with classical Swift. I am trying to find out the disadvantages of RxSwift and I found none of them, mentioned about the debuggability issues.

Question: What are the factual technical limitations of RxSwift for debuggability?

Sazzad Hissain Khan
  • 37,929
  • 33
  • 189
  • 256
  • 1
    I would say that's just a biased opinion of your manager. – Sweeper Feb 12 '20 at 06:42
  • 3
    It is only difficult to debug when you try to go through Stacktrace. If you add logs properly or even add breakpoints at proper places, i think you should be fine. – AjinkyaSharma Feb 12 '20 at 07:50
  • “Difficult” is still opinion based. Who knows what you would find difficult? Asking for actual techniques and limitations would be fine (if it isn’t a duplicate). – matt Mar 14 '20 at 13:45

1 Answers1

4

I have been using RxSwift since 2015 when it first came out. I have put it in lots of small and medium projects over the years. I wouldn't call it difficult to debug but it is different to debug. As @AjinkaSharma mentioned in the comments, following a stack trace is a very frustrating experience so don't even bother. Better is to put .debug() operators at strategic places. Another useful tool is [TimeLane][1] which will allow you to track your observables in the profiler.

More importantly, if you are having even a little bit of a hard time getting an observable chain to work the way you want, write a unit test. It is extremely easy to wrap a bit of logic into an operator and then write a test for it using RxTest and I don't know why more people don't do it other than they are used to unit tests being a pain when using MVC.

In my experience, the hardest part to debug are resource leaks. Even detecting them can be difficult unless you include the TRACE_RESOURCES flag in your debug build. Once you do that, you can put the following in your app delegate:

#if DEBUG
_ = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)
    .map { _ in RxSwift.Resources.total }
    .distinctUntilChanged()
    .subscribe(onNext: { print("♦️ Resource count \($0)") })
#endif

That way you can track the resource count when you go back and fourth between screens to make sure everything is released properly.

Lastly, the architecture you end up with is quite functional and very different than what most Swift developers are used to. When done right, you end up with more closures and free functions and fewer protocols and extensions, so that will take getting used to as well.

Join us on the RxSwift slack where there are a bunch of knowledgable and active participants who will be happy to answer quick questions or share a bit of code any time of the day.

Daniel T.
  • 32,821
  • 6
  • 50
  • 72
  • is it possible to write the debug logs from rxswift to file. – sujith1406 Dec 04 '20 at 06:49
  • Certainly. You would have to write your own operator but it can be done. Making your own operator is quite easy in RxSwift (as compared to, for example, Combine.) – Daniel T. Dec 04 '20 at 12:24
  • Yes, stack traces with RxSwift are longer and different, but sooner or later they land in non-reactive code which is much more easier to understand. I solved many reactive crashes just with the stack traces from Crashlytics. – Alexander Vasenin Apr 30 '21 at 05:46
  • TBH, that doesn't sounds like a nice experience. Especially when you're used to "set breakpoint; inspect problem" – horseshoe7 Nov 18 '22 at 07:42
  • There's a dramatic difference between "not what you are used to" and "difficult". – Daniel T. Nov 18 '22 at 11:53