Write on a background queue - or maybe not

The iOS SDK documentation states the following:

Concurrency Concerns
Since transactions block each other, it is best to avoid opening transactions on both the UI thread and a background thread. If you are using Sync, avoid opening transactions on the UI thread altogether, as Realm processes synchronizations on a background thread. If a background transaction blocks your UI thread’s transaction, your app may appear unresponsive.

So that is the stated policy and yet the o-fish iOS app written by Realm developers writes on the main thread. Why is that? I’ve found it cumbersome to update a managed object with values from the UI but then write on a background queue. I was hoping the o-fish app would show me the “right” way to do it.

I believe that is a warning that’s been used across multiple drivers and doesn’t apply nearly as much for iOS (we’re looking to see whether we can remove the warning altogether).

In the work that I’ve done (including O-FISH), I haven’t hit any problems with updating Realm in the main thread (and for SwiftUI it would be a real pain to do otherwise).

My recommendation would be to go ahead and update Realm from the UI thread, but just have that warning in the back of your mind if you see latency issues.

That statement in the documentation cost me a lot of time changing code and making it more complex. It should be changed ASAP before it misleads anyone else.

Thanks for the feedback, Nina! I’ll raise this issue with the rest of the docs team to see if we can improve the wording here to avoid misleading folks – while I think we can all agree that it’s best to avoid large transactions on the UI thread in general, it’s definitely a bit more complicated than that and there are times when you need to do exactly that!

2 Likes

More guidance on when to use a background queue is needed. For example, if you should use a background queue for a large transaction, define what you mean by “large.”

2 Likes