Short answer: Yes. As part of your workflow when you are requesting an update from the server; you should update your change tokens. Normally, I would see a data request flow be something like: Main: Send request to a background thread BG: Request from Server BG: Receive Payload BG: Consume Payload BG: Write to Disk BG: Notify main thread Main: Update UI With your change tokens in the store, same thing: Main: Send request to a background thread BG: Fetch change tokens to send to server BG: Request from Server with change tokens BG: Receive Payload BG: Consume Payload BG: Update change tokens in metadata BG: Write to Disk BG: Notify main thread Main: Update UI Since the entire action of updating data from the server is a single flow, there is no risk of the token being out of sync of the request. This is assuming you have one synchronous server request queue. If you are doing server requests in parallel then that will cause issues. To have parallel update requests you would need to spin them as sub operations of a master operation. When all subs are complete then the master updates the change token with a final save of the context.

I suspect the confusion stems from what a NSManagedObjectContext actually is. A context is a scratchpad that allows you to store edits to objects that you may want to save in the future. If you were to dealloc a NSManagedObjectContext before saving it, all changes go away like they never happened, including any updates to the metadata for the store. By seeing the context as a scratchpad, the metadata API documentation starts to make sense. When you update the metadata at the context level, that is a temporary change. When you save that context, you are telling the store to update its state based on what is in the context. Committing the scratchpad to permanence. Now, conflicts. If you were to change the same metadata key in two different contexts; you produced a race condition. First save wins. Second save fails with, I suspect, an interesting error.