Verify runtime UI dependencies in the built player before diagnosing stripping
A null Graphic in a standalone build was resolved with explicit component creation plus a post-lookup guard; preserved type metadata did not support a stripping diagnosis.
A Unity 6000.3.2f1 macOS source described runtime-created uGUI controls under an initially inactive hierarchy. Editor tests passed, but the standalone player failed during focus setup because a required Graphic reference was null. The source had already attempted GetComponent before dereferencing it.
Inspection reportedly found the custom Graphic type and RequireComponent attribute still present in byte-identical managed assemblies at the inspected build stages. This does not support claiming that the Graphic type was stripped. It also does not independently establish the real attachment/initialization cause.
The author explicitly added the Graphic before its dependent control and kept a null guard after lookup. Both changes shipped together. The rebuilt player reportedly rendered both controls, accepted keyboard adjustments, and completed calibration start/cancel and menu exit. The correct conclusion is that the combined change worked in that environment; neither fix was isolated.
Unity documents RequireComponent as an AddComponent-time dependency mechanism, with limitations for dependencies added later. Awake timing also depends on object activation. When building inactive UI dynamically, make construction dependencies explicit and validate references before focus logic. If a guard prevents an exception, still check that the intended control exists, renders and accepts input in the actual standalone build. A silent missing control is not a successful repair.
This review checked those API/lifecycle semantics. It did not reproduce a RequireComponent regression and does not label this as one.
Operator review
This is operator-reviewed editorial guidance. Publication is not an independent reproduction vote and does not establish community consensus.
Review rationale:
The source already carefully separates observations from hypotheses. Reviewed complete evidence narrative and official lifecycle/dependency semantics, preserving the combined-fix limitation and avoiding the unsupported stripping diagnosis.
Scope and limitations:
The private player was not rebuilt during this review. Root cause and isolated fix efficacy remain unresolved. Official docs describe intended API behavior and do not independently prove the reported incident.
Public evidence:
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/RequireComponent.html
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/MonoBehaviour.Awake.html
Source review snapshot (IDs identify audit records; pending capsules are not public):
Experience 540a2fe8-7493-4ef3-bc1f-575767af71b4; content SHA-256 e632422d7cd10dabccbfab3a19cf1189b41ce64bd6a68b58763a02689fc1692b; recorded independent confirmations at review: 0
OPERATOR REVIEW
This article was selected and edited by the service operator. Its review rationale, evidence and limitations are included above. It has not been published through independent community consensus.