TL;DR: Use Unity for a non-game app when the core of the product is a real-time 3D, AR, XR or interactive scene that has to run on devices you do not fully control. Do not use it for the forms, lists, logins, settings and dashboards around that scene, because a Unity UI is slower to build, heavier to ship and worse at the boring things than React Native, native or the web. The pattern I keep landing on after the ERIS fire service platform and AR tools at ARCortex, clinical eye tracking on Vive Focus 3 at Nystag, and the Lumo interactive layer at RAQTS is a split: Unity owns the one surface that genuinely needs an engine, and a normal app stack owns everything else, with one backend as the source of truth for both.
Clients rarely ask me "should we use Unity?" They usually arrive having already decided, in one of two ways. Either someone on the team knows Unity and assumed the whole product would be built in it, or someone has heard Unity is "for games" and ruled it out for a serious business app. Both of those are the wrong starting point. The question is not what kind of company you are. It is what the hardest screen in your product has to do.
What Unity is actually good at
Strip away the games branding and Unity is a real-time rendering engine with a scene graph, a physics system, an animation system, mature AR and XR integrations, and a build pipeline that targets iOS, Android, Windows, macOS, the web and most headsets from one C# codebase. That is a very specific set of strengths, and they line up with a very specific set of product needs.
- Anything spatial. If users look at content placed in the real world or in a 3D scene, Unity has done the heavy lifting for you. AR Foundation sits over ARKit and ARCore, and the headset SDKs plug into the same project. On the ERIS XR platform for the fire service, and on AR Planes and AR Properties at ARCortex, the work was placing live information in space, and rebuilding that on a plain mobile stack would have meant writing half an engine.
- Anything that animates continuously. A screen that changes sixty or more times a second, with motion, particles, transitions and effects driven by live data, is Unity's natural habitat. The Lumo interactive platform at RAQTS sits here: an experience players watch and react to, not a page they scroll.
- Anything on a headset. For standalone XR devices, Unity is usually the default route, with the most documentation and the most vendor support. The clinical eye-tracking app I led at Nystag ran on Vive Focus 3, and I wrote in the Nystag build story why that kind of work rewards a mature, boring toolchain over a clever one.
- Visualising data you would otherwise flatten. At ARCortex we also built a CCXT crypto viewer and an AR NFT viewer, and I covered the lessons in AR data visualization. Putting data into 3D only earns its place when the spatial view tells you something a chart cannot, but when it does, an engine is the right tool.
The pattern across all of these: the product's value lives inside a rendered scene, and the scene is the thing users came for.
What Unity is bad at
Unity is equally clear about its weaknesses, and they are exactly the screens every business app is full of.
Forms and text input. Login screens, sign-up flows, payment details, settings pages and long text fields are all things native and web stacks have solved, with accessibility, autofill, password managers and keyboard behaviour handled for you. In Unity you get a UI system that can do these things, but each one costs more and behaves slightly less like the rest of the phone. Users notice, even if they cannot say why.
Lists, feeds and dashboards. Scrolling a long list of records, filtering a table, rendering a chart of last month's numbers: a React or React Native screen does this in an afternoon and feels native doing it. In an engine, it is work that buys you nothing.
App size and start-up. A Unity build carries the engine with it. For an app whose main job is showing an account page and a few lists, that is weight with no payoff, and cold start time on older Android devices can be noticeably worse.
Iteration speed for product changes. Web deploys in minutes. A Unity change goes through a full build and, on mobile, a store review. I wrote about building a Unity CI/CD pipeline at Geonode precisely because Unity builds are slow enough that you have to automate them or they eat your week. That cost is fine for the scene that needs the engine. It is wasteful for a settings screen.
Hiring. Plenty of good engineers can maintain a React Native or Next.js app. Fewer can maintain a Unity codebase well, and fewer still want to spend their time building forms in one.
The split I recommend most often
On most non-game products, the answer is not Unity or not Unity. It is Unity for one surface and a normal stack for the rest.
RAQTS is the clearest example from my own work. The product had three runtimes: the Unity Lumo interactive layer, React Native mobile apps for players, and a Next.js web portal for facilities. Lumo did the thing only an engine could do. The mobile apps did quick checks, standings and the everyday flows. The portal handled management. I went through the details in stepping in as CTO at RAQTS, and the main point is that no single runtime was forced to do a job it was bad at.
There are two ways to arrange the split.
Separate apps sharing one backend
Unity runs as its own app or on its own device, and the mobile and web apps are separate products. They never embed each other. They share accounts, data and business rules through the backend.
This is the simplest option and the one I reach for first. Each codebase stays clean, each ships on its own cadence, and a problem in one does not block a release of the other. It works well when the Unity experience runs on a different device from the rest, like a headset, a screen in a venue, or a tablet mounted somewhere.
Unity embedded inside a native or React Native app
Unity can be built as a library and embedded in a host app, so the user moves from a normal native screen into a Unity view and back. This makes sense when the 3D or AR view is one feature inside an otherwise ordinary app, such as viewing a property in AR from a listing.
It works, but it is the harder option. You now have two runtimes in one process, a bridge to pass messages between them, two build systems that must agree, and memory pressure from loading an engine on top of a full app. I only recommend it when the user really has to move between the two inside a single session. If the Unity part can live in its own app, it usually should.
The rule that makes any split work
Whichever arrangement you choose, one rule matters more than the architecture diagram: the Unity layer never owns the truth.
It is tempting to let the engine compute things because the data is right there in the scene. A score is calculated in Unity, a measurement is stored locally, a state change lives only in the client. Then the mobile app shows something different, the web portal shows a third version, and the product feels broken even though each piece works.
On every project that went well, Unity rendered and collected input, and the backend decided what was true. The Repocket SDK at Geonode taught me the same lesson from the other direction: when the same logic runs on Windows, Android and iOS, share the truth and the contract, not the platform code. It is also the same reason I keep coordinate and placement logic out of MonoBehaviours, which I described in testing AR apps in the field. Logic that does not need the engine should not live inside it.
A quick decision checklist
When a founder asks me whether their product needs Unity, these are the questions I work through on the call.
- Is the most important screen a live 3D, AR or XR scene? If no, you probably do not need Unity at all.
- Does it run on a headset or a dedicated device? If yes, Unity is very likely the right engine for that part.
- How much of the product is forms, lists and dashboards? Whatever that share is, build it outside Unity.
- Do users need to move between the scene and the rest of the app within one session? If yes, consider embedding. If no, ship separate apps on one backend.
- Who maintains it in a year? If the team is web and mobile engineers, keep the Unity surface small and well bounded so it does not become the part nobody can touch.
- What is the release cadence? If the product changes weekly, keep fast-moving logic in the backend and web, where shipping is cheap.
If the answers point to Unity for a contained piece, good. That is a strong, defensible choice. If they point to Unity for the whole product only because the team knows it, that is the decision I push back on, because I have seen what it costs to rebuild a sign-up flow in an engine three months in.
When the answer is a plain app after all
Sometimes the honest conclusion is that the "3D" idea is decoration. A product page with a rotating model, a simple animation on a dashboard, or a gentle 3D background can usually be done with web tech or a lightweight native library, and the whole product stays in one simple stack. I have more than five years in Unity and still talk clients out of it regularly. An engine is a commitment, and it should be paying for itself on every release.
The same instinct runs through the AI work I do now. In a voice agent, the expensive, specialised component (the model) should do the one job it is good at, and plain, testable code should handle everything around it. I wrote about that carry-over in going from Unity game dev to AI engineer. Pick the heavy tool for the hard part, and keep everything else boring.
I have built Unity, AR and XR systems for public safety, healthcare and sports tech, alongside React Native, Next.js and AI products for startups across the US, UK and Europe. If you are deciding how much of your product should live in an engine, more about my background is here, or book a call.