> having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning.

> having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning. Good point that we should be more explicit about threading model of Realm and its benefits. Realms and their objects can be shared across threads (and processes), you just have to be explicit about it (by having each thread get its own instances of the given objects/realms). The huge benefit you get from this, is that you never have to worry about locking or any other concurrency issues. All threads will always have a consistent view of the data, it will only update to reflect changes done by other threads at safe points in your code (like between events, where you are not in the process of using the data). > Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. You don't need 3 copies, only three instances. That way each thread will have its own instance (and as such not be affected by changes on other threads), but they will all point to the same underlying data. > I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render. With realm you don't even have to do that. You can let thread B modify the object, and then the UI thread can just watch its own instance of that same object and be notified when it changes, it can then update the UI. All perfectly safe without any need for manual synchronization between the threads.