One solution is to set the object itself to read, and in case of editing client side, create an associated object that stores all changes to that object.
Use a 'mutation' object with attributes 'attibute' 'oldvalue', 'newvalue' and 'changeddate'.
Then create logic on serverside to synchronize the original objects after synchronization from the client. You still have to introduce some conflict management in case of changes on the same attributes, or choose to overwrite older changes with newer changes.
I'd say this is a problem in web dev also.
What I'd do is if multiple people/agents can access and work on the same object, lock the object by changing the status upon opening/starting editing and making sure the status is being changed. Then logic can prevent others on picking up this object. Statuses can be exchanged with selective sync. Making sure you dont pickup on object that is being edited somewhere else would require a selective sync on the status of such an object before picking it up.
However, I would say this scenarion may be less common under architectures where people are only accessing and handling information specific to themselves. In applications where agents would pick up a ticket in a mobile app your case definately applies.