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

Metaverse app development means building a real-time 3D app in which several people share the same space at once. This guide is for engineers and technical founders who choose a stack and plan an architecture. It covers the client, networking, voice, the content pipeline, device budgets, enterprise uses, and the optional blockchain layer.

A shared 3D app must solve four engineering problems. It must render well on the target devices, keep shared state in sync, carry voice with low delay, and ship 3D content small enough to load fast. A blockchain is an optional fifth layer and does not replace any of the four. The metaverse development services guide covers the same topic for buyers who hire a firm.

The devices in 2026 include Meta Quest 3 and 3S, Apple Vision Pro, and Samsung Galaxy XR. Apple released a Vision Pro with the M5 chip in October 2025. Samsung released Galaxy XR on Android XR in October 2025, and Android XR supports OpenXR and WebXR. WebGPU now runs in all major browsers. Most buyers now want training, events, design review, games and digital twins, not virtual land.

Reference architecture for metaverse application development

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

Many teams start the design with the ownership layer, such as tokens and land. Start with the client instead, because the app must run at a stable frame rate and feel comfortable before any other layer adds value.

Metaverse enterprise solutions: common uses

Picking the client runtime

Browser: WebGL, WebGPU and WebXR

A browser runtime opens from a link with no install.

• Three.js is the most widely used library and has the largest set of add-ons.
• Babylon.js is a fuller engine with an editor and strong WebXR support.
• PlayCanvas adds a cloud editor that several people can use at once.

WebGPU adds compute shaders and lowers the CPU cost of each draw call, which helps large scenes. Keep a WebGL 2 fallback for older devices. WebXR lets the same app run in the Quest browser, Safari on Vision Pro and Android XR, but each device supports a different set of features.

Browsers have real limits. Mobile Safari limits memory, background execution is not guaranteed, and a larger download makes more visitors leave. Track the time to the first interactive frame as a key metric.

Native engines

Unity is the most common engine for Quest and mobile XR. Unity supports visionOS apps in the shared space through PolySpatial. Unreal Engine leads on visual detail, large worlds and cinematic content. Unreal's Pixel Streaming encodes video on cloud GPUs and sends a high-end render to a browser. Godot is an open-source engine with no license fees or royalties. Unity announced a runtime fee in 2023 and canceled it in 2024, and that episode led many studios to review their engine licensing risk.

Apple, Meta and Android XR specifics

On Vision Pro, Apple's native path is SwiftUI with RealityKit. Apple limits what apps can access, and apps cannot read raw camera feeds without special enterprise entitlements. On Quest, OpenXR is the standard API, and Meta adds its own features on top, such as passthrough, scene understanding, spatial anchors and shared anchors for players in the same room. Android XR also uses OpenXR, so much Quest code can move to Galaxy XR. Each store runs its own review process, so plan time for it.

Networking

A multi-user 3D app is a distributed system with a strict delay budget. Make these decisions early:

• Authority model. In client-authoritative sync, each client owns its avatar and some objects. This model is simpler and suits 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 positions 10 to 20 times per second and interpolate between updates. Fast games need more updates, plus prediction on the client and correction from the server.
• Interest management. Each client should receive updates only for nearby or relevant objects. Without interest management, total bandwidth grows roughly with the square of the user count.
• Sharding. Most claims of "thousands of users in one world" describe many instances of the same room. Decide which experiences need one shared instance, such as a keynote, and which can be split, such as breakout areas.
• Persistence. Separate short-lived room state, such as who stands where, from lasting state, such as inventory and placed objects. Write lasting state to a database, not to the memory of the real-time server.

Voice and presence

Users usually care more about voice than about graphics. The standard pattern is WebRTC with a selective forwarding unit (SFU): each client uploads one stream, the SFU forwards the relevant streams to other clients, and the client applies spatial audio based on avatar positions. A large app also needs these parts:

• A per-room limit on how many voices the SFU forwards.
• A TURN relay for users behind strict networks.
• Mute, block and push-to-talk, and host controls over who can speak.

Presentation stages often send the audience a one-to-many broadcast, such as HLS or low-latency streaming, while the speakers keep interactive voice.

The 3D content pipeline

Teams underestimate content work more than any other part. A working pipeline has five steps:

1. Author. Create assets in Blender, Maya or 3ds Max, or import them from CAD or BIM sources. Agree on scale, units and naming rules first.
2. Convert. Use glTF/GLB for real-time delivery. Use OpenUSD for scene composition, layering and exchange with tools such as NVIDIA Omniverse.
3. Optimize. Reduce mesh detail, generate levels of detail and bake lighting where possible. Compress geometry with Draco or meshopt and textures with KTX2 and Basis Universal.
4. Validate. Check each asset automatically against budgets for triangles, materials, texture memory and file size, and fail the build when an asset exceeds a budget.
5. Version and deliver. Serve assets through a CDN with versioned file names, and stream them in stages so users can start before everything loads.

Gaussian splatting creates realistic scenes from photos or video. Splats work well for viewing, but they suit collision, relighting and editing less well. Many teams therefore combine a splat background with ordinary meshes for anything users touch. Khronos published a glTF extension for splats as a release candidate in February 2026.

Performance budgets by device

Write budgets down before content production starts. The numbers below are common starting points, so profile on your real target hardware.

In VR, a dropped frame causes discomfort. Offer comfortable movement, such as teleport and snap turning, and avoid camera motion the user does not control. Test with people who get motion sickness easily.

Where blockchain fits

First decide whether users must own and trade assets outside your control. If they do not, leave the blockchain out. If they do, keep the chain at the edges of the app:

• Represent tradable items as ERC-1155 tokens for wearables and other items with many copies, or as ERC-721 tokens for unique items such as named land parcels. The ERC-1155 specification defines the multi-token standard.
• Keep gameplay and presence off-chain. Read ownership from an indexer and cache it, and never make a frame wait for a blockchain RPC call.
• Use a low-fee network, such as an Ethereum layer 2 or an app-specific chain, for item transfers. The guide to layer 2 and interoperability covers the trade-offs.
• Use embedded wallets or smart accounts, so new users do not have to handle a seed phrase on the first visit. ERC-4337 defines smart accounts. EIP-7702, live since Ethereum's Pectra upgrade in May 2025, lets a normal wallet delegate to smart-account code.
• Get the contracts audited and plan an upgrade or migration path. Bridges are a frequent point of failure: in March 2022, attackers took about $620 million from the Ronin bridge used by Axie Infinity.

The guides to metaverse game development services and to metaverse NFT marketplace development cover item economies and in-world trading.

Platform services

The backend decides whether the app stays up after launch.

• Identity. Email or social login, enterprise SSO through SAML or OIDC for workplace and training apps, and guest access for events.
• Trust and safety. Reports, blocking, personal boundaries, voice moderation and audit logs. Add age checks where laws such as the UK Online Safety Act or the US COPPA Rule apply.
• Content management. A CMS lets non-engineers update posters, videos, schedules and products without a new build.
• Analytics. Session length, return rate, maps of where people go and get stuck, and frame-rate data per device.
• Live operations. Autoscaling for event peaks, feature flags, crash reports and a written plan for incidents.

A realistic build sequence

1. Build a prototype of one room on the weakest target device, with real networking and voice for 10 to 20 users.
2. Load-test to your peak user count with bots, including voice, before you spend heavily on art.
3. Set the asset budgets, then produce content in parallel with systems work.
4. Add identity, the CMS, moderation and analytics.
5. Add the ownership layer last, and only if the earlier steps still show a need for it.
6. Run a closed beta, measure return visits and make changes before any public launch.

Frequently asked questions