Unity New Input System Actions Not Working in Build Only - How to Fix
Problem: Your Input Actions and Player Input (or manual InputAction usage) behave correctly in the Unity Editor, but in a development or release player build nothing happens: Move stays zero, Jump never performs, or UI never receives Submit/Cancel. You may see no errors, or occasional warnings about missing assets.
Root cause (typical): The Editor loads all your scenes and assets while you iterate, but builds only ship what is referenced from the first scene, included in Resources, or pulled in by Addressables. Separately, IL2CPP managed stripping, UI Input Module configuration, or platform focus (Android touch, fullscreen standalone) can block the same code that worked in Play Mode.
This article assumes the Input System package is installed and Active Input Handling is already set to Input System Package (New) or Both. If input fails everywhere including the Editor, start with Unity Input System Not Working - New Input System Fix.
Quick fix checklist
- Confirm the first scene in Build Settings contains a PlayerInput (or your bootstrap) that enables the correct action map.
- Verify the Input Action Asset is referenced by a scene object or prefab in the build, not only by an Editor-only test scene.
- For IL2CPP, rule out managed stripping removing Input System types used via reflection; add a link.xml preserve if your project uses heavy reflection on actions.
- Check Event System uses Input System UI Input Module when your UI should receive UI actions; mismatched modules can steal or drop events in builds.
- On Android, test with Run In Background and ensure nothing requests exclusive focus; confirm touch bindings exist if you expect touch rather than keyboard.
Step 1 - Validate build settings and boot scene
- Open File > Build Settings.
- Note the scene at index 0. That scene always loads first in a player build.
- Ensure your PlayerInput (or script that calls
Enable()on your asset) exists in that scene, or is created immediately from a persistent loader (e.g.DontDestroyOnLoad) that runs from scene 0.
Verification: Add a temporary Debug.Log("Boot OK") in Awake on the same object as PlayerInput in the boot scene. Confirm it appears in Development Build logs.
Common mistake: Testing in the Editor with a different startup scene than the one at the top of Build Settings.
Step 2 - Ensure the Input Action Asset is included
Unity includes assets referenced by serializable fields on objects in built scenes. Failures often come from:
- Loading the asset only via
Resources.Loadpath typo (case sensitivity on some platforms). - Addressables or AssetBundles where the asset was never marked Addressable or the catalog is stale.
- Runtime Instantiate of a prefab that lives only under Editor folders (excluded from builds).
Fix:
- Select your Player Input component and confirm the Actions field is assigned (not Missing).
- If you load actions from code, log
asset != nullon device or use Development Build file logging. - For Addressables, build a local catalog and confirm the InputActionAsset address resolves on first run.
Verification: Create a minimal build with one scene containing only PlayerInput + your asset. If that works, reintroduce systems until the break reappears.
Step 3 - IL2CPP and managed code stripping
On IL2CPP targets, Managed Stripping Level can remove types that appear unused. The Input System is usually safe, but custom wrappers using reflection or ScriptableObject indirection can break.
Fix:
- Edit > Project Settings > Player > Other Settings – temporarily set Managed Stripping Level to Minimal (or Low) and rebuild.
- If that fixes input, identify stripped types and add a
link.xmlinAssetswith appropriatepreserverules, then restore your stripping level.
Official reference: Unity manual - IL2CPP.
Step 4 - UI and the Input System
In builds, Standalone Input Module will not drive UI when you rely on the New Input System only.
Fix:
- On your Event System GameObject, replace Standalone Input Module with Input System UI Input Module (package UI).
- Ensure UI actions (Navigate, Submit, Cancel, Point, Click) are bound in the same or linked Input Action Asset the module references.
Symptom: Gameplay actions work but buttons never click in build – often this module mismatch.
Step 5 - Platform-specific notes
Windows / macOS standalone: Fullscreen focus can pause updates if Run In Background is off under Player settings.
Android: Confirm bindings for touch on UI and gameplay if you are not using a virtual stick. Some devices need low Default Screen Orientation changes retested after build.
WebGL: Input latency and focus rules differ; test in the target browser with a development build.
Alternative causes
- Duplicate
PlayerInputcomponents both enabling different maps and cancelling each other. - Time scale set to
0with gameplay that still expects input (pause menu should switch to a UI map). - Device filters on actions that exclude the device class present on hardware (e.g. only Gamepad when testing keyboard).
Prevention tips
- Keep one bootstrap scene responsible for input and DontDestroyOnLoad so every platform build shares the same path.
- Add an automated smoke test build step that loads scene 0 and asserts one InputAction performed within a timeout.
- Version your .inputactions file in Git and treat changes like API changes (review bindings in PRs).
FAQ
Should I use Player Input or pure C# callbacks?
Either works in builds if the asset is enabled and referenced. Pick one style per project and stay consistent.
Does Input System need to live in Resources?
No, if a built scene references it. Resources is only one way to guarantee inclusion.
Could Addressables break only on device?
Yes, if catalog URL, SSL, or caching differs from Editor simulation. Check Addressables diagnostics logs.
Related links
- Unity Input System Not Working - New Input System Fix – Editor-wide troubleshooting
- Input Handling - Unity New Input System vs Legacy – Conceptual comparison
- Unity Game Engine guide – Broader Unity learning path
Bookmark this page if you ship on multiple platforms; build-only input bugs recur whenever startup scenes or Addressables change. Share it with anyone on your team who says it works on my machine.