A 16-year Journey of Developing VR Apps

Virtual Reality (VR) gets a lot of column inches these days, not least because more of us are working remotely. But just because VR is getting more popular, it doesn’t necessarily mean that the speed VR applications are developed has picked up in general. We see this as an excellent opportunity to be at the forefront of developing future-proof VR applications for our clients.

As with all kinds of modern application development, there are many steps in the evolutionary process that get refined over time as knowledge improves. As that happens, the fidelity of the end product improves - as does user expectation.

Over the years, we’ve seen this with web application development as people started wanting more control over their content. With the growing maturity of Content Management Systems (CMSs) and the realisation that content doesn’t always mean “HTML content”, headless has thankfully stepped beyond its trendy reputation. The market has recognised that a CMS isn’t just for HTML and people are now looking at other ways they can use their CMS to streamline their workflows.

As we started developing more complex mobile applications back in 2005, non-technical users wanted to manage content even when application development was more convoluted. Cellular networks were still not widely used for non-voice traffic and usage was costly. We decided to build our own server-side mechanisms for dealing with what was essentially binary data. Our goal was to use as little bandwidth as possible but avoid the critical design flaw of hardwiring content into the application. Downloading a new app version each time would have been cumbersome and costly for the end user.

This happened at the same time when we and many others built our own CMSs. The development curves are a precise match. Our first web applications were effectively flat HTML with hardwired content because it was still something the industry considered relatively new. There was probably even a novelty factor to it.

The question that invariably followed was, can we change content ourselves?

Today, we and many others have realised that “rolling your own” CMS just doesn’t make commercial sense as you can’t match the pace of vendors that develop their CMS every single day.

Fast forward to the present day, and we’re developing all sorts of applications that have a CMS at their core. We have always viewed mobile applications as a “remote control” for server-side applications: A mobile app gives you interactivity, tactility, and the ability to use it offline. Still, fundamentally the data at its core is almost always grabbed from a remote API - from the CMS.

Looking at VR to date, many of the bespoke applications you see still tend to be at the “flat HTML” stage. They use hardwired content and offer very little flexibility. This is partly due to leading development platforms like Unity and Unreal Engine not being too concerned with more basic network capabilities, but that’s changing - albeit at a slow pace. We believe it’s time for these applications to evolve.

Therefore, it’ll come as no surprise that our approach is to plug the CMS into a native VR application. VR applications are still just Android applications when you compile them down, so it’s not a cognitive leap to see the similarities.

We acknowledge that dynamically loaded content has not been easy to implement until more recent years because of the degree of “baking” required to maintain frame rates. However, we don’t see any difference between serving content to a VR application and a mobile application.

When developing VR walk-throughs for property companies, they occasionally want to have a different picture hanging on the wall or another range of wall colours for someone to choose from. Given the painfully cumbersome process of compiling and deploying a VR application, a little bit of extra code to manage this from the CMS saves time for everyone.

We don’t do anything particularly complicated here. The application calls the CMS’s REST API, which provides textual and rich content with timestamps, allowing the application to determine if it needs to refresh its cached content. We like to use Magnolia as our CMS because it’s got the right balance between features and complexity.

The CMS uniquely identifies the VR headsets, and our software provides the capability to assign each headset to a user. Users have roles, giving them access to certain types of content such as 3D models, virtual rooms, and panoramic videos. We can also tie users to subscriptions and payment systems, giving you complete control over the content you make available to the client application from the server-side.

Because an application could already be running on some occasions, it makes sense to use WebSockets, allowing you to change content in real-time and adding another level of dynamism to the overall experience, particularly if users see things changing around them.

When building applications on a pool of 30+ headsets, you don’t want to log each one in separately before sending it out, and you certainly don’t want the end user to do this either. Instead, we use the device’s identifier, enabling the server to automatically recognize a headset and its assigned user, eliminating the cumbersome process of entering login details. Users only have to get their headset onto their WiFi, and they’re off.

Having a solid CMS at the heart of a VR application is pivotal to delivering advanced, enterprise-grade solutions. When developing applications for healthcare or educational clients, we commonly see a pool of devices shared among many users, mainly because of the cost of headsets. By leveraging the CMS to create that extra layer of control, your investment goes further, as indeed does the principle of changing the picture on the wall.