I am trying to create an app where I have multiple users modifying an entity at runtime similar to collaborative digital sculpting using SharePlay on VisionOS. When creating a collaborative experience using other 3D engines I have utilized an external server that devices send and update their state from serving as a global "source of truth". This doesn't seem to be the intended workflow for SharePlay which seemingly only allows for device to device messaging. While this works for a variety of apps it doesn't provide a smooth experience when multiple users are interacting with and manipulating the same 3D entity. Is there an intended way to do this for SharePlay? Would the best practice be to have one user serve as a host and establish a "source of truth" based on their app state?
The closest example in documentation I have found is an example for using SharePlay in a drawing app. When a user is drawing they send the information for their realtime stroke through unreliable SharePlay messages and then, when they've finished, they send a reliable message with the final line. This technique makes sense for the given example since there is no scenario where multiple users would be drawing the same line, but it seemingly falls short for my use case since multiple users can sculpt in the same area of a given mesh. What would the intended approach be to achieve this with SharePlay? Is it simply a limitation of this type of networking? Thanks!
You can still use a server, though it's a tradeoff rather than the intended path. Nothing in Group Activities stops your app from talking to your own backend, so you can keep your authoritative server as the source of truth and use the SharePlay session for participant discovery, identity, and establishing a shared coordinate system. Device-to-device messaging is what SharePlay offers, not what it requires.
But a source of truth and conflict resolution are two different problems, and you're really hitting the second one. Picking a source of truth (server or host) decides where edits get ordered. It doesn't decide how two edits to the same spot get merged. That merge policy is conflict resolution, and SharePlay is deliberately unopinionated about it: GroupSessionMessenger delivers messages; how you merge them is up to you.
The counter in Implementing SharePlay for immersive spaces in visionOS is one such policy: a logical counter (similar to a Lamport timestamp) with participant ID as tiebreaker, which gives you last writer wins. That works for a single value like a cube color, but applied to a whole mesh it means one person's stroke discards another's. You can extend the same idea by giving each editable unit its own counter (e.g. a vertex region) instead of tracking one counter for the whole mesh. Then edits in different areas merge, and only genuinely overlapping edits conflict.
So this isn't a limitation of the networking. It's a layer SharePlay leaves to you, whichever source of truth you choose.
