Written by:
Last Published:
27 October 2026
•
.webp)
Your app runs on iPhone Duo, Apple's new foldable iPhone. Fine. Is it designed for it? That is a different question, and Apple is about to make the gap visible.
Apple is already accepting apps optimised for the device, and submitting iPhone Duo screenshots adds an optimisation badge to your product page. From April 2027, every app or game submitted will need those screenshots. So the real question is not whether to look at iPhone Duo. It is whether you look now, on your own timetable, or later, on Apple's.
This article is for product owners and designers who need to scope iPhone Duo app design work. We keep the examples general, because the questions are the same for any iOS app. The apps hit hardest are the ones with long sessions, media and live state, such as a video player, a delivery tracker or a recipe app, which is exactly where a form factor change hurts. One caveat before we start: this is an analysis of Apple's published guidance and our own design reasoning.
iPhone Duo is Apple's foldable iPhone, on sale since 23 October 2026. It has an outer and an inner display joined by a hinge. The outer display uses a compact width layout, the inner a regular width layout, toolbars and tab bars move to the side, and the fold becomes a region your content must respect.
Apple's Human Interface Guidelines for iPhone Duo describe how people hold and position the device: partly folded like a book, set down on a surface or standing on its edges, as well as open or closed. Supporting all of that does not mean designing a layout for each pose. It means building one layout that resizes well.
Three terms do most of the work here:
Avoid fixed widths and anything tied to one specific screen, and the layout will adapt with little extra work.
What happens to an app you leave untouched depends on the SDK it was built with, according to Apple's three steps to make your app shine on iPhone Duo:
Short version: doing nothing is a choice, and its outcome changes with every SDK you adopt.
Apple's notice sets one hard requirement. From April 2027, all apps and games submitted to the App Store must include iPhone Duo screenshots. Everything else, including the badge and a featuring nomination, is optional for now. The notice does not give an exact day or separate new apps from updates.
Here is the timeline as Apple published it:
Two optional extras are worth knowing about. Submitting iPhone Duo screenshots shows an optimisation badge on your product page, so people can see which apps are ready before they download. And, as Apple's three steps page explains, in App Store Connect you can nominate your app for featuring and note that it supports every pose of the device.
Plan the App Store screenshots early. Apple publishes screenshot specifications, asset best practices and a preview tool in App Store Connect that shows how screenshots and metadata appear on the device. Screenshots of an app you have not adapted are a poor advert, so the deadline quietly doubles as a design deadline.
Every iOS app has work to do, but some are more exposed than others. Four traits make a foldable punishing: media-first screens, long sessions, live state such as timers, playback position or a basket, and flows that involve money. A video player, a navigation app, a food-delivery app, a banking app and a recipe app each have at least two of them.
Picture someone following a recipe: a video playing, a countdown running, flour on their hands. Now fold the phone mid-step. In a news app, a layout glitch is an irritation. Here, it breaks the task the person came to do, and that is what they trust the app for.
The commercial context points the same way. Sensor Tower reports that consumers spent $167 billion on in-app purchases in 2025, up 10%, and that spending on non-game apps overtook games for the first time. RevenueCat's State of Subscription Apps 2025, drawn from about 75,000 subscription apps, shows that the App Store earns a median of $0.38 per install after 60 days, against $0.14 on Google Play. None of this is specific to iPhone Duo, and we have no figures yet on who is buying the device, so check your own analytics for the share of your users on the newest iPhones and the flows they spend longest in.
The case rests on three things: access, visibility and revenue protection. After April 2027, an app without iPhone Duo screenshots does not meet Apple's submission requirements. The badge makes ready apps visible before download. And in any app with subscriptions or a checkout, a broken session puts revenue at risk.
Access. Read plainly, Apple's notice says every app or game submitted needs iPhone Duo screenshots. A team that has not prepared turns a design task into a release blocker, usually at the least convenient moment, when a bug fix needs to ship.
Visibility. Apple shows the optimisation badge on the product page, before anyone downloads. If a competitor's app carries it and yours does not, that difference is visible in the store. The featuring nomination is a second, optional lever.
Revenue. Paywall, checkout and onboarding flows are where a layout reset costs money directly. Set a baseline now for paywall conversion, task completion and store conversion, so you can compare iPhone Duo with other iPhones after launch. Apple has not published benchmarks, so your own numbers are the evidence.
We cannot give a single figure, because cost follows your codebase and your product. Five variables drive most of it:
The quickest way to turn those into an estimate is an iPhone Duo app audit: a structured review of your app against Apple's guidance, before any build work starts. Our Technical and UX audit is a natural starting point for it.
Start with the flows where a reset costs most. As a rule of thumb, we propose the Reset Test: for each flow, ask what a person loses if the device opens, closes or resizes halfway through. The loss is money, momentum or trust. The answer sets the order of work.
| Tier | What a reset costs | Example flows in a typical app |
|---|---|---|
| 1 | Money or progress | Paywall and checkout, an active session such as playback, navigation or a call, forms with typed data |
| 2 | Momentum | Catalogue or library, overview and dashboard, history and stats |
| 3 | Little | Settings, help, account details |
Ship Tier 1 first, then Tier 2, and treat Tier 3 as clean-up. It is a rule of thumb, not a standard, so adjust the tiers to your own product. It keeps the work small enough to fit a roadmap and gives leadership a clear answer to "what do we do first, and why?".
An app on iPhone Duo needs five design decisions: keep the session alive when the device opens, use the table pose for follow-along content, check how media crops, use the inner display for a second level of hierarchy, and respect the vertical bar on the outer display. Each one maps to a specific rule in Apple's guidance.
Think of one shop floor, laid out for a morning sale and rearranged for an evening event. The stock is the same. The floor plan changes. Nobody should have to hunt for the till.
Apple's guidance asks for that: keep the same controls, the same state and the same hierarchy as the layout changes. What follows are scenarios, not case studies. They show how Apple's rules play out in an app with media, timers and transactions.
People open and close iPhone Duo often, so Apple asks for behaviour that is predictable and consistent on both displays. In an app with a running task, a person who unfolds the phone mid-task should find the timer, their progress and the video position exactly where they left them. Think of a recipe step, a delivery tracker or a lesson.
Write it as an acceptance criterion: unfold during an active task and nothing resets. Then check the code. An app can be resized mid-session, so reading the screen size once at launch is not enough. Size has to be recalculated whenever the layout changes.
Apple describes an optional layout for the pose where the device is set on a surface: media at the top, tappable controls on a stable base below. For follow-along content such as a cooking video, a language lesson or a video call, that is a natural fit. The video sits where you can see it from a distance, and the controls sit where your hand can reach them.
The rule that matters most is to keep the same controls and the same hierarchy as in the other poses. Apple's Tech Talk also advises against tying features to a specific pose. A table layout is a rearrangement, not a different app.
Video and images set to fill the screen can lose important content on wider displays. Apple points to this directly: media using aspect-fill modes may crop out the part that matters.
In your app, the part that matters might be a face, a product or a map pin. Decide per asset whether to fit or fill, choose by size class or aspect ratio, or set a focal point. Ask your designer to review the hero video or image on every display, not only the one you tested first.
Apple's advice for the inner display is not to stretch the iPhone layout, but to show one more level of your hierarchy where it helps. Its example is Mail, which shows a list or a message when closed, and both side by side when open.
In a typical app, that could be a list on one side and the selected item or active task on the other, using a split view. If your app is information-dense and has a tab bar, Apple's Tech Talk also mentions presenting it as a sidebar on the inner display, and notes this does not suit every app. A few practical points from the guidelines:
ReservedRegion API, which moves content away from reserved areas such as the cameras and the fold.On the outer display, toolbars, tab bars and navigation controls sit along the side to save vertical space. They share that edge with the status bar and the Dynamic Island. A timer or delivery tracker running as a Live Activity (a live-updating status that Apple shows in the Dynamic Island) expands in that same space, so your controls and the system's need to coexist.
Apple's advice is blunt: in general, do not override the default bar placement. Give every toolbar item a title as well as a symbol, keep text-only buttons to a minimum, and set a visibility priority so that "Checkout" is the last action to disappear into the overflow menu, not the first.
Treat iPhone Duo as a scoped piece of work with an owner, a test plan and a date. In practice that means six steps: rebuild, audit, write acceptance criteria, test on several setups, plan store assets, and start with the Tier 1 flows from the Reset Test.
Test for continuity first, then for layout. Apple lists three ways to test: the resizable iOS simulator in Device Hub, iPhone Mirroring on macOS 27 with the window dragged to extreme sizes, and the iPhone Duo simulator in Xcode 27.1, which Apple calls the best way to test the full native experience.
Across those setups, check the following:
Most problems come from code that assumes a phone is always the same size. Apple flags a set of patterns to remove, which we group into six, from sizing off the main screen to hard-coded screen sizes. Each one has a direct replacement. Most are fixes to how layout is calculated, not redesigns.
| Pattern to remove | Do this instead |
|---|---|
Sizing from the main screen (UIScreen.main.bounds) | Use the view or window bounds, or GeometryReader (the SwiftUI view that reads the size of its container) |
| Reading the size once at launch | Recalculate whenever the layout changes, because a fold can resize the app mid-session |
| Choosing layouts by device orientation | Compare the width and height of the space actually available |
| Treating idiom or size class as the device (for example, assuming regular width means iPad) | Decide by size classes or available space, since an iPhone can now have any combination |
| Hard-coded screen sizes (a fixed height, for instance) | Remove them and rely on safe areas and margins |
| Aspect-fill media that crops important content | Choose fit or fill by size class or aspect ratio, or set a focal point |
None of these is exotic. That is the good news. The less good news is that they tend to sit in the oldest parts of a codebase, which is exactly where nobody wants to look.
iPhone Duo is Apple's foldable iPhone. It has two displays, each with its own front-facing camera, and a hinge in the centre that supports several ways to hold and position it. It reached customers on 23 October 2026.
An app can appear at many sizes: the outer display, the inner display, partly folded, or sharing the screen with another app. Toolbars and tab bars sit along the side on the outer display, and the fold is a region content must avoid. Apple still asks you to follow its usual iOS design patterns.
Yes, in our view, and the sensible start is an audit rather than a rebuild. Apps that rely on video, timers, live state or checkout flows suffer most when a layout resets. Use the Reset Test to decide which flows come first.
No. Apple's route is to recompile with Xcode 27.1, fix the patterns above and test across poses. In our view, a rebuild is only on the table if your layout logic is tied so tightly to fixed screen sizes that fixing it amounts to rewriting it.
There is no honest single figure. Cost follows the number of flows, how layouts are built, the amount of media, custom components and test setups. An audit turns those variables into a scoped estimate.
From April 2027, for all apps and games submitted. Apple's notice gives the month, not the day, and does not distinguish new apps from updates. Plan as if every submission needs them.
Possibly as a starting point, but test it. Apple says the inner display should feel like a natural extension of an iPad layout, and also warns against choosing layouts by device idiom, since an iPhone can now present any combination of size classes. If your iPad layout is built on size classes, you have a head start. If it is chosen by checking for an iPad, it will not carry over automatically.
Recompile, audit, test and plan your screenshots. Keep state and controls consistent as the device opens, and use the extra width for a second level of hierarchy, not for stretched phone screens. Use the Reset Test to start with the flows where a reset costs most.
The deadline is April 2027, but the visible difference starts now, because Apple shows which apps are ready before anyone downloads them.
If you are scoping iPhone Duo work, or weighing up iOS app priorities for the next quarter, we are happy to talk it through. Our Digital Product Design team works with product owners and designers on exactly this kind of decision, and our engineering teams can add capacity when the build starts.
We have built iOS products before, such as Jinga Life, a family health records app. Bring us the awkward layout questions first.
Contact us to book a short call about your iPhone Duo plans, and we will help you work out where to start.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
.webp)
