iPhone Duo vs Samsung Galaxy Z Fold: what differs for developers

Spec-sheet comparisons of these two devices are everywhere. This is not one. The question that matters if you build software is narrower: if my app runs on both, how many different things do I now have to handle?

Fewer than you would expect on layout. More than you would expect on APIs.

The displays

Apple and Samsung both arrived at a 7.6-inch inner display. They did not arrive at the same shape.

Apple’s inner panel is the tallest and narrowest of the three. Samsung’s Fold 8 is wider and shorter; the Ultra is closer to square than anything else shipping.

The cover screen is the bigger divergence

The inner displays differ by a manageable amount. The cover displays are barely the same category of device.

• Z Fold 8 Ultra: 2.33 — a conventional phone. Your existing phone layout works, unchanged.
• Z Fold 8: 1.58 — squat, but recognisable.
• iPhone Duo: 1.45 — closer to a small square than a phone.

A folded iPhone Duo puts your app in a substantially more unusual environment than a folded Fold Ultra does. If you are testing one cover screen and assuming the other behaves similarly, it does not.

What is genuinely the same

Both platforms want the same thing from you, and it is not fold-specific:

• Layout driven by available space, not device identity. Apple’s size classes and Android’s WindowSizeClass express the same idea.
• Content that reflows rather than scales. On both, a fixed-aspect layout either crops or letterboxes.
• Handling resize mid-session. Both support multi-window; both change your window without relaunching you.

If your app already adapts properly on Android foldables, the iPhone Duo work is mostly configuration. The hard part — accepting that width is a variable — is already done.

What is genuinely different

Apple arrived at Android’s model, five years later

This is the most useful thing to notice. Android’s FoldingFeature, stable since Jetpack WindowManager 1.1 in 2023, exposes:

• state — FLAT or HALF_OPENED
• orientation — HORIZONTAL or VERTICAL
• occlusionType — NONE or FULL

Apple’s ReservedRegion, new in iOS 27.1, distinguishes:

• division regions — split an area in two (the hinge)
• occlusion regions — cover an area (the under-display camera)

It is the same idea, applied differently. Android asks of the hinge itself “does this feature occlude?”. Apple encodes the answer in the region’s kind, and on iPhone Duo the hinge is always a division region while the occlusion region is the inner camera, active only while the camera is on. A developer who has shipped fold-aware Android code will find Apple’s model immediately familiar.

Where Apple goes further

Vertical bars. Under the iOS 27.1 SDK, navigation, toolbar and tab bar controls share a single vertical region at the side on the outer display and on the inner display in landscape; only the inner display in portrait keeps horizontal bars. Android has no equivalent system behaviour — bars stay where you put them. This is the change most likely to surprise an Android developer porting across, and it is worth reading up on before you assume your bar layout carries over.

Scene accessories. iPhone Duo can show supplementary UI on the outer display while the main UI runs on the inner one. Android’s rear display mode is comparable in spirit but narrower in practice.

Where Android goes further

Maturity. Android foldable APIs have had roughly five years of real devices, real bugs and real documentation. Apple’s are days old and the written documentation was still unpublished at launch.

Tooling. Android Studio has had foldable emulators and fold postures for years. Xcode’s Device Hub is new.

And on the web, they diverge completely

Chrome supports the Viewport Segments API, so a website on an Android foldable can lay out around the hinge. Safari does not, and WebKit has taken no position on either that or the Device Posture API — both proposals have sat open since March 2024.

So the same website can be fold-aware on a Galaxy Z Fold and fold-blind on an iPhone Duo, with no change on your side. Covered in Websites on iPhone Duo.

If you ship on both

A realistic order of work:

1. Fix space assumptions once. Fixed widths, orientation locks and device-identity checks break on both platforms. This is shared work and the bulk of it.
2. Handle asymmetric insets on iOS. Apple’s safe areas are asymmetric in a way Android’s typically are not. A symmetric-inset assumption survives on Android and fails here.
3. Budget separately for Apple’s vertical bars. No Android equivalent, so nothing in your Android codebase prepares you for it.
4. Map fold handling rather than rewriting it. If you have FoldingFeature logic, it ports to ReservedRegion conceptually. The abstraction transfers even though the API does not.
5. Test both cover screens. 1.45 and 2.33 are not variations of one layout.

Samsung is not the only comparison worth making. Across all nine shipping foldables the inner panels run from 1.04 to 1.43 and the cover panels from 1.45 to 2.37, and Apple sits at an extreme of both — see designing apps for the foldable era for the full landscape and what Android 16 now enforces.

For React Native and Flutter the fold APIs are unreachable on the iOS side without native work — neither vendor has shipped iPhone Duo support. That is covered in the framework guides.

One honest caveat

The Apple figures here come from Apple’s own specifications and Tech Talks and are firm. The Samsung figures come from published specifications; treat the derived aspect ratios as close rather than exact, since manufacturers round diagonals. The comparison holds at the level that matters — the shapes really are different — but do not build a pixel-exact layout from a table on the internet, including this one.