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.