A foldable iPhone is no longer a rumor you can safely ignore. Bloomberg's Mark Gurman has reported it multiple times, WWDC26 marketing materials have hints embedded in the logo, and iOS 27 — due to be announced on June 8, 2026 — is being built with specific foldable optimizations the reporting community has now pieced together in reasonable detail. A September 2026 launch is the most frequently cited window.
If you ship an iOS app, you have 47 days until WWDC and roughly 140 days until foldable devices are in users' pockets. That is not a "someday" problem. It is a "get ahead of this now" problem, because the developers who ship foldable-ready updates in the launch window will own the "best apps for foldable iPhone" search term on the App Store for a year.
This guide walks through what actually changes when the foldable ships, how to audit your app for readiness, what to do in SwiftUI and UIKit, how to rethink your App Store listing, and what Android's foldable generation has to teach iOS developers who have never shipped for this form factor.
what a foldable iphone actually changes#
The short version: you get a third screen-size class on iOS. Today, you design for compact (iPhone) and regular (iPad). A foldable introduces a folded state that feels like a compact phone, an unfolded state that sits between a phone and an iPad mini, and — critically — a transition between the two while the app is running.
The continuity problem is the one that trips up Android apps every cycle. Your app is running on a 6.7" portrait screen, the user unfolds the device, and now your layout is running on an 8" nearly-square canvas. If you hard-coded widths, pinned elements with fixed frames, or forgot to handle orientation changes, the user sees a broken app. If you handled it, the user sees a more capable version of the same app, with more content on screen and a new reason to keep using it.
The hinge is the other consideration. Foldables have a display seam down the middle. You want to avoid placing tap targets, key text, or image focal points directly on that line. This is less of a problem on modern foldables than first-generation ones, but it is still a real consideration in your layout math.
the readiness audit — what to actually check#
Run your app on the largest iPad simulator you have today. Not because iPads are foldables, but because iPad Multitasking is the closest approximation of the unfolded state that exists in public simulators right now. Pay attention to:
- Fixed-width components that stretch awkwardly or truncate.
- Navigation hierarchies that assume a single-column layout.
- Sheets and modals that look comically oversized.
- Text that stays pinned to one side of the screen when there's twice the room.
- Images and hero assets that blur when scaled up.
Every one of those is a foldable readiness bug that you can fix today without waiting for iOS 27 beta 1.
swiftui: the work is mostly already done for you#
If your app is SwiftUI-first, the news is good. The framework was designed with multi-size-class responsiveness baked in, and most of the work you'd do for foldable readiness is the same work you'd do for good iPad support.
The patterns to lean on:
NavigationSplitViewinstead of a single-columnNavigationStackfor anything with a list-detail relationship. Split views collapse cleanly on compact and expand on regular automatically. A foldable unfold will behave like a size-class transition, and split views handle that transition for free.GeometryReaderfor anything that needs to reflow based on available width. Use it sparingly — it's easy to abuse — but for adaptive hero sections it's the right tool.- Container queries (
containerRelativeFrame) instead of.frame(width:). This is the single highest-leverage change most SwiftUI apps can make. A relative frame that says "60% of whatever container I'm in" works on every size; a fixed 240 points does not. - Scene-aware state. If your app stores UI state (selected tab, detail selection) make sure it survives a scene size change. Users unfolding mid-session and losing their place is the fastest way to lose a review.
Run a quick grep of your codebase for hard-coded widths, .frame(width:, and magic numbers in padding. Those are your regression risks.
uikit: the lift is larger but manageable#
UIKit apps have more work to do because the framework still reflects a world where a compact phone and a regular iPad were the only two classes that mattered.
Focus your effort on three things. First, audit every UIViewController subclass for size-class awareness. traitCollectionDidChange is the hook that fires when the size class shifts, and it will fire when a foldable unfolds. If your controller assumes the size class it had at viewDidLoad is still the size class it has now, you have a bug. Second, shift layout logic into Auto Layout constraints with multipliers instead of hard-coded constants. A constraint that says "this view is 40% of its superview's width" handles the transition; a 240-point constant does not. Third, use UISplitViewController for list-detail patterns. It has had proper collapse and expand behavior since iOS 14, and Apple has been steadily improving its handling of mid-session size changes.
rethinking your app store listing#
Here is the part most teams miss. When the foldable ships, Apple will almost certainly add a new screenshot slot to App Store Connect for the foldable display size. Apps that populate that slot on day one will look native on the device. Apps that don't will show default scaled screenshots, which will look worse than their iPhone equivalents.
That is a real conversion hit for nothing more than a production issue. The fix is boring: regenerate your full screenshot set at the new size on day one. If you're doing this by hand across 14 locales and four device sizes, that's a week of work. If you're automating it, it's a single pipeline run.
Your listing copy also has room to flex. "Optimized for the iPhone Fold" in your description, if true, is the kind of freshness signal the ranking algorithm rewards in the 30 days after a new device ships.
what android's foldable experience teaches us#
Android has been shipping foldable devices since 2019. Seven years of lessons apply directly here, because the hardware problem is the same. A few of the big ones:
The apps that did well on foldables were not the apps that redesigned themselves. They were the apps that already had responsive layouts and simply filled the extra space gracefully. Users do not want a different experience on the unfolded screen; they want more of the same experience.
The apps that failed were the ones that treated the unfolded state as a tablet mode and tried to introduce new UI patterns when the device opened. That is confusing. Unfold should feel like the app is breathing more, not morphing.
And the apps that won the media cycle were the ones that shipped a dedicated update in the first week of device availability, called out foldable support explicitly in their listing, and regenerated their screenshots. The launch-week developer playbook is well-trodden on Android. iOS is about to get its own version.
a practical week-by-week plan#
If you want a concrete sequence to work through between now and WWDC:
This week and next, run the iPad audit. Fix the obvious fixed-width and size-class bugs. Move your most egregious hard-coded frames to relative sizing. This is the work you should do regardless of whether the foldable ships on time.
In May, migrate to NavigationSplitView if you're SwiftUI, or UISplitViewController if you're UIKit. Test on the 13" iPad Pro and the 11" iPad. The goal is for your app to look intentional across four size classes today: compact iPhone, regular iPad portrait, regular iPad landscape, and iPad Slide Over.
The week of WWDC (June 8), install the iOS 27 beta and check your app against whatever new size class and foldable simulator Apple ships. Expect bugs. File radars early.
Through June and July, test against the developer beta regularly. Bugs you catch in beta 1 are much easier to file and get fixed than bugs you discover at launch.
In August, prep your launch-week submission. New screenshots at the foldable size, listing copy updated, release notes written, compliance checks run. The goal is to ship within 72 hours of the foldable launch.
In September, submit the day the device ships. Own the "optimized for foldable" moment.
where stora fits#
Stora was built for exactly this kind of multi-device, multi-SDK submission cycle. When the foldable simulator drops in Xcode 27, our screenshot generator will regenerate your full set across every device size — including the new one — in one run. The compliance engine catches layout and manifest issues before submission. The one-click publish flow pushes a clean build to both stores without you hand-managing metadata across locales.
The forcing function here is that launch windows are short. If you're spending three days regenerating screenshots, you've already lost the window. The tools exist to make this a non-issue.
the takeaway#
The foldable iPhone is a platform event. iOS 27 is the first OS built with it in mind. The developers who are ready in early September will own the launch-week conversation and the App Store rankings that come with it. The developers who are still auditing their Auto Layout constraints in late August will watch it happen from the sidelines.
Forty-seven days to WWDC. A hundred and forty days to a foldable in a user's hand. Start the audit now.