Get your in-app messages ready for iPhone Duo: a foldable iPhone compatibility checklist

Apple announced iPhone Duo, its first foldable iPhone, on September 9, 2026. Pre-orders open October 16 and it goes on sale October 23, running iOS 27.1. What’s strange is the sequencing: Apple published the rules the same day, but the SDK with a Duo simulator only arrives “later in September.” The documentation exists and the hardware mostly doesn’t, which is exactly the window to go find the layout assumptions in your app that quietly stopped being true.

This guide skips the device review, there will be a hundred of those. The push notification itself is drawn by the system, so there’s nothing to change there. Everything your app draws inside itself is the part that now has to survive a screen that changes shape and aspect ratio while a session is already running: in-app messages, rich media, the push primer, loaders. That’s the surface Apple wrote new rules for, and it’s the one most teams are about to walk straight past.

What actually changed with iOS 27 on a foldable iPhone

iPhone Duo has 2 displays with near-identical aspect ratios. The inner one is 7.6 inches, roughly 50% more screen area than an iPhone 18 Pro Max; the outer one is 5.4 inches, about 90% of the screen area of an iPhone 18 Pro. The proportions are close but not identical, which is one more reason to drive layout from size classes rather than from a ratio you assume holds on both.

Every app takes part in Split View. Duo is the first iPhone to run multiple instances of your app’s UI, which means your in-app messaging can end up in half the screen next to somebody else’s app.

And the shape changes mid-session. The user unfolds the device, or half-folds it, while your modal is up. Layout stops being a thing you decide once at launch.

3 levels of compatibility, and where most apps land

Apple’s rule is blunt: your app runs on Duo without recompiling. How much of the screen it gets is the catch, and that depends on which SDK you built against.

• Older SDK: it runs, but your content stays boxed into the phone-shaped region.
• iOS 27 SDK: your UI extends left of the status-bar area on the inner display.
• iOS 27.1 SDK: your UI reaches the screen edge, and standard navigation and toolbar buttons lay out vertically.

Which means a team that does nothing ships its in-app messages in a phone-sized box on a 7.6-inch display. Not broken. Just visibly untouched, sitting next to competitors who bothered.

Why your in-app messaging layout stops working

3 reasons, and they stack.

Aspect ratio. Most in-app and rich-media templates were laid out to the proportions of a normal iPhone. The inner display’s proportions are different, and templates built for the old ones won’t land where you drew them.

Orientation is the wrong signal. The inner display is regular in both size classes and doesn’t honor supported interface orientations. Any layout branch keyed on orientation is reading a signal the inner display ignores. Apple’s instruction is direct: decide layout from size classes, not orientation.

Safe area is asymmetric. Insets and layout margins on Duo are often different on each side, so you handle every edge on its own instead of assuming a symmetric frame. Then test it in Split View, where the frame gets narrow again.

The in-app message that’s up when the phone opens

This is the case worth thinking through, because no simulator has let anyone watch it yet: a modal in-app message is on screen and the user unfolds the phone. The frame changes underneath a view that’s already presented.

Apple hands you 2 tools here, and mixing them up is the easy mistake.

The hinge APIs, onHingeChange in SwiftUI and UIHingeInteraction in UIKit, report a discrete state (closed, partially open, fully open) and a continuous angle. They’re meant to be watched live and to drive interactions and effects. Apple’s own demo uses the fold angle to bend the pitch of a virtual instrument. That’s the register they’re for, not moving your buttons around.

Layout goes through a different door. Apple points you at the arrangement and region APIs from the “Strike a pose with adaptive layouts on iPhone Duo” talk, which introduces reserved regions, arrangement views with split and overlay layouts, and displacement: reframing existing elements into the space that’s actually available, so content stays visible and reachable as the device closes. iOS 27.1 adds ReservedRegion in SwiftUI and UIViewReservedRegion in UIKit, so your custom UI can claim the space it needs without colliding with system UI. You query them with reservedRegions(kind:), where .division is the fold itself and .occlusion is the camera.

For a modal, that resolves to one rule: don’t reach for the hinge angle to reposition it. Let it answer to the arrangement and the reserved region, so when the screen opens your content lands where it belongs instead of clinging to a frame that’s gone.

In-app notifications in Split View

Since every app is in the multitasking pool now, your in-app notifications can wind up in half the screen next to a stranger’s app. That’s a much narrower frame than the full inner display, which is the whole reason to test at half width. A modal that reads fine full-screen will clip or crowd when it loses half its room.

There’s also a hard wall to know about: you can’t open new windows on the outer display, it’s reserved for the inner experience. Any presentation logic that spawns windows has to account for that.

The outer display: your compact layout, plus widgets and Live Activities

The outer display behaves like any other iPhone screen. Your app runs there, and so does everything it draws, in-app messages included. Apple’s framing is that the outer display is a compact-width layout, the same as a regular iPhone, while the inner display is regular in both dimensions. At 5.4 inches it’s the narrowest full-screen frame your in-app messaging gets on this device, so it belongs in the test matrix rather than in the “doesn’t apply” pile.

There’s a second surface stacked on top of that one. On Duo, StandBy runs on either display even when the device isn’t charging: set the phone down and the outer screen stays lit and pointed at the room. An app with no widget and no Live Activity is simply absent from that moment. Presence there comes through a widget or a Live Activity, which is the same work you’d already do for lock-screen and Dynamic Island. If you’ve built Live Activities, this is the second place that investment earns out. If you haven’t, here’s another reason.

A foldable iPhone compatibility checklist for before October 23

You can’t touch the hardware yet, but everything short of that is on the table:

• Inventory your in-app and rich-media templates. Find every one that hard-codes a frame, an aspect ratio, or a phone-sized box.
• Audit your 16:9 creatives. Anything built to a fixed aspect ratio needs a plan for the inner display.
• Find your orientation branches. Layout keyed on interface orientation is reading a signal the inner display ignores, so move it to size classes.
• Check each safe-area edge on its own. Assume asymmetry; don’t assume a symmetric inset.
• Grep for UIScreen.main. On a 2-display device it’s ambiguous, and Apple says it will be deprecated. Read the screen from window?.windowScene?.screen and the scale from traitCollection.displayScale.
• Test at compact width, not just unfolded. The outer display is where your in-app messages get the least room, and it’s a real surface for them.
• Line up your Device Hub test. When the Xcode 27.1 beta ships, the Duo simulator lives in Device Hub: open it, close it, rotate it, half-fold it with a message on screen.
• Segment by device model. Give yourself a way to target Duo users for separate testing once they’re in the wild.
• Revisit your push notification and onboarding primer copy. The permission prompt users see during onboarding is still system-drawn, but any custom pre-permission screen leading up to it inherits the same layout rules as your in-app messaging.

None of it needs the device. All of it needs doing before the device is in your users’ hands, not after.

Ship your in-app messaging ready for Duo

Fixing this across in-app messages, rich media, and push primers by hand, on every screen your users carry, is the kind of thing that’s easier on one integration than six. That’s the case for handling in-app messaging and push notifications through a single mobile engagement platform like Pushwoosh: start free or talk to our team about getting your messaging Duo-ready before October 23.