The biggest technology choice for those wishing to build XR experiences is whether to build for the web, or to build native apps. Both approaches have their advantages, and the decision will depend on your existing capabilities, what sort of application you’re building, who you’re building it for, and what hardware it will run on.
The biggest advantage of web applications is the ease of getting them in front of users. With no app store approval process, and no ‘install barrier’, developers can push features out far more easily, and can embed XR experiences directly into existing websites. A web-based approach also allows developers to bring a lot of transferable skills to XR projects. And with the web being based on open standards, you are less at the whims of individual vendors changing the platform out from under you, although waiting for APIs to be implemented by all browsers is still a challenge. Android, Oculus, Hololens, and Magic Leap have all committed to WebXR support. Unfortunately Apple are dragging their heels, leaving their much more limited, proprietary AR Quick Look the only web-ready solution on iOS. What Apple will choose to support on their upcoming dedicated XR hardware remains unclear.
Native applications’ chief advantage is better access to lower-level device APIs, which allows better performance and better control over the hardware. When building native XR apps, you’ll have to choose between a cross-platform game engine like Unity or Unreal, or directly using the SDKs of your target devices. Game engines offer the efficiency and flexibility of building once and deploying to multiple targets, while device SDKs often offer more powerful features if you are prepared to commit to that device. The importance of portability will depend on the nature of the application being built; mass-market offerings will benefit the most from portability, while industrial applications may choose to optimise for specific hardware. Existing capabilities will affect the decision as well - if you already have teams building dedicated iOS and Android apps, or if you already have experience building 3D apps using Unity, that will affect your decision.
Now that we understand some of the tradeoffs involved in selecting web technologies, cross-platform engines, or native SDKs, let’s look at some example scenarios and the choices that best suit them. We’ll consider: a) Augmented Reality for e-commerce, b) Mixed Reality for industry, and c) Virtual Reality for training and simulation.
As a mass-market application, AR for ecommerce must prioritise portability, and low barrier to entry. The more devices we support, and the fewer hurdles we put in front of customers to using our product, the greater the return on investment. This means a web-based solution is the obvious choice, and as mentioned above this also allows us to bring all our existing skills in building and deploying web applications. The main complication is Apple’s lack of support (so far) for the WebXR standard, which means that for now we are forced to implement support for both WebXR and Apple’s AR Quick Look.
When building MR for industry, we may be building a product for internal users, or selling a B2B product. In either case, we will likely be targeting specific hardware, and we shouldn’t need to worry about users’ willingness to install an app. This negates much of the benefit of WebXR and suggests a native approach may be better. Still, there are benefits to avoiding vendor lock-in, so it may make sense to start with a cross-platform framework like Unity, keeping a close eye on whether the framework can deliver everything you need. Given that MR can be quite complex, involving computer vision, object tracking, and digital twins, you may need to switch to a true native approach using the individual device SDKs in order to maximise power and performance.
Companies creating VR training and simulation will also probably know what devices they are targeting. However, VR applications are simpler than AR and VR in some ways, due to the lack of interaction with the real world, so there is less need for powerful, low-level, device-specific APIs. Given this lack of single-device benefit for VR, it’s better to choose a cross-platform solution that can survive the coming and going of hardware. Both WebXR and Unity would be reasonable choices, each having benefits. As above, WebXR is easier for web developers to adopt, and is easier to deploy and update. Unity offers a higher ceiling for rendering performance and has a richer ecosystem of VR tools and plugins.
There are many more uses for AR, MR, and VR. The three cases above should serve as examples of how to choose a platform by prioritising their strengths and weaknesses based on what you are trying to build. Technology decisions should always be based on product and customer needs, and XR is no different.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.