Skip to content
Mobile
Skill

/iphone-duo-capacitor

Adapt a Capacitor or Ionic app to iPhone Duo, Apple's first foldable iPhone — why the standard Device Posture and Viewport Segments CSS does not reach a web view, what CSS gives you today, and how to get fold state, hinge angle and bar placement from the native side. Use when a

From plugin
iphone-duo-skills
31011 skills

Claude Code

$ npx -y skills add mirzaaghazadeh/iphone-duo-skills --skill iphone-duo-capacitor --agent claude-code

SKILL.md

iphone-duo-capacitor.SKILL.md
name: iphone-duo-capacitor
description: Adapt a Capacitor or Ionic app to iPhone Duo, Apple's first foldable iPhone — why the standard Device Posture and Viewport Segments CSS does not reach a web view, what CSS gives you today, and how to get fold state, hinge angle and bar placement from the native side. Use when a Capacitor, Ionic, Angular, React or Vue app needs foldable iPhone support.

Capacitor on iPhone Duo

Start here, because it is the thing that will waste your afternoon otherwise:

> **WebKit 27.1 implements Device Posture and Viewport Segments, but both sit > behind an experimental flag that only Safari can set.**

A Capacitor app runs in a `WKWebView` it does not control the flags of, so `navigator.devicePosture`, the `device-posture` media query and the `env(viewport-segment-*)` variables are all absent there, while the same page in Safari on the same device can see them. Feature-detect rather than assume, and plan for both to be missing.

So the web platform gives you no fold awareness on this device out of the box. What it *does* give you is most of what matters. Work in two tiers.

Tier 1 — works today, no native code

Trust safe areas, and never assume symmetry

This is the one that produces real bugs. iOS moves its bars to **one side** of the display, and that side depends on the pose and the reading direction.

The bar arrives as a genuine safe-area inset: measured on the 27.1 simulator it is `env(safe-area-inset-right)` of **84px**, and it moves to `env(safe-area-inset-top)` of **82px** if the app opts out of vertical bars, live and without a reload. So most layouts need nothing more than honest `env(safe-area-inset-*)` padding on all four edges.

Any expression of the form `width - env(safe-area-inset-left) * 2` is a defect on this device.

Resize correctly

The window changes size constantly: opening, closing, folding, rotating, Split View. Read sizes when you need them rather than caching, and prefer container queries and `%`/`fr` layout over stored pixel values. Anything measured in a `useEffect` or `ngOnInit` and kept will be stale within seconds.

Think in size classes, not device checks

iOS reasons about this device in size classes: the outer display is **compact width**, the inner display is **regular width**. Branch on the size you were given, never on a user-agent string or an orientation, since the inner display does not honour supported orientations.

Measured on the simulator: inner display **951×669** in landscape, outer display **466×678**.

Move navigation to the side on the wide display

When iOS moves its own tab bars and toolbars to a vertical rail, an HTML tab bar pinned to the bottom looks unconverted next to every native app. A side rail on the inner display and a bottom bar on the outer one is the web analogue, and it costs one breakpoint.

Tier 2 — needs the native side

Everything genuinely iPhone Duo-specific is invisible to the web view until something native hands it over.

| Native API (iOS 27.1) | Why you want it in the web view | |---|---| | `reservedRegions(kind:options:)` on `UIView` | Where the fold and the camera are, so layout can avoid them | | `UIHingeInteraction` | Continuous hinge angle, for effects and posture | | `verticalBarEdge` on the trait collection | Which edge iOS moved the bars to, so your own chrome matches | | Size class from `traitCollection` | The signal iOS actually uses, rather than your breakpoint guess |

Two details worth knowing before you write any of this yourself. A flat phone's fold region is reported **inactive**, so reading it needs `options: .includeInactive` or you will conclude the device has no hinge. And `UIHinge.status` updates lazily, so it disagrees with the angle mid-fold; treat the angle as the truth when both are available.

Use the existing bridge

[`@erkamyaman/capacitor-foldable`](https://github.com/erkamyaman/capacitor-foldable) is an MIT plugin that already does this, and also fills in Device Posture and Viewport Segments so the standard CSS works in an app today:

npm install @erkamyaman/capacitor-foldable
npx cap sync
import { Foldable, installFoldablePolyfill } from '@erkamyaman/capacitor-foldable';

await installFoldablePolyfill();

const fold = await Foldable.getFoldState();
await Foldable.addListener('foldStateChange', (state) => layout(state));

The polyfill sets `--fold-left`, `--fold-width` and friends on `<html>`, so a grid can put its gutter exactly on the crease rather than guessing. The same build covers Android foldables through `androidx.window`.

Deeper material lives in [iphone-duo-capacitor-skills](https://github.com/erkamyaman/iphone-duo-capacitor-skills): the CSS patterns, the full API, Ionic specifics, and how to test on the simulator and on an Android emulator.

Ionic apps

Ionic's `ion-tabs` is HTML, so it stays at the bottom while native bars move. Two routes: a stylesheet that turns the tab bar into a side pill on the edge iOS chose, or [`@rdlabo/capacitor-native-ui`](https://github.com/rdlabo-dev/ionic-theme-ios27/tree/main/packages/capacitor-native-ui), which renders existing `ion-buttons`, `ion-button`, `ion-back-button` and `ion-tab-bar` with UIKit and SwiftUI while the originals, their state and their handlers stay in the web view. It takes device state as input, so the two compose rather than compete, and it lists the plugin in its own setup. The optional [`@rdlabo/ionic-theme-ios27`](https://github.com/rdlabo-dev/ionic-theme-ios27) adds iOS 27 styling on top.

What to do, in order

1. Audit every safe-area expression for assumed symmetry. Most bugs die here. 2. Stop caching sizes, and branch on the size you were handed. 3. Give the wide display a real layout rather than a stretched phone one. 4. Add the plugin, and feature-detect the standard APIs so the same build still works in a browser that has them. 5. Only then reach for hinge angle effects, which are the smallest part of

Read more
@mirzaaghazadeh
Ships withiphone-duo-skills

Image © Apple Inc., from the iPhone Duo developer page, used for identification. Not affiliated with or endorsed by Apple. Agent skills for building iOS apps on iPhone Duo — Apple's first foldable iPhone, announced September 9, 2026.

Stars on GitHub

Momentum

stars in total
310
Star history of mirzaaghazadeh/iphone-duo-skills on GitHub, a chart by star-history.com

Other skills on iphone-duo-skills.

More skills from other plugins.

deep-code-review

deep-code-review

In-depth design-focused code review - understands codebase context before evaluating PR changes, posts structured feedback to…

expo5d53k
@expo@expoInstall Skill
modlens

modlens

Plug-in vision for text-only models. Hard rule: when a file path or URL with an image extension (.png, .jpg, .jpeg, .webp, .gif,…

modlens3w4.6k
@liustack@liustackInstall Skill
appllama-app-design-skill

appllama-app-design-sk…

Build native-feeling, benchmark-quality mobile app screens (Expo / React Native). Use when designing or implementing any mobile…

appllama2mo3.9k
@appllama@appllamaInstall Skill

Questions about iphone-duo-capacitor.

Which coding agents can use iphone-duo-capacitor?
iphone-duo-capacitor installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.