Metaverse application development: an engineering guide to shared 3D apps

A metaverse application is a real-time 3D app where several people share the same space at once. Building one means solving four engineering problems well: rendering on the devices you target, keeping shared state in sync, carrying voice with low latency, and shipping 3D content small enough to load fast. A blockchain is an optional fifth layer, not the foundation.

This page is the technical companion to the buyer's guide to metaverse development services. It is aimed at engineers and technical founders choosing a stack and planning an architecture. It assumes the 2026 landscape: standalone headsets like Meta Quest 3 and 3S, Apple Vision Pro on visionOS, WebGPU in mainstream browsers, and a market that has moved past "virtual land" toward practical uses such as training, events, design review, games and digital twins.

Reference architecture

Most shared 3D apps, whatever their theme, decompose into the same layers.

The common mistake is to design from the top layer down, starting with tokens and land. Design from the client up. If the app is not pleasant to be in at a stable frame rate, nothing else matters.

Picking the client runtime

Browser: WebGL, WebGPU and WebXR

A browser runtime gives instant access from a link. Three.js is the most widely used library and has a huge ecosystem; Babylon.js offers a more batteries-included engine with an editor and strong WebXR support; PlayCanvas adds a collaborative cloud editor. WebGPU brings compute shaders and lower CPU overhead per draw call, which matters for large scenes, but you should keep a WebGL 2 fallback for older devices. WebXR lets the same app run inside the Quest browser or Vision Pro's Safari, with varying feature support across devices.

Browser constraints are real: memory limits on mobile Safari, no guaranteed background execution, and download size that directly affects bounce rate. Treat the first interactive frame as a key metric.

Native engines

Unity is the most common choice for Quest and mobile XR, and supports visionOS through PolySpatial for shared-space apps. Unreal Engine wins on visual fidelity, large worlds and cinematic content, and its Pixel Streaming can deliver a high-end render to a browser by encoding video on cloud GPUs. Godot has matured into a credible open-source option for smaller teams who want to avoid licensing exposure; Unity's 2023 runtime-fee episode, later reversed, made many studios think harder about that.

Apple and Meta platform specifics

On Vision Pro, Apple's native path is SwiftUI plus RealityKit, with strict rules around what apps can access (for example, raw camera feeds are restricted). On Quest, OpenXR is the standard API and Meta layers its own features on top: passthrough, scene understanding, spatial anchors and shared anchors for co-located multiplayer. Plan for platform review processes when distributing through their stores.

Networking: the hard part

Multi-user 3D is a distributed systems problem with a strict latency budget. Decisions to make early:

• Authority model. Client-authoritative sync (each client owns its avatar and some objects) is simpler and fine for social spaces. Server-authoritative simulation is required when cheating matters, such as games with economies or competitive play.
• Tick rate and interpolation. Social apps can send avatar transforms at 10–20 updates per second and interpolate; fast games need more, plus client-side prediction and reconciliation.
• Interest management. Each client should only receive updates for nearby or relevant entities. Without it, bandwidth grows roughly with the square of the user count.
• Sharding. Most "thousands of users in one world" claims are actually many instances of the same room. Decide which experiences genuinely need a single shared instance (a keynote) and which can be sharded (breakout areas).
• Persistence. Separate ephemeral room state (who is standing where) from durable state (inventory, placed objects) and write the latter to a real database, not the realtime server's memory.

Voice and presence

Voice usually matters more to users than graphics. WebRTC with a selective forwarding unit (SFU) is the standard pattern: each client uploads one stream, and the SFU forwards relevant streams to others. Spatial audio is then applied on the client based on avatar positions. At scale you need per-room limits on how many voices are forwarded, a TURN relay for users behind restrictive networks, and moderation features such as mute, block, push-to-talk and the ability for hosts to control who can speak. Presentation stages often switch to a one-to-many broadcast model (HLS or low-latency streaming) for the audience while keeping interactive voice for the speakers.

The 3D content pipeline

Teams underestimate content more than any other part. A workable pipeline looks like this:

1. Author in Blender, Maya, 3ds Max or from CAD/BIM sources, with agreed scale, units and naming conventions.
2. Convert to an interchange format: glTF/GLB for real-time delivery, OpenUSD when you need composition, layering and interchange with tools like Omniverse.
3. Optimize: decimate meshes, generate levels of detail, bake lighting where possible, compress geometry (Draco or meshopt) and textures (KTX2 with Basis Universal).
4. Validate automatically against budgets: triangle count, material count, texture memory, file size. Fail the build when an asset exceeds them.
5. Version and deliver through a CDN with cache-busting, and stream assets progressively so users can start interacting before everything loads.

Newer capture techniques such as Gaussian splatting can produce convincing real-world scenes from photos or video. They are excellent for viewing, but less suited to interactive scenes that need collision, relighting or editing, so many teams combine a splat backdrop with conventional meshes for anything users touch.

Performance budgets by device

Write budgets down before content production starts. The numbers below are typical starting points rather than hard rules; profile on your actual target hardware.

In VR, a dropped frame is not cosmetic. It causes discomfort. Design locomotion with comfort in mind (teleport and snap turning options), avoid forced camera motion, and test with people who are prone to motion sickness.

Where blockchain fits, if at all

Ask whether the app needs users to own and trade assets independently of you. If not, skip it. If yes, keep the chain at the edges:

• Represent tradable items as ERC-1155 (fungible or semi-fungible items like wearables) or ERC-721 (unique items such as named land parcels), following the ERC-1155 specification.
• Keep gameplay and presence off-chain. Read ownership from an indexer and cache it; never block a frame waiting for an RPC call.
• Use a low-fee network (an Ethereum layer 2 or an app-focused chain) for item transfers; the trade-offs are covered in the guide on scaling with layer 2 and interoperability.
• Reduce wallet friction with embedded wallets or smart accounts (ERC-4337, and EIP-7702 delegation since Ethereum's 2025 Pectra upgrade), so new users are not forced through seed phrases on first visit.
• Have contracts audited and plan an upgrade or migration path. Bridges have been a recurring point of failure; the 2022 Ronin bridge hack that hit Axie Infinity is the standard cautionary tale.

For item economies and in-world trading specifically, see metaverse NFT game development and the metaverse NFT marketplace guide.

Platform services you still need

The unglamorous backend decides whether the app survives launch.

• Identity: email or social login, enterprise SSO via SAML or OIDC for workplace and training apps, and guest access for events.
• Trust and safety: reporting, blocking, personal boundaries, voice moderation, audit logs, and age assurance where laws like the UK Online Safety Act or US COPPA apply.
• Content management: a CMS so non-engineers can update posters, videos, schedules and products without a new build.
• Analytics: session length, return rate, heatmaps of where people go and where they get stuck, frame-rate telemetry by device.
• Live operations: autoscaling for event spikes, feature flags, crash reporting and an incident playbook.

A realistic build sequence

1. Prototype one room on the weakest target device with real networking and voice for 10–20 users.
2. Load-test to your peak concurrency with bots, including voice, before investing heavily in art.
3. Lock asset budgets, then run content production in parallel with systems work.
4. Add identity, CMS, moderation and analytics.
5. Add the ownership layer last, only if the case for it survived the earlier steps.
6. Run a closed beta, measure return visits, and iterate before any public launch.

Frequently asked questions