Apple 'Surprise and Shine' Event: iPhone Duo, iPhone 18 Pro and what it means for devs

Today Apple held its “Surprise and Shine” event at the Steve Jobs Theater in Apple Park. It was John Ternus’s first keynote as CEO —he took over on September 1— and it didn’t arrive empty. This post recaps what was announced and lands on what it means for those of us building iOS apps, especially around the new foldable form factor.

What was announced

Three new iPhones. The iPhone 18 Pro, the iPhone 18 Pro Max, and the iPhone Duo, Apple’s first foldable. All three run the A20 Pro chip on a 2 nm process (MacRumors event preview). Surprise: no base iPhone 18 this year — Apple moved it to spring 2027 along with the iPhone 18e and second-gen iPhone Air (TechRadar).

The iPhone Duo, in numbers:

Outer display: 5.4 inches (~90% of the iPhone 18 Pro area).
Inner display: 7.6 inches (50% larger than the 18 Pro Max, 80% larger than the 18 Pro).
Continuous aspect ratio between both displays, per Apple.
12 GB of RAM, base storage 256 GB.
First iPhone with Apple’s own C2 modem, reducing Qualcomm dependency.
Starting price: $1,999 USD. Preorders October 16, shipping October 23 (Variety, Macworld).

Beyond the iPhone: Apple Watch Series 12, fourth-generation Apple Watch Ultra, and AirPods 5 (TidBITS, 9to5Mac).

The OS 27 package — everything on September 14

Apple confirmed that iOS 27, iPadOS 27, macOS 27 Golden Gate, watchOS 27, tvOS 27, and visionOS 27 all ship on Monday, September 14, 2026 (9to5Mac, Neowin). One date for the whole stack — five days after the event.

macOS 27 is named “Golden Gate”, continuing the line of California-inspired names. The most visible changes (Macworld, 9to5Mac release notes):

New Siri with Apple Intelligence integrated at the app level.
Shortcuts with AI — shortcuts generated from natural-language prompts.
Safari improvements, new Golden Gate wallpapers and screensavers.
Drops Intel Mac support — Apple silicon only. Advanced Siri AI features require M3 or newer and 12 GB of unified memory.

For us iOS devs, the September 14 date matters for a concrete reason: it’s the day real users start updating, and also the day the foldable APIs discussed below stop being beta and land in production.

The elephant in the room: two screens on an iPhone

The iPhone Duo isn’t just a bigger display. It’s a device with two physical states —closed and open— and a range of angles in between. Apple showed several system-level adaptations built around that fact (MacRumors: Apple Announces Foldable iPhone Duo):

System controls placed at the edges for thumb reach.
Home Screen dock oriented vertically when the device is open.
Content that scales automatically during the transition between displays.
Apps that can run in dual mode (two apps side by side) or mirror across both screens.
Audio tuning that adjusts the mix based on speaker distance as the angle changes.

Third parties that arrived at launch with real support: Netflix, Zoom, and Slack (Digital Trends).

Developer angle: what iOS 27 and Xcode 26 bring

None of this came out of nowhere. At the WWDC 2026 Platforms State of the Union Apple had already presented the resizable app framework, a push for apps to stop assuming fixed device dimensions and adopt dynamic adaptation (MacRumors: iOS 27 Hints at Foldable iPhone). The iPhone Duo is the concrete reason that framework existed.

Parallel View — the system does part of the work

Apple ships a system-level reflow mechanism called Parallel View that automatically adapts existing apps to the Duo’s wide display. If you build against the latest SDK, your app is opted in by default to resizability (byteiota: iPhone Fold APIs).

The important distinction: automatic adaptation isn’t the same as intentional design. Parallel View keeps your app from looking broken, but it doesn’t make it look good on the larger screen.

NavigationSplitView — the real shortcut (and it isn’t new)

Since iOS 16, NavigationSplitView collapses to a stack on compact screens and expands to sidebar-detail when there’s room, with no conditional code:

NavigationSplitView(columnVisibility: $columnVisibility) {
    ArticleListView()
        .navigationTitle("Headlines")
} detail: {
    if let article = selectedArticle {
        ArticleDetailView(article: article)
    }
}

This component was designed for iPad and now behaves as the default pattern on the Duo.

Foldable-specific APIs

Analysts found several new APIs in the iOS 27 code for reacting to the device’s physical state:

foldState — the fold state (closed, open, folded to a specific angle).
angleDegrees — current angle between the two halves.
mechanicalAngleDegrees — raw mechanical angle from the sensor.

On top of that, iOS 27 introduces the .adaptiveSidebar() modifier and Liquid Glass design tokens for sidebar backgrounds when the layout expands.

Xcode 26 — testing without hardware

Xcode 26 already ships with:

An iPhone Fold simulator with state toggles (open / closed / intermediate angles).
A Fold State overlay in the View Debugger to inspect how your layout reacts.
Resizable Previews for testing size and aspect-ratio ranges without swapping simulators.

The conscious opt-out

Not every app should adapt. If your app is a camera or AR app that only makes sense on the outer display with the device closed, you can declare it in Info.plist:

<key>UIRequiresFullScreen</key>
<true/>

That runs it only on the 5.4” cover display. It’s a conscious opt-out, not neglect.

Conclusion — concrete challenges for making apps compatible

Here’s where you have to sit down and think. The iPhone Duo brings up-to-date something iPad had already been signaling: the era of fixed per-device layout is over. These are the challenges I see:

1. Audit what your app assumes. Any frame(width: 375), any calculation based on UIScreen.main.bounds, any layout that assumes “single portrait” is immediate debt. The same app is going to run on a 5.4” cover, a 7.6” inner, an iPhone 18 Pro Max, and —if you share code— an iPad.

2. Design for intermediate states, not binary ones. The foldable isn’t just “open” or “closed”. There are angles, there’s posture (the device propped at 90° used as a tripod or a mini-laptop), there are transitions in the middle of an interaction. Each one is a product opportunity — a camera app can use the semi-folded device as a virtual tripod, a video-call app can reorganize controls to the lower half when the upper half shows the other person.

3. Preserve state across transitions. When the user opens the device mid-task, does scroll stay put? Does keyboard focus move? Does video keep playing? SwiftUI with scene lifecycle handled well helps, but every app has its details.

4. Rethink aspect ratio, not just size. Both Duo displays share aspect ratio, but one is nearly double the other in area. Images, videos, grids and components that assume a single aspect ratio need review —not to become elastic blindly, but to choose what takes advantage of the extra space.

5. Testing with and without hardware. The Xcode 26 iPhone Fold simulator covers the basics, but validating real touches, physical transitions, and the ergonomics of the intermediate angle needs the device. With a $1,999 USD starting price, not every team member will have one on day 1 — you have to stretch the simulator and prioritize which validations actually require the metal.

6. One codebase. The goal of NavigationSplitView and the resizable framework is that you don’t duplicate code for traditional iPhone, Duo, and iPad. If you find yourself writing if isFoldable {…}, you’re probably fighting the platform’s design. The legitimate exception is when you reach for specific APIs like foldState or angleDegrees for features that only make sense on the new hardware.

The message repeated across the event and the docs that followed is the same: adaptive layout by default. Not because the foldable is going to be the majority of installed base tomorrow —it won’t, at that price— but because the platform’s direction committed to it. This is the reasonable moment to audit existing apps against Parallel View, adopt NavigationSplitView where it makes sense, and decide which Duo features justify touching foldState by hand.