Why Apple wants you to stop designing for device poses

The guidance, directly

Apple's documentation is direct on this point: do not create custom layouts for specific hinge angles or poses. Instead, design for two size classes — compact width for the outer display, and regular width for the inner display. For tabletop or book-style poses specifically, the system is meant to handle layout adjustments automatically through reserved regions and arrangement containers, covered in more detail in our adaptive layouts guide.

Why this approach makes sense

A few reasons this constraint is worth taking seriously rather than working around:

• Hinge geometry is very likely to change across hardware generations. A layout keyed to specific angle thresholds on the first iPhone Duo has no guarantee of still making sense on a second-generation device with a different hinge range, covered in our look at what is rumored for the next iPhone Duo.
• Pose detection is inherently fuzzy. The boundary between "tabletop" and "partially open" is a judgment call, and building layout logic on top of that judgment call means your interface can flicker or behave inconsistently right at the boundary.
• Size classes are a pattern iOS developers already understand from iPad and from years of building responsive layouts across iPhone screen sizes. Reusing that mental model rather than inventing a parallel pose-based one keeps the amount of new complexity developers have to absorb much smaller.

Where hinge angle still fits in

This does not mean pose and hinge angle are irrelevant to developers — they are just not meant to drive layout. Apple's onHingeChange and UIHingeInteraction APIs exist specifically for interactive effects like pitch-bending or 3D perspective shifts, not for deciding what content goes where. See our dedicated piece on the hinge angle API for where that line is actually drawn.

The practical takeaway

If you are starting an iPhone Duo layout from scratch, the fastest path to something that holds up across hardware generations is: build with size classes and standard containers first, reach for ArrangementView and reserved regions for anything genuinely custom, and treat hinge angle purely as an input to animation and interaction, never to structural layout decisions.