Xcode 27.2 beta landed on September 16 with the iOS 27.2 SDK. It is full of iPhone Duo support: hinge observation, reserved regions, a new arrangement container, a whole family of vertical bar controls. There is no Duo simulator in it and no device support. Apple’s release notes say that arrives later this month, in Xcode 27.1.
Xcode 27.2 is in beta. Xcode 27.1 is the one still coming. The numbers run backwards because 27.1 is the Duo launch train and 27.2 is the ordinary next cycle, seeded first.
So you can compile against the new API today. You cannot see it work.
Which version you need
Use 27.2 beta to read the API and start moving code. Wait for 27.1 to build and ship, because that is the release with the simulator and the pose controls.
That is not a preference. The amount of screen your app gets is decided by the SDK it links against, and there are three outcomes. Built before iOS 27, you run in a narrow safe area on black. Built with the iOS 27 SDK, you reach the left of the status bar. Built with the iOS 27.1 SDK, you go full screen and your bars lay out vertically under the status bar.
Most shipping apps are in the middle tier. If you use standard controls you get a decent result by rebuilding. If you have a custom nav bar, the automatic path does almost nothing for you.
The one that will bite
On the inner display your bar buttons go vertical. That is a real API, not magic, and it has a trap in it.
var axisBehavior: UIBarButtonItem.AxisBehavior { get set }
// .automatic | .horizontalOnly | .verticalPreferred
An item marked .horizontalOnly is not shown on the inner display. Not compressed, not moved. Gone. If you set that because the item looked wrong stacked vertically, you just deleted it from the interface on the device this API exists for.
There is a second default worth knowing. When the vertical bar runs out of room, UINavigationItem.verticalBarCompressionBehavior decides who loses, and .automatic resolves to .prefersTabBar on iOS. Your bar buttons are first out unless you say .prefersBarItems.
You can turn the whole thing off with UIViewController.preferredVerticalBarBehavior, which is .automatic or .disabled. There is no case that forces vertical. You can decline it, you cannot demand it.
Hinge and fold
UIHingeInteraction in UIKit, onHingeChange in SwiftUI. Both give you an angle and a status of closed, partially open, or fully open.
Watch the seams between them. UIKit’s angle is a CGFloat, SwiftUI’s is an Angle. UIKit’s status has a fourth case, .unknown, that SwiftUI does not have. If you bridge the two layers, you are converting units and mapping enums that are not the same set.
More useful than either is reserved regions. A region is an area of your view that something else owns, either an occlusion like a camera, or a division, which is the fold. You query it off a geometry proxy in SwiftUI or UIView.ReservedRegion in UIKit, and each one hands you a frame plus the margins interactive content should keep clear.
The rule is simple. Scrollable content can run through the fold. A button on the crease is a button people miss.
What actually breaks
None of this is the hard part. The hard part is three assumptions a fixed rectangle let us get away with for eighteen years.
Orientation checks. The inner display does not honor supported interface orientations, so any layout branching on orientation is now wrong. Branch on size classes.
UIScreen.main. Deprecated since iOS 26, and meaningless on a two display device. Ask window?.windowScene?.screen and read scale from traitCollection.displayScale.
Symmetric safe area math. view.bounds.width - view.safeAreaInsets.left * 2 was always a shortcut. Use view.bounds.inset(by: view.safeAreaInsets).width and treat each edge separately.
If you ship React Native
Your app is a UIKit app, so the tier rule applies to you exactly as written. Rebuild against 27.1 and look at what happens.
None of the rest has a JavaScript surface. The hinge is an easy native module. Reserved regions are the valuable one and the harder one, because the query is per view, not a device event.
Look at the vertical bar first, because it hits apps that adopt nothing. If your navigation is a JS component drawing its own bar, you are not getting vertical layout, and you may be getting it half applied around a native bar you forgot was still there.
What I would not do is read a device model string and branch on it. One device is several shapes now.
This week
Delete the orientation branches. Fix the safe area math. Stop asking UIScreen.main questions it cannot answer. Audit any .horizontalOnly you were tempted to set.
None of that needs a simulator, and all of it is correct on every iPhone ever shipped. Then get 27.1 and spend your time on the part that needs eyes on a screen.
