CREATOR SYSTEMIndependent Roblox Build guides · Sources dated per page
Build CreatorAI game creation manualsOpen guide indexSearch
Menu

BC-0012 · CORE GUIDE

Editorial review 2026-09-26 · Official sources conflict

Roblox Build on iPad

Support's current mobile category names iOS, but it does not provide a separate iPad model or tablet-feature matrix. Record the actual iPad app entry and requirement state rather than turning broad wording into promises about tablet-specific behavior.

Objective

Record the iPad entry and input observations while leaving untested accessory behavior explicitly unresolved.

Before you start

  • Read the literal current mobile device category.
  • Identify the tablet, app version and intended account.
  • List the particular input or layout behavior you actually need to inspect.

Steps

  1. Separate documented category wording from tablet-specific questions.
  2. Check the normal creation entry on the intended account.
  3. Record any explicit requirement before testing the editor.
  4. Inspect touch and text-entry behavior in the actual orientation.
  5. Keep accessory and multitasking paths untested unless directly checked.
  6. Report the exact failing surface and context without generalizing to all tablets.

Verification

  • The record does not invent an iPad model compatibility list.
  • Entry access, account requirements and interface layout remain distinct.
  • Every claimed input result corresponds to an actual inspected method.
  • An orientation-specific issue is not generalized beyond the observation.

Limitations

  • This guide does not confirm every iPad or accessory combination.
  • It cannot inspect account rollout remotely.
  • A broad mobile category is not a detailed tablet interaction specification.

Working notes

Keep the wording literal. A mobile operating-system category does not by itself document every tablet model, orientation or accessory. If your question is about a particular iPad configuration, write that narrower question beside the source statement instead of silently treating it as answered.

Inspect the normal account workflow before testing accessory or layout assumptions. Note whether the creation entry is present, whether it is blocked by an explicit requirement and whether the editor opens. Capture the visible result in a private note without including credentials or identity documents.

After entry, check the interaction you actually need. Text entry, visibility of the generated scene and basic touch actions can be observed separately. Do not describe landscape, multitasking, Pencil input or an attached keyboard as confirmed simply because a tablet-sized screen exists.

A device observation should help frame the next question. If the interface opens but a control is obscured, that is a different problem from a missing entry. Retain the orientation and input context when describing the issue, and avoid destructive reinstallation merely to test an undocumented compatibility theory.

Examples

  • Tablet evidence row: official category wording—copy; iPad model and app version—record; orientation and input method—record; creation entry—present or absent; result after opening—record. Keep each untested accessory feature marked not checked.
  • Layout-specific observation: the entry opens, but text input covers the action needed to continue. Record that overlap and orientation; do not rewrite the observation as a universal claim that tablet access is unavailable.
  • Scope boundary: an external keyboard is connected, but only touch navigation was inspected. The result supports the touch observation, not a claim that every shortcut or keyboard interaction behaves correctly.