Unity can share scenes, assets and gameplay code across several targets, but “one identical codebase everywhere” is not a delivery plan. Operating systems differ in input, graphics, memory, lifecycle, permissions, safe areas, storefront services, privacy and release tooling. A maintainable project shares the stable core and isolates platform-specific behaviour behind tested interfaces.
Start by naming supported target versions and devices. Unity's system-requirements page lists editor and player requirements for a pinned Unity release, but storefront submission rules can change independently (Unity — Unity 6 system requirements). Treat the release matrix as a maintained product decision.
Pin the toolchain and dependency graph
Record the exact Unity editor version, render pipeline, package lock, scripting backend, SDK, NDK, JDK, Xcode and platform modules. Commit ProjectSettings, Packages/manifest.json and Packages/packages-lock.json; exclude generated Library and build output according to the repository policy.
Upgrade in a branch with a backup and representative build tests. A project opening successfully in a new editor is not evidence that asset bundles, platform SDKs, save data or store integrations still work.
Keep secrets, signing keys and store credentials out of the repository. CI should receive them through an approved secret store with least privilege and auditable rotation. Do not put production service keys in StreamingAssets or a client script; a shipped client is observable by its user.
Build a platform-services boundary
Gameplay should request a capability rather than calling a storefront SDK throughout the project. Define narrow interfaces for services such as:
- user identity and guest mode;
- achievements and leaderboards;
- purchases and entitlement restore;
- cloud save and conflict resolution;
- sharing, notifications and review prompts;
- file paths and local persistence;
- analytics, consent and crash reporting; and
- haptics and platform overlays.
Provide a real adapter per supported platform and a deterministic development adapter. A missing capability needs a defined result—disabled, local fallback or clear error—not a null reference. Feature detection is safer than assuming every device in one platform family behaves identically.
Keep conditional compilation close to adapter boundaries. A forest of #if directives inside gameplay code makes test coverage and ownership unclear. Validate platform callbacks on the main thread if the SDK requires it, and make asynchronous completion cancellable across scene changes and app suspension.
Design input and interface for each form factor
Use gameplay actions rather than hard-coded keys. Unity's Input System is the recommended system for new Unity 6 projects; the legacy UnityEngine.Input API is documented as legacy (Unity — Input System, Unity — legacy Input API).
Provide bindings and prompts for keyboard and mouse, gamepad and touch according to the actual targets. Support hot-plug, rebinding, dead zones and multiple users where required. Touch interfaces need target sizes, finger occlusion and gesture-conflict tests; a virtual stick copied from desktop controls may not be usable.
Build layouts around anchors, content constraints and device safe areas rather than one fixed reference resolution. Test narrow, wide, notched, folded and resized viewports as relevant. Text scaling, localisation and right-to-left content can change layout more than aspect ratio.
Lifecycle behaviour also differs. Define pause, audio, networking, timers, saves and background-work policies for focus loss, suspension, termination and resume. Mobile operating systems may terminate an app without a final graceful shutdown callback, so persist critical progress at safe checkpoints.
Use target-specific quality and content budgets
One visual configuration rarely suits every GPU and thermal envelope. Create quality tiers with explicit budgets for:
- CPU and GPU frame time;
- resolution and dynamic-resolution policy;
- texture, mesh, audio and runtime memory;
- shader variants and render features;
- lighting, shadows, post-processing and particles;
- loading and streaming; and
- download and patch size.
Do not identify performance by device model string alone. Use a supported capability and quality policy with conservative defaults, then let players adjust settings where appropriate. Test thermal throttling and long sessions, not just a cold one-minute capture.
Profile a built player. Unity documents that attaching the Profiler to a development build is the most accurate way to profile the target platform; editor profiling includes editor overhead (Unity — Profile your application). Record build hash, device, scene, quality tier and capture duration.
Use Build Profiles as versioned delivery inputs
Unity 6 Build Profiles store build configurations as assets. They can preserve independent scene lists, scripting defines and platform settings for development and release variants (Unity — Build Profiles).
Create named profiles such as:
- Android development and release;
- iOS development and release;
- Windows development and release; and
- Web development and release, if supported.
Keep signing and secrets outside the asset. Add a pre-build validation step for application identifiers, version, scenes, backend, architecture, required icons, privacy declarations and environment endpoint. Generate a manifest containing editor, package and source revisions with the artefact.
Build automation must fail when expected output or tests are missing. A green compile does not mean a store-ready package; signing, entitlements, native SDKs, privacy manifests and upload validation are separate gates.
Test a matrix on physical devices
Use layers of evidence:
| Layer | Examples |
|---|---|
| Fast automated tests | gameplay model, save migration, adapters and content validation |
| Editor or headless integration | scenes, addressable content, input maps and service fakes |
| Built smoke tests | boot, first-run, suspend/resume, save, settings and shutdown |
| Physical-device journeys | input, safe area, thermal load, permissions, network changes and purchases in sandbox |
| Store validation | package, signing, declarations, required SDK and review metadata |
Select a minimum supported device, representative middle tier and at least one device for each distinct graphics or input family. Emulators are useful for automation but do not establish GPU, thermal, sensor, haptic or storefront behaviour.
Document unsupported combinations and a rollback plan. Monitor crash-free sessions, load failures, performance and service errors with consent-aware telemetry. Do not claim broad compatibility from a small lab matrix.
For help defining a Unity delivery architecture or target-device matrix, see Ozlin Info's game-development services or contact Ozlin Info.
Related reading: Cross-platform game input architecture.
General-information disclaimer
This article provides general technical information. It does not guarantee compatibility, performance, storefront acceptance or platform certification. Verify current Unity, operating-system, SDK, privacy and storefront requirements for every release.
AI-assistance disclosure
AI tools assisted with source discovery, outlining and copyediting. A human reviewer must build and test the pinned project on real targets and verify current platform-holder requirements before publication or release.
Primary sources checked
- Unity — Unity 6 system requirements
- Unity — Build Profiles
- Unity — Input System
- Unity — legacy Input API
- Unity — Profile your application
- Apple — App Review Guidelines
- Android Developers — Meet Google Play target API requirements
Source access date: 29 August 2026.
