BC-0135 · TROUBLESHOOTING
Editorial review 2026-09-26 · Official sources conflict
Roblox Build Works on One Device but Not Another
When the same account reaches Build on one device but not another, compare the same action and surface before blaming either device. Record app, input and visible requirement differences. A successful result elsewhere does not supply a complete compatibility specification for the failing setup.
Symptom
The same intended account appears to work on one device but not another.
Immediate action
Check that both observations use the same creation workflow and action.
Diagnostic branches
- Account or workflow differs between the observations.
- Label the comparison unmatched before drawing a device conclusion.
- The same creation entry is present on one device and absent on another.
- Record platform and source-scope differences and use the corresponding access guide.
- Both open the intended project but input or layout differs.
- Investigate the first different control response or visible obstruction.
- A safe second-device comparison is unavailable.
- Keep a single-device failure record without claiming the missing comparison was tested.
Least-destructive change
Compare existing authorized observations without changing hardware, projects or spending settings for the test.
Retest
- The same action and project are named on both sides.
- The first divergent state is more specific than works or does not work.
- A successful device result is not used to invent specifications for all others.
Escalation
Provide official support the matched-action table and redacted notice when the device difference remains unexplained. Include unheld variables instead of presenting the comparison as a controlled diagnosis.
Working notes
Confirm that the observations concern the same account and workflow. Playing a published game on one device and editing through Build on another are not equivalent tests. Neither is comparing a browser page with an app's creation surface.
List the variables rather than changing all of them. Record platform, app version, input method, view arrangement and the exact action attempted. A difference can explain why the comparison is inconclusive without proving which variable caused the failure.
Use already available access and projects for the comparison. Do not buy another device, create a replacement game or send additional paid prompts simply to populate the worksheet. If no safe second observation exists, retain the original failure record and its limits.
Branch at the first divergent result. If the entry is absent on the second device, investigate access and source scope. If both reach the same project but a control behaves differently, investigate that input or layout state. This preserves the useful observation instead of flattening every difference into compatibility.
Examples
- Matched-action record: same account, same existing project, same intended opening action; device A opens it, device B shows a specific notice. Preserve the notice before trying unrelated gameplay edits.
- Unmatched test: a public game link plays on a desktop while creation is attempted on a phone. The observations concern different workflows and cannot identify a device-specific creation defect.
- Divergence table: shared account/workflow / device contexts / last matching state / first different result / relevant notice / safe next observation. Untested hardware and input combinations remain unverified.