The foldable era: your app now has to survive nine screen shapes

For about a decade, one number described every phone on sale. Whatever you were building for, the screen was roughly twice as tall as it was wide — iPhone 18 Pro is 2.17, and almost everything else landed within a few percent of that. You could hard-code against it and get away with it, and most apps did.

That number is now one point in a range.

The assumption that just expired

Nine foldables are shipping as this is written. Their screens run from 1.04 — essentially square — to 2.37. That is not a shift in the average. It is the same average with the spread blown open, which is a different and much more annoying problem, because an average you can design for and a spread you cannot.

Then it gets worse: a single foldable occupies two points in that range, and moves between them while your app is running. Not on relaunch. Not on rotation, which you already handle. Mid-session, in response to a hinge.

So the honest framing of the foldable era is not “phones got bigger” and not “phones are landscape now”. It is this: the shape of the window your app draws into is no longer a property of the device, and it was never something you controlled in the first place. Both Apple and Google have now made that explicit in their platform rules, independently, in the same year. More on that below.

Nine devices, nine shapes

Ratios here are the long edge divided by the short edge, so a bigger number means a narrower screen. Every figure comes from the vendor’s own published specification.

Unfolded, on the inner display:

Closed, on the cover display:

One coincidence in there is worth pausing on. The Pixel 11 Pro Fold’s cover display is 2.17 — the iPhone 18 Pro’s ratio, to two decimal places. Google’s foldable, closed, is dimensionally an ordinary phone.

Android went square. Apple went tall.

Look at the top of that first table. Five of the nine inner panels sit between 1.04 and 1.12. Those are not tall screens and they are not wide screens. They are squares with a rounding error.

That has a consequence most teams have not internalised: on a 1.04 panel, portrait and landscape stop being meaningfully different states. There is no long axis to rotate. A layout that branches on orientation produces two near-identical geometries and two code paths to maintain, and a layout tuned for one of them is already tuned for the other whether you meant it or not.

Apple went the other way. The iPhone Duo’s inner display is 1.42 — the narrowest book-style foldable shipping. Only the Huawei Mate XT 2 is proportionally narrower, at 1.43, and that is a tri-fold that opens to 10.2 inches, which is a tablet wearing a phone’s clothes.

So the iPhone Duo’s unfolded screen is the closest thing in this table to a conventional tall layout, and that sounds like good news. It is, partly: if your app already has an iPad layout, the Duo’s inner display reports Regular width and that layout is usually close to right. We go into that in what to fix first, and the trap there is gating it on the device idiom, which still reports .phone.

The bad news is on the other side of the hinge.

The cover screen is where Apple diverges

Seven of the nine cover displays are between 2.14 and 2.37. Those are normal phones. If your app runs on a closed Pixel 11 Pro Fold, a Mate X7, a Mix Fold 4 or a Z TriFold, it is drawing into a window shaped almost exactly like the one it has been drawing into since 2017. Nothing breaks. Nothing even looks odd.

Two devices are not in that group. The Galaxy Z Fold 8’s cover is 1.58, squat but recognisable. And the iPhone Duo’s cover is 1.45 — the squattest cover display on any shipping foldable.

That single number carries more commercial weight than anything else in this post, so here is the implication spelled out:

• On every Android foldable except Samsung’s, the user has to deliberately open the device to reach the layout that breaks. Plenty of people rarely do. Your crash-free rate and your reviews stay intact for a while.
• On iPhone Duo, the broken layout is the default state. 1.45 is not a phone shape. A navigation bar tuned for 402 points of width, a fixed-height hero, a paywall laid out against a 2.17 ratio — all of that is already wrong on the screen the user looks at before they ever unfold anything.

An iPhone Duo owner meets your layout problem in the first five seconds. A Pixel Fold owner might not meet it for a week. The same defect, very different urgency.

If your app has fixed dimensions anywhere, that is where this lands first — see hard-coded screen dimensions, and the full iPhone Duo specifications for the exact point values on both panels.

Both platforms took orientation away from you

Here is the part that turns this from a hardware curiosity into a policy change. In the same year, Apple and Google both decided the app no longer gets to declare its own shape.

Apple. The iPhone Duo’s inner display does not honour your supported interface orientations. If you locked your app to portrait, you will still be laid out in landscape when the device is open. There is no opt-out and no compatibility mode. The details are in orientation lock is ignored.

Google. Android 16, API level 36, ignores the equivalent declarations on any display whose smallest width is 600dp or more — tablets, the inner display of a foldable, and desktop windowing. The list of things that stop working:

There is an escape hatch, and it has an expiry date:

<!-- Works while you target API 36. Gone at API 37. -->
<property
    android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
    android:value="true" />

Games are excluded, identified by the android:appCategory flag. Everything else is on the clock.

Two platform owners, with different hardware, different OS architectures and no particular reason to agree, arrived at the same rule in the same year. That is not a coincidence you should bet against. Treat “my app controls its own orientation” as a deprecated idea on both platforms, and the opt-out as a way to buy one release cycle, not as a position.

Stop branching on orientation. Branch on size.

Both platforms offer the same replacement, and have for years: classify the window you were given, rather than asking the device what it is.

On Apple’s side that is size classes. The iPhone Duo reports Regular width × Regular height on the inner display and Compact width × Regular height on the cover.

struct RootView: View {
  @Environment(\.horizontalSizeClass) private var width

  var body: some View {
    // Not: UIDevice.current.orientation, and not a screen-width threshold.
    if width == .regular {
      NavigationSplitView { Sidebar() } detail: { Detail() }
    } else {
      NavigationStack { Compact() }
    }
  }
}

