A virtual object that appears stable for a moment is not the same thing as a dependable spatial attachment. The application must decide what the object is attached to, how related objects move together, and what happens when tracking becomes uncertain. Those decisions become especially important when a scene contains more than one item.
Spatial anchors are part of that architecture. This guide explains how to reason about them without treating an anchor as a magical permanent coordinate. Use the AR API learning hub alongside this article, and begin with a small placement task before adding persistence or shared experiences.
Start with the role of an anchor
The ARCore anchor documentation explains that anchors help virtual content appear to remain in place as the system updates its understanding of the environment. Objects attached to an anchor follow changes to its pose. The documentation also distinguishes local, Cloud, and Geospatial anchors and recommends reusing anchors for nearby related objects when appropriate.
For application design, the important question is not merely “where is this object?” It is “what relationship should remain stable?” A collection of puzzle pieces may need to stay aligned with one another. A label may need to remain associated with a particular surface. Those are different attachment requirements.
Write that relationship in plain language before choosing an anchor strategy. Doing so prevents a low-level implementation choice from silently deciding how the user expects the scene to behave.
Separate object identity from anchor identity
A lesson object, product model, or annotation should have an application identity independent of its current anchor. Replacing or recreating an anchor should not necessarily create a new logical object. Likewise, deleting a virtual object should not leave unrelated application state attached to an obsolete tracking resource.
Consider a hypothetical maintenance label. Its identity describes the instruction and the component it refers to. Its placement describes the current relationship to the tracked scene. Keeping these separate lets the application preserve the instruction when it needs to ask the user to place the label again.
Document the ownership rule: which component creates an anchor, which objects use it, and which component releases it. Shared ownership without a clear lifecycle can turn a small scene into a difficult resource-management problem.
Group content according to intended behavior
Imagine a miniature solar-system exhibit on a table. The planets, labels, and decorative orbit rings should maintain their arrangement relative to the exhibit root. They do not each need an unrelated placement decision merely because they are separate meshes.
Now imagine a label on a wall and another on a freestanding display. Those objects may have different spatial relationships and may need separate attachment handling. The grouping should follow the meaning of the scene, not the number of imported files.
Create a scene diagram showing logical roots, local transforms, and attachment boundaries. This diagram can be simple enough for a designer or content author to review. If nobody can explain why two objects share an attachment, revisit the grouping before adding more content.
Make placement and attachment separate states
Before commitment, the object may follow a preview candidate. After commitment, it should follow the application's attachment model. Use explicit states for those phases. Otherwise, a model can accidentally keep following the aiming ray after the user believes it has been placed.
Define the failure path between the two states. The preview might be valid while the requested attachment cannot be completed. In that case, keep the user informed and offer another attempt. Do not freeze the preview and label it successful merely to avoid showing an error.
Our AR hit-testing guide covers the earlier placement interaction. Connect the two workflows with a clear handoff rather than letting preview code and anchor code both write the object's transform at the same time.
Treat tracking uncertainty as a user experience
When tracking is uncertain, the user needs to understand what remains reliable. A label that continues to look authoritative while its placement is questionable can be more confusing than an openly paused experience. Decide how your task should respond before uncertainty occurs.
For a decorative object, a subdued visual state may be enough. For a precise alignment exercise, pausing confirmation and asking for reacquisition may be more appropriate. These are product-level judgments. They should follow the consequences of a misplaced object rather than a desire to keep the screen busy.
Avoid dramatic motion as a recovery cue. Instead, explain the state in calm language and provide a deliberate repositioning action. The application should not make the person guess whether an object moved because they touched it, the environment changed, or tracking was re-established.
Do not confuse local attachment with persistence
A local experience can look stable during one session without proving anything about the next session. Before promising persistence, define what must survive: the object identity, the user's arrangement, the physical relationship, or all three. Each requirement needs its own evidence.
A saved application transform is not a complete persistence strategy when its reference frame cannot be reconstructed. Store the meaning of the placement and the information your chosen system needs, not just three coordinates whose origin may be gone later.
Similarly, shared placement needs a shared interpretation. Two clients displaying the same numerical position are not necessarily referring to the same physical point. Treat multi-device alignment as a separate feature with its own testing and recovery plan.
Design a clean lifecycle
Create resources when the task needs them and release them when the relationship is no longer used. Make the lifecycle visible in a development overlay: active logical objects, attachment roots, and objects waiting for placement. This is more useful than a single count with no context.
Test repeated placement, deletion, reset, and session exit. A prototype that works once can still accumulate stale state after several cycles. Use a scripted sequence to expose that behavior while the scene is still small.
Keep cleanup idempotent where possible: calling it twice should not produce a second failure that obscures the first. Separate application cleanup from the disappearance of a particular rendering object so a partial scene teardown does not leave hidden ownership behind.
Build an anchor regression scene
A useful fixture contains two related objects under one logical root and another object with an independent relationship. Give each a clear label and visible axes. This makes relative movement easier to observe than a complex artistic scene.
Test from different viewpoints, after interruption, and after deliberate repositioning. Record whether the expected relationships remain understandable. Do not turn a single successful trial into a universal accuracy claim; keep the conditions and limitations attached to the observation.
When a regression appears, compare the scene revision, attachment logic, and imported pivots. A visible placement change may come from a content update rather than the tracking system. A fixture with known geometry helps isolate that difference.
Practical questions
Should every object have its own anchor?
Choose attachment boundaries based on intended spatial relationships. A scene made of many meshes can still represent one logical assembly. Conversely, two visually similar objects can have independent placement requirements. Start with the relationship diagram rather than a one-object, one-anchor rule.
Can users correct placement without starting over?
They should have a deliberate recovery path when the task allows it. Preserve the object's application identity and relevant task state while returning its placement to a preview phase. This makes correction feel like part of the experience rather than a failure that erases progress.
Conclusion: preserve relationships, not illusions of certainty
A strong spatial-anchor design names what should stay together, separates logical identity from tracking resources, and explains uncertain states. It also has a complete lifecycle, including repositioning and cleanup. Those choices make a scene easier to understand and maintain.
Build a small regression fixture before adding persistent or shared placement. Then explore the spatial 3D architecture guide for the broader data contracts that keep coordinate spaces, object identity, and asset revisions from becoming entangled.
