Mobile
Unity
Real-time 3D, AR/VR and simulation built in Unity — by engineers who ship to real hardware.
Overview
Unity is the leading cross-platform real-time 3D engine. You build a project once — a scene of objects with behaviour, physics, rendering and input — and deploy it to iOS, Android, Windows, macOS, WebGL, games consoles, and AR/VR headsets from a single codebase. You script it in C#, working against Unity’s component and GameObject model: an entity in the scene is a GameObject, and what it does — how it moves, renders, collides, responds — is assembled from components you attach and scripts you write. The editor sits at the centre of the workflow, letting you compose scenes visually while the real logic lives in code.
Unity earned its reputation in games — it is the engine behind an enormous share of mobile and indie titles, and its Asset Store gives teams a running start on models, shaders and tooling. But the more interesting shift is outside games. The same real-time rendering and interaction that power a game are exactly what an AR try-on, a VR training simulator, a product configurator, an architectural walkthrough or a digital twin need. That is where we work: interactive 3D, AR/VR/XR, simulation and visualisation applications built in Unity with C#, not just games.
Our angle is that these are engineering projects, not content projects. A training simulation that has to run at a locked frame rate on a standalone headset, or a visualisation that must load a large model on a mid-range phone, lives or dies on performance budgets, asset pipelines and honest hardware constraints. We treat Unity as the serious application platform it is — and we are candid about where it costs you, including the platform and business-model risk that Unity’s own pricing history has forced every team to take seriously.
Best for — Interactive 3D, AR/VR/XR, simulation and visualisation applications — and cross-platform games — where real-time rendering on real hardware is the core requirement, and a senior team can hold the performance and platform-risk trade-offs.
Why teams choose Unity
One project, many targets
A single C# codebase deploys to iOS, Android, desktop, consoles, WebGL and headsets. For interactive 3D and AR/VR, rebuilding that per platform natively is rarely justifiable, and Unity’s cross-platform reach is where most of the saving comes from.
Real-time 3D without reinventing the engine
Physics, rendering, input, animation and an XR stack come in the box. You spend your budget on the experience and the domain logic, not on writing a renderer or a collision system from scratch.
A visual editor over real code
Designers and engineers compose scenes, tune materials and iterate on layout in the editor, while behaviour lives in versioned C#. That split keeps iteration fast without turning the project into something only a tool can open.
Why businesses choose Unity
- You are building interactive 3D, AR/VR/XR, simulation or visualisation, and you want it on multiple platforms without funding a native build for each.
- You value a mature engine and a deep hiring pool over a bespoke or bleeding-edge renderer that only its authors understand.
- You need real-time performance on constrained hardware — mobile or standalone headsets — and want a team that treats frame budgets as a first-class requirement.
- You want an honest read on the platform-risk and licensing trade-offs before you commit, not a vendor’s optimism.
What we build with Unity
The capabilities this technology is genuinely strong at — and what we most often build with it.
GameObject and component model
Unity structures a scene as GameObjects assembled from components — transforms, renderers, colliders, and your own C# behaviours. We use this composition model deliberately, keeping behaviour in small, testable scripts rather than a handful of god-objects that become impossible to reason about.
Scriptable render pipelines (URP and HDRP)
Unity offers the Universal Render Pipeline for broad, performant reach across mobile and headsets, and the High Definition pipeline for high-fidelity desktop and console work. Choosing the right one up front — and configuring it for your target hardware — is one of the load-bearing decisions on any real-time project.
Built-in physics and collision
Rigid bodies, colliders, joints and raycasts come as standard, which is what makes Unity a natural fit for simulation and training as well as games. We tune fixed-timestep physics against the experience, because naive physics settings are a common cause of jitter and non-determinism.
XR toolkit for AR and VR
Unity’s XR support and interaction toolkit cover the headset and AR runtimes — grabbing, teleporting, gaze and hand input — behind a common abstraction. This is why Unity is the pragmatic default for immersive work: the hard, device-specific parts are already solved and maintained.
Asset pipeline and the Asset Store
Unity imports and processes models, textures, audio and animation into optimised runtime formats, and the Asset Store supplies vetted tooling and content. We treat imported assets as engineering artefacts — with import settings, compression and budgets under version control — not as things dragged in and forgotten.
C# scripting and the editor loop
All real logic is C#, edited in your IDE and hot-reloaded into the editor for a fast iterate-and-play loop. We lean on C#’s type system and Unity’s ScriptableObjects to keep configuration and behaviour clean, which is what keeps a large Unity project maintainable over time.
Use cases
AR/VR training and simulation
Immersive training for skills that are expensive or dangerous to rehearse for real — equipment operation, procedures, safety scenarios — running at a locked frame rate on standalone headsets.
Product and architectural visualisation
Interactive configurators and walkthroughs that let people explore a product, vehicle or building in real time, changing options and viewpoints rather than watching a fixed render.
Industrial and automotive simulation
Real-time simulation and digital twins that mirror physical systems, where physics, sensor input and 3D representation have to stay in step with reality.
Cross-platform games
Mobile and indie titles, and multi-platform releases, where deploying one C# codebase to phones, desktop, web and console is the deciding advantage.
When Unity is the right choice
- Right for cross-platform games — mobile, desktop, console and web — where one C# codebase deploying to many targets is a decisive saving over building each natively.
- Right for AR/VR/XR: try-on and preview experiences, immersive training, and headset applications, where Unity’s XR support and real-time rendering are the mature, well-trodden path.
- Right for real-time 3D visualisation, simulation and training — product and architectural visualisation, industrial and automotive simulation, and digital twins — where interactivity and 3D are the whole point.
- Wrong for simple 2D interfaces or non-interactive, non-real-time needs. A brochure site, a form-driven app or a static render does not need a 3D engine, and Unity’s weight and build complexity are pure cost there.
- Reconsider when platform or business-model risk is a real concern for you. Unity is a proprietary engine with licensing costs at scale, and its 2023 pricing episode showed the vendor can change commercial terms in ways that hurt. For the highest-end AAA graphics, some studios prefer Unreal — we will say so if that is your case.
Unity: pros and cons
Strengths
- Genuine cross-platform reach — one codebase to mobile, desktop, console, WebGL and AR/VR headsets — is unmatched for interactive 3D.
- A mature, complete real-time toolset: physics, rendering pipelines, animation, input and XR support that would take years to build yourself.
- A vast ecosystem and Asset Store, plus the largest pool of 3D and XR engineers of any engine, so hiring and problem-solving are easier.
- C# is a productive, strongly typed language with excellent tooling, which makes Unity codebases more maintainable than the engine’s reputation suggests.
Trade-offs
- The 2023 “Runtime Fee” pricing controversy badly damaged developer trust. Unity later walked much of it back, but it made teams wary of platform and business-model risk, and that wariness is rational — the commercial terms are not fully in your control.
- It is a proprietary engine with licensing costs that grow at scale, and a degree of lock-in: a substantial Unity project is not something you port off the engine cheaply.
- It can be far heavier than needed for simple 2D or non-interactive work, where the build pipeline, runtime size and engine overhead buy you nothing.
- For the highest-end AAA graphics, some studios prefer Unreal Engine, and Unity can require more hand-tuning to reach a comparable top-end visual bar.
Architecture
A Unity project’s architecture is decided long before the fun 3D work starts, and it is where projects quietly go wrong. We settle the load-bearing choices early: which render pipeline (URP for broad, budget-constrained reach; HDRP for high-fidelity desktop and console); how scenes are split and loaded so a large application does not stall on a single monolithic scene; and how state and configuration are structured, typically with ScriptableObjects rather than scattered singletons. The GameObject and component model is powerful precisely because it is composable — the discipline is keeping behaviours small and their dependencies explicit, so the scene graph stays understandable as the project grows.
The other architectural axis is the target hardware. A build for a standalone VR headset, a mid-range Android phone and a desktop are different runtime environments with different memory, thermal and GPU limits, and we design the asset and rendering strategy around the tightest target from day one rather than optimising in a panic before launch. Native platform features — camera and sensors on mobile, device runtimes for AR/VR — are reached through Unity’s plugin layer, and we keep that boundary clean so platform-specific code does not leak through the whole codebase.
Performance
Real-time 3D is a performance budget problem before it is anything else. A VR application that misses its frame target does not merely feel slow — it makes people ill, so the budget is non-negotiable. We work to explicit per-frame budgets for the target hardware and profile with Unity’s own profiler and frame debugger rather than guessing: draw calls and batching, overdraw, physics cost, garbage collection spikes from careless allocation, and shader complexity are the usual culprits. The fixes are specific — batching and instancing, level-of-detail and occlusion, texture compression and atlasing, object pooling to avoid per-frame allocations, and moving work off the critical path.
The asset pipeline is half the performance story. Oversized textures, uncompressed audio and un-optimised meshes are the most common reason a build is bloated and slow, and they are invisible until you measure. We set import settings, compression and memory budgets deliberately and keep them under review, because on mobile and standalone headsets the difference between a considered pipeline and a careless one is the difference between a shippable application and one that overheats and drops frames.
Security
A Unity client is, like any distributed application, fundamentally untrusted — the build ships to the user’s device and can be inspected, so nothing that matters commercially should depend on client-side enforcement. For anything with stakes — in-app purchases, competitive scoring, entitlements, multiplayer authority — the source of truth lives on the server, and the client is treated as a display and input surface that can lie. Secrets and API keys never sit in the build, where they can be extracted from the binary or asset bundles.
Beyond that, the concerns are the ordinary ones done properly: authenticated, encrypted communication with your backend, careful handling of any personal data an AR or training application captures (camera frames and spatial data are sensitive), and disciplined management of third-party assets and plugins, each of which is code you are trusting. We keep that dependency surface small and current rather than accumulating Asset Store packages nobody owns.
Scalability
For most interactive 3D and AR/VR work, “scale” is not server traffic — the demanding computation runs on the device — it is the scale of the content and the team. A Unity project grows by scenes, assets and behaviours, and it stays maintainable only if that growth is structured: additive scene loading, addressable assets for content that ships or streams separately, and clear ownership of systems so several engineers can work without colliding in the scene graph. We plan for that structure early, because retrofitting it into a sprawling single-scene project is painful.
Where a Unity application does have a backend — multiplayer, shared state, telemetry, a digital twin fed by live data — that server side scales by the same rules as any other system, and we build it that way: a clean API boundary, stateless services where possible, and the real-time transport chosen to match the interaction. The point is to keep the Unity client and the backend as separable concerns, so each can grow, and be reasoned about, on its own terms.
Unity integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start on the target hardware, not in a comfortable desktop editor. The first thing we prove is that the experience runs within budget on the device it has to ship to — a specific headset or phone — because everything downstream depends on that being true. From there we build in vertical slices: one real interaction, end to end, on the real target, rather than a beautiful scene that has never been profiled. Performance and asset budgets are checked continuously, not saved up as a crisis before launch.
The engineers designing the architecture and the render strategy are the ones writing the C# and profiling the builds. That is what operating what we build means here: the frame-budget and platform-risk decisions are made by people who will feel the consequences on the device. You get honest trade-offs — including when Unity, or a particular pipeline, is the wrong tool — typed and structured code, and an application your team can open, understand and extend.
The service behind it
Delivered throughMobile App DevelopmentWhat we build with Unity
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Unity in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Mobile
Why teams choose us for Unity
Senior engineers only
Real-time 3D and AR/VR punish inexperience — frame budgets, asset pipelines and device quirks are unforgiving. The people making those decisions on your project have shipped to real hardware before; there are no juniors learning on your headset build.
We operate what we build
We run the applications we ship, so we optimise for how a build behaves on a warm phone or a standalone headset after twenty minutes of use, not for a thirty-second demo on a workstation.
Honest about Unity’s risks
We will tell you plainly about licensing costs at scale, the platform and business-model risk the 2023 pricing episode exposed, and when Unreal or a lighter tool would serve you better — before you commit, not after.
Typical timeline
- 01
Discovery and target definition
One to two weeks agreeing the experience, the platforms, the render pipeline and — crucially — the exact hardware and its performance budget, so the constraints are known before content volume grows.
- 02
Vertical slice on real hardware
Two to four weeks delivering one real interaction end to end, running and profiled on the actual target device, proving the budget and the architecture against reality.
- 03
Iterative build
Feature-by-feature delivery in short cycles, each running on-device, with frame budgets and asset sizes checked as we go rather than discovered at the end.
- 04
Optimisation and handover
Final profiling and optimisation to hold the frame target across the range of hardware, build and store setup, and documentation so your team can own the project.
How pricing works
- Fixed-scope builds for well-defined applications — a specific AR experience, a training simulator, a visualisation tool — quoted once the interactions, assets and target hardware are understood.
- Monthly senior engagement for ongoing product work, where scope evolves across platforms and you want continuity rather than a single fixed deliverable.
- Focused audits and rescues for existing Unity projects — performance and frame-budget problems, asset-pipeline bloat, or a stalled build — priced by the assessment.
Hire Unity engineers
Need Unity capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Unity engineersCommon questions
Do you build non-game applications in Unity, or only games?
Mostly non-game applications. Unity is a real-time 3D engine, and the same rendering, physics and interaction that power a game are what AR/VR training, product and architectural visualisation, simulation and digital twins need. That interactive 3D and XR work is where most of our Unity projects sit, though we build cross-platform games too.
Is Unity’s 2023 pricing controversy still a reason to worry?
It is a reason to go in with your eyes open. Unity’s proposed “Runtime Fee” damaged developer trust, and although the company walked much of it back, it showed the vendor can change commercial terms in ways that hurt. That platform and business-model risk is real and we factor it into the advice — it does not rule Unity out, but it should be a conscious choice.
Should we use Unity or Unreal Engine?
It depends on the target. For cross-platform mobile and AR/VR, and for most real-time visualisation and simulation, Unity’s reach, XR maturity and lighter footprint usually win. For the highest-end AAA desktop and console graphics, Unreal is often the better fit. We are happy to make that call honestly for your specific project rather than defaulting to whichever we know best.
Which platforms can one Unity project actually deploy to?
From a single C# codebase: iOS, Android, Windows, macOS, WebGL, the major consoles, and AR/VR headsets. The caveat is that “deploys everywhere” is not “performs everywhere” — each target has its own performance budget and quirks, so we design around the tightest hardware from the start rather than assuming one build fits all.
Why does performance come up so much with Unity work?
Because real-time 3D is a performance-budget problem first. On mobile and standalone headsets you have a fixed per-frame budget, and in VR missing it can literally make people unwell. Most of the engineering — asset pipelines, render pipeline choice, batching, level-of-detail, avoiding garbage-collection spikes — exists to hold that budget on the hardware you are shipping to.
Building on Unity?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.