iPhone Duo Is Here Oct 23: Is Your App Ready?

On October 5, Apple told developers that iPhone Duo reaches customers on October 23, and that you can submit iPhone Duo-optimized apps in App Store Connect right now. It is Apple's first foldable. If you have an iOS app in production, some of your users will open it on this device within weeks, and some of them will be the early adopters who write reviews.

The timeline matters more than the hardware. Apple has put a hard date on the App Store side too: starting in April 2027, every submitted app and game needs screenshots for iPhone Duo. That is an update-cycle deadline, not a launch-week one, but it means you cannot ignore the device and ship business as usual.

So what should you actually do? Most of the advice online is either panic or a shrug. Our view sits in the middle. A typical consumer or B2B app will run on the new device without breaking, because Apple has spent years pushing developers toward adaptive layouts on iPad and in Split View. But "runs" is a low bar. The first people to hold the device will judge your app on whether it looks deliberate on a bigger inner screen, and a stretched phone layout looks lazy.

This guide is the checklist we would hand a founder who asked us on a call what to do before the 23rd. It covers the facts Apple has published, the tests worth running, the three kinds of app that need real work, and what to leave alone. If you want the design theory behind foldable layouts, read our earlier piece on building for foldable devices. This one is about the next three weeks.

Start with what is confirmed, because a lot of secondary coverage is guesswork presented as fact.

• Availability: October 23, 2026.
• Tooling: Xcode 27.1 adds development support. Device Hub, the testing tool in Xcode, shows your app across every pose and orientation of the device.
• Submissions: optimized apps can go into App Store Connect now.
• Screenshots: updated specs exist for iPhone Duo, and App Store Connect has a preview tool that shows how your screenshots and metadata will look on it. From April 2027, screenshots for the device are required.
• Design kits: Apple published Figma and Sketch kits on September 18.

Reports put the outer display at 5.4 inches and the inner display at 7.6 inches. Those numbers come up in coverage of Apple's materials, and they are good enough to plan around. What Apple has not published, as far as we can tell, is a clean list of point dimensions. Some developers have pulled numbers out of the simulator profile. We would not hard-code anything based on those. Read the sizes out of Xcode on your own machine and design to size classes, not to a device number.

That last point is the whole discipline. If your code has a hard-coded check for one specific screen width anywhere, you have a problem that predates this device. If it reacts to the space it is given, you probably have a smaller problem than you fear.

One more caution. Early coverage disagrees on exactly how the simulator shows up in different Xcode installs. Check that you are on Xcode 27.1 and look for the device in Device Hub before you assume anything works or fails.

Before you hire anyone or open a ticket, spend ten minutes finding out where you stand. You need a Mac with Xcode 27.1, your project, and a build.

1. Recompile with Xcode 27.1 and run the app on the iPhone Duo device in Device Hub.
2. Walk the onboarding, the main tab or home screen, one detail screen, the paywall if you have one, and settings.
3. Fold, unfold and rotate the device while you are on each screen. Watch what happens to scroll position, text entry and any video or camera view.
4. Switch to dark mode and the largest accessibility text size and repeat on the inner display.
5. Open a deep link or a push notification while the device is in the closed pose, then unfold it.

Take screenshots of everything that looks wrong. You are not fixing yet. You are sorting the problems into three buckets: broken (crashes, clipped buttons, unreachable controls), ugly (a phone layout stretched into a large space with dead margins) and fine.

In our experience, apps built with current SwiftUI and sensible constraints land mostly in "fine" and "ugly." Apps with hand-calculated frames, fixed-width modals or custom navigation containers land in "broken." A cross-platform app written in React Native or Flutter usually behaves like its iPad build, so if you never tested the iPad version, you have a preview of what you will find. Our comparison of React Native, Swift and Kotlin covers why that framework choice affects how much layout work you inherit.

The smoke test also tells you something about your team. If a developer can fix everything in the broken bucket in an afternoon, you are in good shape. If the answer is "we would need to rework navigation," that is a project, and it needs a budget line.

Not every app needs the same attention. Three types need more than a screenshot refresh.

Apps built around a single column

Feeds, chat apps, to-do lists and most consumer social products are a single scrolling column. On a 7.6-inch inner display, that column either floats in the middle with wide empty margins or stretches until the line length is unreadable. The fix is a two-pane layout: list on one side, detail on the other. The native navigation components already support it. If you built your own container, you will be rebuilding it.

Apps with media, camera or maps as the main surface

Video players, camera tools, mapping and AR apps get the most out of a bigger screen and also break in the most interesting ways when the device changes pose mid-session. A camera preview that was sized for one aspect ratio will letterbox or crop wrongly when the user unfolds. Test fold transitions with the camera running and with a video playing, because that is where state gets lost.

Productivity and B2B tools with dense data

Dashboards, CRMs, field-service apps and anything with tables benefit the most. Your users already wish the phone version showed more columns. A larger inner display gives you a real reason to add a side panel, an inspector or a split inbox. This is the case where optimizing is a feature and not only maintenance, and where a launch-week update can earn a mention in the App Store.

