So after many tries I have learned many very bad ways to design a concurrent + core data app. I think the best I’ve come up with is a singleton where every method has a callback and the singleton makes sure every core data operation happens on the main thread.
Why? Because when you want to display an objects data on the screen you are going to pull it out of managed object and assign it to some UI element. In doing this, you may fault the property causing a read, which if your context wasn’t created on the main thread, COULD cause an exception.
The alternative is to pull everything off an object into variables (copied?) and then use the variables to update the UI. Sounds super tedious, there’s gotta be another way.
I think that if you keep your commits small (so if you need to commit something huge to core data, break it up and jump on and off the main thread making only small commits each time), I don’t think you’ll see any interface jitters.
So that’s my best “simple rules” idea for now, if you’ve come up with something better, please e-mail me at firstname.lastname@example.org and I’ll post your superior design. Or I’ll try and shoot holes it in with you ;)