On Android the same idea is WindowSizeClass, with published breakpoints:

val info = currentWindowAdaptiveInfo()
// One decision, every form factor: phone, cover screen, inner panel, desktop window.
when (info.windowSizeClass.minWidthDp) { /* … */ }

Note the 600dp threshold doing double duty: it is both the boundary where Android starts ignoring your orientation declarations and the compact/medium boundary. Google put the enforcement exactly where the guidance already was.

The practical rule for both platforms is the same, and it is worth stating flatly because it is the single highest-leverage change in this post: delete every branch keyed on orientation, idiom or a screen-width constant, and replace it with one keyed on the size class of the window you were handed. That one refactor covers the iPhone Duo’s two displays, every Android foldable’s two displays, tablets, split view and desktop windows simultaneously. More on the Apple side in size classes, not orientation.

The hinge is an API on both platforms

Size classes tell you how much room you have. They do not tell you that a physical crease runs down the middle of it. Both platforms expose that separately, and the models map onto each other closely enough to share a design.

The distinction that matters on both sides is whether something hides content or merely divides it. On Android the hinge itself can be either, depending on the device. On iPhone Duo Apple settles it: the fold is a division region, so the pixels are all there and you should avoid putting a tap target or a line of text across the crease, while the under-display FaceTime camera is an occlusion region that appears only while the camera is active. Apple also says hinge data is for interactions and effects, not layout; lay out with arrangements and reserved regions. We cover the Apple side in division regions and hinge interaction.

// Android: the same decision, different vocabulary.
val fold = collectFoldingFeaturesAsState().value.firstOrNull()
if (fold?.isSeparating == true && fold.orientation == FoldingFeature.Orientation.VERTICAL) {
  // Two logical panes, hinge running down the middle.
}

If you are building for both platforms, model the hinge once — as a rectangle plus a “hides content” flag plus a state — and write two thin adapters. The concepts are close enough that anything more elaborate is wasted work.

The web is the one platform with no answer

If your product is a website or a web view, none of the above is available to you on Apple hardware.

The web platform did solve this. The Viewport Segments API exposes each logically separate region of the viewport, and the Device Posture API exposes the fold state. Both shipped in Chrome 138, which means they work on every Android foldable in the table above.

Neither works in Safari. Intel filed WebKit standards positions for both in March 2024 and both are still open with no position recorded. So on an iPhone Duo, your responsive CSS will resize correctly and will have no way to know a crease exists. The full picture, including what to do instead, is in websites on iPhone Duo.

What actually has to change in your code

In rough order of cost-to-benefit, and all of it pays off on both platforms at once:

1. Delete orientation and idiom branches. Replace with size classes. Cheap, mechanical, and it is the change both platforms are now forcing. Start here.
2. Find your fixed dimensions. Any constant tuned to a ~400-point-wide phone is wrong by more than half on a 626-point inner display, and wrong in a different direction on a 466-point cover. Grep for numeric width and height constants.
3. Stop locking orientation. It no longer works on either platform’s large displays, and the Android opt-out expires at API 37.
4. Make navigation adaptive. A tab bar that becomes a sidebar at Regular width is the single most visible improvement on a large foldable panel, and it is the pattern both platforms’ own components already implement.
5. Handle the hinge. Keep tap targets and text runs off the crease, and distinguish division from occlusion.
6. Test the closed state first, on Apple hardware. This inverts the usual instinct. On Android the cover screen is a solved case; on iPhone Duo it is the least phone-shaped screen in the industry and the first one your user sees.
7. Handle resize as a continuous event, not a relaunch. The window changes shape mid-session. Anything cached at launch — a layout constant, a column count, an image crop — has to be recomputed.

Framework-specific versions of most of this are in the React Native and Flutter guides, and the device-by-device comparison of Apple and Samsung’s choices is in iPhone Duo vs Samsung Galaxy Z Fold.

If you would rather know what it costs before you commit engineering time to it, we do a free evaluation of a single app and tell you which of the seven above actually apply to your code.

One honest caveat

Worth being precise about where these numbers come from, because the distinction matters.

The Apple figures are Apple’s own, from its published specifications. Everything else comes from each vendor’s public specification page rather than from first-party developer documentation. Manufacturers round diagonals, so treat the derived ratios as close rather than exact. One case is not merely rounded: the Galaxy Z Fold 8’s pixel count gives 1.32, while Samsung publishes the panel as 4:3, which is 1.33. We use 1.33 throughout for consistency with Samsung’s own figure.

Three more limits on this post:

• Xiaomi’s 2026 foldable is not in the tables. A Mix Fold 5 has leaked, reportedly with a 7.6-inch 4:3 inner panel, but it has not been announced and leaked specifications are not checkable. The Mix Fold 4 is the current Xiaomi reference until that changes.
• Huawei’s OS is not Android. The global Mate X7 ships EMUI 15, and Huawei’s Chinese models run HarmonyOS. The Jetpack libraries discussed above are not the answer on those devices; the concepts transfer, the APIs do not.
• Flip-style foldables are deliberately excluded. A Z Flip or a Mix Flip folds along the short axis, so the unfolded screen is an ordinary phone and the layout problem never arises. They are a different product, not a smaller version of this one.

The platform behaviours — what Android 16 ignores, what the breakpoints are, what FoldingFeature exposes — are documented by Google and checkable. The conclusion that the two platforms have converged on taking shape control away from the app, and that Apple’s cover display is where this costs the most, is ours.