[saqibkayani2077]

What

Adds a DisplayFeatures plugin exposing native display metadata that web content can't read from CSS alone: active size class, device pose, and reserved-region frames (hinge/camera) — starting with iPhone Duo, Apple's first foldable iPhone, announced September 9, 2026.

WKWebView already resizes with the window and exposes env(safe-area-inset-*) to CSS, so basic layout adaptation on iPhone Duo works without this plugin. This is for the cases JS needs to decide something CSS can't express: which size class is active (the HIG's primary outer/inner-display signal), whether the device is partially folded, and where the folding region or an active camera region sits.

Why

The reserved-region/pose model follows Apple's Tech Talk 111463 ("Strike a pose with adaptive layouts on iPhone Duo") and the Designing for iPhone Duo HIG.

Current limitation — please read before reviewing

The iOS 27.1 SDK that ships the underlying reserved-region APIs (UIView.reservedRegions(kind:)) is not publicly available yet — Apple lists Xcode 27.1 beta as "coming later this month" as of 2026-09-10. So today, getDisplayFeatures() honestly reports supported: false and never guesses at pose/region data. Size classes, safe-area insets, and bounds are real values on every iOS device today. The native DisplayFeaturesProvider protocol is structured so a real implementation can be dropped in once the SDK ships, without changing the public API.

The Swift side is unverified — I don't have Xcode in the environment I used to write this, so DisplayFeatures.swift has never been compiled. Everything else has:

Test plan

npm run test (ts-jest) from core/ — all 5 tests pass:

DisplayFeatures
  ✓ getDisplayFeatures proxies to the native implementation and returns its result untouched
  ✓ addListener on native returns a removable handle for displayFeaturesChanged
  ✓ delivers displayFeaturesChanged state to listeners
  ✓ rejects as unavailable on web
  ✓ rejects as unimplemented on a native platform without the plugin

ts-jest type-checks as part of running, so the TS API surface is type-verified, not just written.

Disclosure

This PR was written with AI assistance (Claude Code), directed and reviewed by me. Happy to answer questions, adjust the approach, or close this if a different direction (e.g. extending an existing plugin, or waiting for the SDK to be public) is preferred.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LAkF81dVyenmpEChH2Nh1k

[theproducer]

This is intriguing! I haven't looked this over in detail yet, but have you thought about adding Android support for similar display features?

[saqibkayani2077]

Great suggestion, Joey! Android is actually in a much better position than iOS here: androidx.window (Jetpack WindowManager) already ships FoldingFeature — state (FLAT/HALF_OPENED), orientation, occlusionType, and bounds — mature, stable, and in production on real foldables (Galaxy Z Fold, Surface Duo, etc.), unlike the iOS side in this PR, which depends on an iOS 27.1 SDK Apple hasn't publicly released yet.

I'm going to add real Android support mapping FoldingFeature onto the same DisplayFeaturesState shape this PR already defines (currently {supported, pose, activeDisplay, horizontalSizeClass, verticalSizeClass, reservedRegions, safeAreaInsets, bounds} — some of those iOS-specific fields would need rethinking for a shared cross-platform shape, will think through that). Unlike the iOS half, I can actually compile and test this against the real SDK, so it won't carry the same caveats. Will follow up here once it's ready.

[saqibkayani2077]

Android support is up. A few notes on how it turned out:

This one is fully compiled and tested against the real SDK (unlike the iOS half, which I flagged as unverified) — ./gradlew clean lint build test -b capacitor/build.gradle (the exact command this repo's own CI runs) is green: lint clean against the baseline, both debug and release unit tests pass, including 5 new test cases.

Backed by androidx.window's FoldingFeature — stable since 2021, used in production on real foldables. It reuses the existing reservedRegions/pose fields rather than adding new API surface. A couple of fields genuinely don't have an Android equivalent (activeDisplay, the two size-class fields — those are iPhone-Duo/UIKit-specific concepts), so those report 'unknown'/'unspecified' on Android rather than guessing at something. Full reasoning is in the commit message.

Two real bugs only showed up once I actually compiled it — WindowInfoTrackerCallbackAdapter wants androidx.core.util.Consumer, not java.util.function.Consumer, and Rect.width()/height() throw under the unit-test stub jar (fixed with field arithmetic instead). Neither would've been caught by review alone.

[erkamyaman]

For anyone who needs it today, @erkamyaman/capacitor-foldable (npm) covers all of this for Capacitor 7 and 8.

• iOS: iPhone Duo support on the real iOS 27.1 SDK. Built with Xcode 27.1 and tested on the iPhone Duo simulator: closed, book, tabletop and fully open, in every rotation.
• Android: Jetpack WindowManager, tested on Galaxy Z Fold8, Z Flip8 and Z Fold8 Ultra.
• Web: a Device Posture and Viewport Segments polyfill, so plain CSS reacts to the fold.

It reports fold state, posture, hinge position and angle, size classes, and where iPhone Duo moves native bars, with change events for each.