This is the mirror image of adopting size classes: even after you branch on size class in new code, older idiom checks scattered through the app quietly keep forcing the phone layout.
Find them
grep -rn "userInterfaceIdiom" --include="*.swift" .
grep -rn "UIDevice.current.model" --include="*.swift" .
grep -rn "horizontalSizeClass == .compact" --include="*.swift" .The third pattern is worth checking carefully. == .compact is often used to mean “is a phone”, which is now false on the inner display — and that is usually the correct new behaviour, so confirm each site rather than mass-replacing.
What idiom is still good for
Idiom remains legitimate for genuinely platform-level questions: whether a hardware keyboard is typical, whether Catalyst-specific menus apply, whether a feature exists on the platform at all.
It is not a proxy for available space. That question now belongs to size classes and to the actual bounds you are given.
The device-detection trap
Do not replace idiom == .pad with a check for iPhone Duo specifically. Hard-coding a device model recreates the same fragility one form factor later, and Apple offers no supported way to ask “am I on a Duo”. Branch on the properties your layout actually depends on — width, size class, active reserved regions.
Cross-platform equivalents
The same pattern appears outside Swift. In React Native, Platform.isPad and any device-model library used for layout decisions. In Flutter, defaultTargetPlatform combined with a hard-coded breakpoint. Both should be replaced with live window dimensions.
How to verify
After removing idiom-based layout branches, run on the inner display and confirm you get the wide layout. Many apps discover a good iPad layout already in the codebase that was simply unreachable.