React Native libraries on iPhone Duo: what shipped, and what is still a pull request

Your app is not one framework. It is React Native plus about forty libraries, and on 23 October a device arrives that none of them were written for.

So we went through the ones that decide layout, and asked a narrow question of each: does it know the screen can fold?

The short answer, on 13 October 2026, ten days out:

• One library has shipped Duo support. react-native-screens released it today.
• React Native’s own fold API does not exist yet. It is a pull request, open since 18 September.
• The library your safe areas depend on has nothing at all. Not an open issue, not a discussion. Zero.
• Expo’s hinge API is real, and npm install expo-hinge does not install it. The default tag is a placeholder published by someone else.

The table

Versions and states read from npm and the GitHub API on 13 October 2026. The commands are in the methodology.

The one that shipped

react-native-screens 4.30.0 went out on 13 October — the day this was written — and its notes open with “This release focuses on iOS 27 and iPhone Duo support in Stack v4.”

The specific bug it fixes is worth quoting, because it tells you what a Duo failure actually looks like:

On iPhone Duo (iOS 27) the same problem affects regular screens in portrait. The screen ended up partially under the header.

Not a crash. Your header overlapping your content, in portrait, on the display people will spend their money to look at.

If you use React Navigation’s native stack, you depend on this library whether you have heard of it or not. Check your lockfile for react-native-screens and see which version you are pinned to. This is the single highest-value thing in this article and it takes ten seconds.

The fold API that does not exist yet

React Native has no supported way to ask where the fold is. The API that would provide it is PR #58594, Add Dimensions.getDisplayFeatures / useDisplayFeatures (iPhone Duo), open since 18 September — a week before the device was even orderable.

It is not the only one in the queue. useScreenDimensions has been proposed twice: #58908 closed unmerged on 7 October, and #58987 opened on 11 October.

And one that deserves its own line: issue #58606, React Native 0.88.x-rc crash on iPhone Duo, open since 19 September. If you were planning to meet the device on the 0.88 release candidate, read that thread before you commit to it.

None of this blocks you. The fold is a nice to have — Apple’s own guidance is to lay out against your container and size classes rather than against the hardware, which is the same advice we give on what to fix first. But if your plan involved detecting the hinge from JavaScript, the plan does not have an API yet.

Expo has the API. Installing it the obvious way gets you the wrong package

Expo is well ahead of core React Native here, and there is a trap in front of it that will cost somebody an afternoon.

npm install expo-hinge resolves to the latest tag, which is version 0.0.0, published 28 September. Its description, in full:

Reserved name. Use expo-foldables.

That is not Expo’s module. It has no repository field, and the package it redirects you to — expo-foldables — is a community package from an individual’s account, not from Expo.

The real one is on the next tag:

npm install expo-hinge@next    # 58.0.1

That version is published by 650 Industries from expo/expo at packages/expo-hinge, documented at its own SDK documentation, and described as “Provides the device hinge angle and status on iPhone Duo and Android foldables.” It is on next rather than latest because Expo versions its packages with the SDK, and SDK 58 is not stable yet.

So the hinge API exists, it is official, and the default install command does not give it to you. Check what you actually got:

npm ls expo-hinge

If it says 0.0.0, you installed the placeholder.

Two more from the Expo repository:

• [ios][display-features] Add expo-display-features module — still open, proposed 18 September, never published to npm.
• [ios][apps] Respect horizontal safe area insets on iPhone Duo — merged on 21 September. Real work, and on the asymmetric-inset problem specifically.

The gap that matters most

react-native-safe-area-context is in essentially every React Native app, and it owns the exact thing iPhone Duo changes.

On every previous iPhone the left and right safe-area insets were the same, so a great deal of code reads one and doubles it. On iPhone Duo they are asymmetric — that is the defining layout fact of the device, and the checklist item for it is a blocker, not a polish.

Searching its repository for iPhone Duo returns zero results. Not an open issue, not a closed one. Its last six releases, back to May, mention nothing about folds, hinges or asymmetry.

To be fair to the library: it may not need changes. It reports what UIKit gives it, and UIKit on iOS 27 reports asymmetric insets correctly. The bug is far more likely to be in your code than in theirs — which is exactly why nobody is going to fix it for you. Run this:

grep -rn "insets.left \* 2\|insets.right \* 2\|insets.left +" src/
grep -rn "paddingHorizontal.*insets" src/

Every hit is a line that assumed both sides match.

What to actually do in the next ten days

In order, highest value first:

1. Bump react-native-screens to 4.30.0. It is the only library that has shipped Duo fixes, and the bug it fixes is visible in portrait.
2. Grep for symmetric safe-area maths. Nothing is going to catch this for you.
3. Do not wait for the fold API. It is an open PR, and you do not need it — size classes and container-relative layout handle the resize.
4. If you are on 0.88.x-rc, read issue #58606 before launch day.
5. Treat expo-hinge as a preview. Version 0.0.0 means what it says.

Methodology

All of it is reproducible. Versions:

for p in react-native react-native-screens react-native-safe-area-context \
         react-native-reanimated @react-navigation/native expo-hinge; do
  npm view "$p" version time.modified
done

Pull request and issue states, per repository:

curl -s -G https://api.github.com/search/issues \
  --data-urlencode 'q=repo:react/react-native "iPhone Duo"' | jq '.items[] | {number, title, state}'

Swap the repository for software-mansion/react-native-screens, appandflow/react-native-safe-area-context, expo/expo or software-mansion/react-native-reanimated. Unauthenticated search allows ten requests a minute, which is the only thing that will slow you down.

Two honest limits. Open pull requests move — the dates are the point of this article, not a permanent status, and anything here could merge the week you read it. And a repository with no issue about iPhone Duo is not proof that a library breaks on it; it is evidence that nobody has reported one, which for a device that has not shipped is a weaker claim than it sounds.

If you would rather have someone establish which of your dependencies actually break, on your own code rather than in general, that is what the audit covers.