One Codebase for Kiosk, Mobile, and Custom Hardware
Why a single Unity codebase deploying across desktop, mobile, kiosks, and dedicated hardware keeps interactive installations cheaper to build and maintain.
Brands rarely want an experience for just one screen. A campaign starts as a kiosk, then someone asks for the mobile version, then the trade-show build needs to run on a dedicated box. Maintaining three separate codebases for that is how budgets quietly double.
The case for a shared core
Building the interaction, scoring, and backend integration once — then targeting each platform from the same source — means a fix or a content change lands everywhere at once. The platform-specific work shrinks to input, resolution, and deployment.
Where the platforms actually differ
- Kiosk: locked-down, attract loops, touch-first, must self-recover.
- Mobile: variable screens, intermittent network, app-store or web delivery.
- Custom hardware: bespoke inputs and a fixed display, tuned to the cabinet.
Designing for the shared core up front — and isolating those differences at the edges — is what makes the second and third platform cheap instead of a rewrite.
Backend comes with it
Logins, scoring, leaderboards, and the APIs a campaign needs live server-side, so every platform talks to the same data. That's what lets a single activation report on results across every screen it ran on.
The takeaway: decide early that the experience will live on more than one device, and build the core accordingly. Retrofitting cross-platform support after the fact is always the expensive path.