If your app is mostly a thin wrapper around a web view, you have a different problem, and the web content needs responsive breakpoints. Your web team handles that, not your iOS team.

For a sense of how much of this is real engineering versus polish, our adaptive UI cost breakdown has the market ranges. The short version for planning: a clean SwiftUI app with 20 to 40 screens usually needs one to two weeks of engineering for a proper adaptive pass, and a custom-navigation app can run several times that.

Here are rough market numbers, in our own estimate and not a quote. They assume a US or Western Europe agency rate and a single iOS codebase.

• Smoke test and triage report: half a day to two days of senior developer time. Roughly $500 to $2,500 depending on who does it.
• Fixing "broken" issues only: two to five days for most apps. $2,000 to $8,000.
• Adding a proper two-pane layout to the main flows: one to three weeks. $6,000 to $25,000 for an app with a standard navigation stack, more if navigation is custom.
• New screenshots and app preview video for the new device: a day or two of design time, a few hundred to a couple of thousand dollars.

The range is wide because the cost is almost entirely a function of how your navigation and layout code was written, not how many screens you have. A well-structured app is cheap. A tangled one is expensive, and this is one more place where code quality turns into a real invoice. If you inherited a vibe-coded app, expect the upper end. Our guide on when to rebuild a vibe-coded app explains how to tell whether patching is still worth it.

On who should do the work: if your current team built the app and knows it, let them do the smoke test. They will find problems faster than a stranger. If nobody on your team has shipped an adaptive layout before, bring in someone who has for the design of the two-pane structure and let your team handle the rest. Getting the structure wrong on day one is the expensive mistake.

The App Store requirement is easy to underestimate. From April 2027, a submission without iPhone Duo screenshots gets stopped. Nothing forces you to produce them before then, but there is a reason to start now: the screenshots are your storefront on a device whose buyers are, by definition, enthusiasts who browse the App Store the first week.

Apple has given you three tools. The updated screenshot and app preview specs describe sizes. The new preview tool in App Store Connect shows how your screenshots and metadata will appear on the device. And Apple added new product page headers and search result assets, with an asset library in App Store Connect to manage them.

Our recommendation is plain. Do not wait for April. Produce one set of inner-display screenshots that show your best two-pane screen, plus one closed-pose set that shows the outer display. If your app did not change at all, say so honestly in your metadata and keep your existing screenshots until the requirement bites. But if you did the layout work, show it. That is the cheapest marketing you will do this quarter.

If screenshots are a weak spot for your team, our App Store screenshots and metadata guide covers what converts and what does not. Keep the same rule from that article: the first two screenshots carry most of the weight.

One practical detail. Plan for screenshot generation to be repeatable. If you capture them by hand, you will redo the work every release. Automating capture with UI tests takes a day to set up and saves you from the April scramble.

A lot of the noise around a new device is about things that do not matter yet. Skip these.

• Fold-specific features for their own sake. You do not need a "tent mode" feature or a gesture that only works on the new hardware. If a feature does not help your user finish a task, it is a demo.
• Dropping support for older iPhones. The new device does not change your minimum OS decision. That is a separate conversation driven by your analytics and the April SDK deadline.
• A native rewrite. Nothing about this launch justifies rewriting a working app. If your app runs and looks acceptable, polish it.
• Chasing exact pixel dimensions from forum posts. Use size classes and read live values from the system.

The honest version is that the device will not be a large share of your users for a while. A new foldable from any maker starts as a small slice of installs. The reason to act now is the combination of cheap fixes, a visible App Store opportunity and a firm deadline for screenshots, not a flood of new traffic.

Check your analytics in the first two weeks after launch. Segment by device model. If the new device is under one percent of sessions, keep your changes small. If it is five percent of your paying users, which can happen in premium-leaning products, move the two-pane work up your list.

If you want a schedule, here is one that fits between now and October 23.

1. This week: install Xcode 27.1, run the smoke test, and write down what is broken, ugly and fine. Decide whether the broken list is an afternoon or a project.
2. Next week: fix everything in the broken bucket. Do not start new layouts yet. Ship a build to TestFlight and have two or three people try it on the simulator, or on real hardware if anyone on your team preorders.
3. The week of the 20th: submit the update. Apple's review times vary, and you want the build live when the first reviews land. Prepare the new screenshots in parallel, using the App Store Connect preview tool to check them.
4. After launch: watch crash reports and session data by device. Plan the two-pane work as a normal roadmap item for the next release, not a fire drill.

For the release mechanics themselves, our mobile app launch checklist is still the right reference, and the rejection patterns in our App Store rejection guide apply to this update like any other.

If you are not sure whether your app lands in the afternoon bucket or the project bucket, that is a fair thing to find out before you commit budget. We run this kind of triage for founders regularly, and it usually takes a short call and a look at the build. Book a free strategy call and we will tell you which bucket you are in.