Skip to content

Best Practices

A short set of habits that make experiences track reliably, run smoothly, and travel well across devices. Each points to the page with the full detail.

Organize your experience

  • Name your Objects and Anchors. Clear names keep a busy hierarchy legible, and they let scripts find things by name. Double-click an item to rename it. A few habits help:
    • Prefer descriptive names (Ball, InfoPanel) over the defaults (Object 1).
    • Be consistent. Pick one style – e.g. camelCase (infoPanel), PascalCase (InfoPanel), or kebab-case (info-panel) – and use it throughout, so names stay predictable in the hierarchy and in scripts (where matching is case-sensitive). Giving related items a shared prefix (ui-title, ui-slider; audio-intro) also keeps a long list scannable.
    • Keep names unique for anything a script references. scene.findEntity({ name }) matches the name exactly – capitalisation included – and returns one match, so duplicates are ambiguous.
    • Settle on a name before you script against it: renaming an Object later breaks any script that looks it up by the old name.
  • Use Scenes to chapter your experience. A Scene is a self-contained stage; larger experiences use several and move between them at runtime. See Experiences, Scenes & Objects and the Transition to Scene action.

Anchor for tracking, nudge with Transform

Place content with an Anchor by default – the anchor is what the device tracks, so it gives the most stable placement. To fine-tune from there, don't move the anchor; nudge the Object's Transform (position, rotation, scale) on top of it. The full pattern, and every anchor type, is in Anchors.

For image markers, the printed size and the image itself matter as much as the software – see the guidance in Anchors → Image (measure the physical width accurately, print with high contrast on a matte flat surface, size the marker for the distance you want to detect from).

Keep it light

Everything in an experience downloads the first time it's opened, then caches – so total size is what the first-load experience feels like.

  • Aim for a small total. Roughly 30–50 MB works well for App Clip-delivered mobile experiences. See Adding Content.
  • Lean by default, but you have room. Favor the lightest asset that still looks good – it loads faster, runs cooler, and ports to the web. Modern devices have real headroom, so right-size rather than starve; there's no single number, since a hero centrepiece, a simple prop, and a scan each warrant very different budgets.
  • Textures: 2K (2048 px) is a comfortable default on current devices; drop to 1024 for the web or when you have many objects. Bake fine detail into normal maps instead of geometry.
  • Big or high-resolution video: stream it rather than embedding it – point at an HLS stream or a manual asset URL. Keeps the whole experience light. See Adding Content.
  • Transparent video: export as HEVC with an alpha channel. A tool like Apple Compressor compresses transparent HEVC well (and spatial / stereo video too), keeping the file small. See Materials.

Adapt to the device

The same experience can run on a phone, a headset, the desktop, and the web – design for the differences.

  • Branch per device with Conditional Logic. The Platform Is condition runs different actions depending on the device – show different content, or route to a different Scene, on a headset versus a phone versus the web. See Actions.
  • In scripts, read environment.deviceCategory to do the same in code (see the scripting Feature Detection guide).
  • Design the lightest target first. Web budgets are tighter than native, so an asset that's fine on a phone can be too heavy in the browser – size down and compress for web delivery.

Reuse state with the Cycle action

To swap between a few states – change which Object is shown, toggle a look or a button's appearance – reach for the Cycle action. It steps through a set of action sets on each trigger (Loop, Ping Pong, or One Shot), so you don't need a variable and branching per state. See Actions.

Design for comfort and safety

Match session length to the device. Handheld AR is tiring to hold up, so keep those interactions brief or let users set the phone down for stationary viewing. Headset experiences are hands-free and comfortable, so they can run much longer. Either way, design for the physical space and guide the user into position.

For location-based experiences, keep the covered area bounded. A route spanning kilometres means near-continuous walking and tracking – which drains battery, heats the device, and taxes tracking and processing – and it raises real safety concerns when people watch a screen while moving. Favour shorter, contained routes over sprawling ones.

When an area is genuinely large, split it into several smaller experiences – one per location – instead of one sprawling experience. Then give each its own entry point so people start fresh at each spot rather than staying in AR the whole way:

  • A QR code or NFC tag at the location is the smoothest entry – scanning it opens that location's experience directly. See Publishing & Sharing.
  • An interactive map or website that links to each experience lets people choose where to go from an overview, out of AR.

If you do want to move straight from one experience into the next without leaving AR, the Open Link action pointing at another experience's share link opens it in place – the app confirms first, offering to restart the same experience or replace the current one.

Test on the real thing

AR depends on the device and the space it runs in – tracking, lighting, scale, and how warm the device gets all differ from the editor preview. Test on an actual device, and on-site for placed or geo experiences, early and throughout – not just at the end. The editor makes this quick:

  • Preview in AR on the device you're editing on – on an iPad you can jump straight into AR (or use the simulator on a Mac). Preview the whole experience or just a selected object to iterate on one element fast.
  • Send to Devices – the workflow to reach for. Keep the experience open in the editor, then open the same experience on another Apple device signed in to the same Scenery account. It appears as a connected device, and from then on your edits stream to it live as you make them – no re-export, no re-opening. It works across Apple devices (iPhone, iPad, Vision Pro), but not the web (WebXR). It's especially valuable for headset work, where you otherwise can't edit and wear the device at the same time.

See Editor Overview for both.