Locking orientation needs a hard reason

What it is

Both orientations should work by default. Locking portrait or landscape throws away the physical fact that the user is already on their side, already in a keyboard case, already unfolding a foldable. “It looks better upright” is not a reason. A racing game that assumes landscape, a camera that faces a hardware sensor, a device bolted to a mount — those are hard reasons.

A banking app that locks portrait “for security” usually just never built landscape. The user reading a balance while lying down, whole page dangling, is the product refusing physics, not security.

Why it happens

A lock pins the UI coordinate system to one short or long edge of the device, while head, hands and mounts live in another. The mismatch is not a slight awkwardness: neck compensation, one-handed use becoming impossible, or an external keyboard whose key plane fights the screen. Some tablets ignore an app lock in split view, so the layout you thought you had frozen appears in an orientation you never drew, and breaks harder.

A lock also “solves” reach by making the problem illegal: no landscape hot-zone map, therefore no landscape. That is a product constraint covering a layout debt.

Where it stops holding

Game levels, AR against a plane, an ID-scan viewfinder, an in-car mount: the lock is physics. Video playback may lock; picking a title and settings outside the player should not follow. Assistive users who clamp the phone to a wheelchair tray have the tray decide orientation; a second lock fights that environment.

Locking only a splash, or only one immersive layer, hurts less than locking the whole app. A whole-app lock needs a sentence that names physics or safety.

Applying it

• For every locked surface, write one reason that mentions a physical posture, a hardware sensor, or a safety risk. If the reason is composition, unlock and ship landscape.
• If the main canvas is locked, do not lock sign-in, settings, help, or permission copy by default.
• How to check: list every portrait/landscape lock. Write the reason beside it. Unlock any row without a physics sentence, and walk the primary path lying on a side, in a keyboard case, and in split view. Only if that walk fails may you relock, and then write the real physical cause. Then check split-view on a tablet: if the OS ignores the lock, landscape layout must exist; the lock was a false comfort.

Related

• Same group: F2.13.1 Landscape rewrites reach and kills one-handed use · F2.13.2 Rotation must keep scroll position and input state
• Nearby: F2.10 Responsive breakpoints · F1.04 Thumb hot zones · J5.09 How screen readers work
• Search terms: orientation lock · portrait only · supportedInterfaceOrientations · split view