@erkamyaman/capacitor-foldable 8.1.0 → 8.3.0

package/skills/capacitor-foldable/references/api.md

@@ -0,0 +1,112 @@
+# The API, and when each part is the right tool
+
+Every **read** method resolves safely on any device, foldable or not. `startRearDisplay()` and `startDualScreen()` reject when the mode is not available; the `stop` methods always resolve.
+
+Platform note up front: `hingeMargins`, `activeDisplay` and the hinge `status` are iOS only; `occludedBounds` is Android only. `cameraBounds` is reported on both, and on iOS it carries every active occlusion, which includes the vertical status bar strip as well as the camera.
+
+Import both the plugin and the polyfill from the package root:
+
+```typescript
+import { Foldable, installFoldablePolyfill } from '@erkamyaman/capacitor-foldable';
+```
+
+## Ask once
+
+```typescript
+const { foldable, supportsTabletop } = await Foldable.isDeviceFoldable();
+```
+
+`supportsTabletop` is a real check on Android (the system advertises the posture). On iOS it mirrors `foldable`, so it is not an independent signal there.
+
+Do not gate layout on this: an Android foldable that advertises no tabletop posture and has no hinge sensor answers `false` while still reporting a fold. For "is there a fold on this screen", test for `hingeBounds`, remembering a closed device has none. For the outer screen on Android, gate on `getDisplayModes()` instead.
+
+## The fold
+
+```typescript
+const fold = await Foldable.getFoldState();
+// state: 'flat' | 'half-opened' | 'closed'   ('closed' is never emitted today)
+// posture: 'flat' | 'tabletop' | 'book'
+// isSeparating, hingeOrientation, hingeBounds
+// cameraBounds                (both: cutouts on Android, active occlusions on iOS)
+// occludedBounds              (Android only, when the fold fully occludes content)
+// hingeMargins, activeDisplay (iOS only)
+```
+
+Use `posture` for layout decisions rather than the raw angle. On iOS it is a threshold on the angle at 20 and 160 degrees with no hysteresis, so avoid designs that flip hard exactly at the boundary; on Android it comes straight from WindowManager's own fold state.
+
+`activeDisplay` tells the outer display from the inner one, but only on iOS. On Android use `getSizeClass()` for the same job.
+
+Listen with `foldStateChange` rather than polling. On Android the very first call can time out after a second and answer `flat`, so treat the first event as the real answer rather than a boot-time read.
+
+## The hinge angle
+
+```typescript
+const { angle, status } = await Foldable.getHingeAngle();
+// angle: degrees, 0 shut and 180 flat, or null without a hinge sensor
+// status: 'closed' | 'partiallyOpen' | 'fullyOpen' | null   (iOS only)
+```
+
+`hingeAngleChange` fires as it moves, carrying the angle alone: call `getHingeAngle()` if you also need the status. On iOS the system's `status` updates lazily and can disagree with the angle; the plugin trusts the angle, and returns both so you can see it. Android reports no status at all.
+
+Good for effects and continuous interactions, not for deciding layout.
+
+## Reserved regions (iOS 27.1)
+
+```typescript
+const { regions } = await Foldable.getReservedRegions();
+// kind: 'division' | 'occlusion', isActive, x/y/width/height, margins
+```
+
+Everything the system reserves on the current display: the fold, the camera, and the strip the vertical status bar occupies. Inactive regions are included, which is how the fold is reported while the device is open flat. Returns `[]` on Android, on web, and on iOS before 27.1.
+
+These coordinates come from the view controller's view, while `hingeBounds` is measured against the web view, so do not mix the two if your web view is inset.
+
+## Size classes
+
+```typescript
+const { horizontal, vertical, widthClass, heightClass } = await Foldable.getSizeClass();
+```
+
+Apple's compact and regular plus Material's window classes. On iOS the first pair are real UIKit traits; on Android and web they are breakpoints on the window size. Either way it is the portable way to tell a small screen from a large one, rather than measuring pixels yourself. `sizeClassChange` fires when it changes.
+
+## Where the system put its bars
+
+```typescript
+const { verticalBarEdge } = await Foldable.getBarPlacement(); // 'leading' | 'trailing' | null
+```
+
+`null` means no vertical bar edge is reported: bars are horizontal, or the platform cannot say, which is always the case on Android, web and iOS before 27.1. On iPhone Duo the bar also arrives as a safe-area inset, so simple layouts need nothing beyond `env(safe-area-inset-*)`. Use this when positioning your own chrome to match. `barPlacementChange` fires when it moves.
+
+```typescript
+await Foldable.setVerticalBarBehavior({ behavior: 'disabled' });  // everything horizontal
+await Foldable.setVerticalBarBehavior({ behavior: 'automatic' }); // system default
+```
+
+Needs `FoldableBridgeViewController`, and resolves `{ applied: false }` when that is missing, on Android, and on web. On iOS any other string rejects, while a missing one falls back to `automatic`; Android and web resolve without validating. Apple asks you not to override bar placement, so keep this for immersive interfaces.
+
+## While the hinge moves
+
+```typescript
+await Foldable.addListener('foldingChange', ({ folding }) => { /* pause heavy work */ });
+```
+
+Only fires where a hinge angle is available: an Android foldable with a hinge sensor, or iPhone Duo on iOS 27.1.
+
+## Android display modes
+
+```typescript
+const { rearDisplay, dualScreen } = await Foldable.getDisplayModes();
+// each: 'active' | 'available' | 'unavailable' | 'unsupported'
+
+if (rearDisplay === 'available') await Foldable.startRearDisplay();
+if (dualScreen === 'available') await Foldable.startDualScreen({ url: 'cover.html' });
+
+await Foldable.stopRearDisplay();
+await Foldable.stopDualScreen();
+```
+
+`startRearDisplay()` shows a system confirmation first, and `startDualScreen()` rejects outright without a `url`. Both accept `available` or `active`.
+
+`displayModeChange` reports both modes together. Relative URLs resolve against the app's own URL, so `cover.html` has to be a page you ship in the web build, which for a bundler means adding it as an extra entry point. A `data:` URL works too, and is the easier route for dynamic content. That page runs in its own web view with no access to Capacitor plugins, and calling `startDualScreen` again replaces it.
+
+Android only; both read as `unsupported` on iOS and web, where the `start` methods reject. See [android.md](android.md).

package/skills/capacitor-foldable/references/css-layout.md

@@ -0,0 +1,127 @@
+# Laying out around the crease
+
+After `installFoldablePolyfill()` on a native platform, the plugin keeps these on `<html>`.
+
+| | |
+| --- | --- |
+| Direction, while a fold is reported | `.fold-vertical` (crease runs down the screen), `.fold-horizontal` (across) |
+| Position and size of the fold band | `var(--fold-left)`, `var(--fold-top)`, `var(--fold-width)`, `var(--fold-height)` |
+| How much of the band is margin (iOS only) | `var(--fold-margin-top)`, `--fold-margin-right`, `--fold-margin-bottom`, `--fold-margin-left` |
+| While the hinge moves | `.folding` |
+| Where native bars went | `.vertical-bars-leading`, `.vertical-bars-trailing`, `var(--vertical-tab-bar-bottom)` |
+| Standard APIs, polyfilled | `.horizontal-viewport-segments-2`, `.vertical-viewport-segments-2`, `.device-posture-folded`, `.device-posture-continuous`, `var(--viewport-segment-*)` |
+
+Three things to know before using them:
+
+- **They are viewport coordinates**, measured against the web view. A grid built from `--fold-left` only lines up if the element's own content box starts at viewport 0. Subtract your own insets otherwise, as the examples app does.
+- **`--fold-width` can be `0px`.** A seamless fold, the kind with no physical gap, reports zero thickness whatever the state, and `--fold-margin-*` is iOS only and reads `0px` on Android. Keep your own minimum gutter, `max(12px, var(--fold-width, 0px))`, rather than relying on the band for visual separation. The fallback matters: on a phone with no fold the variable does not exist, and a bare `var()` with no fallback makes the whole declaration invalid.
+- **`.fold-horizontal` means the hinge is horizontal, not that the device is in tabletop.** It is set while flat too. The tabletop and book postures have no class of their own: read `posture` from `getFoldState()`. (The `.device-posture-*` classes in the table are the Device Posture API's folded and continuous, which is a different thing.)
+
+What is conditional: the `--fold-*` variables, `.fold-*`, `.vertical-bars-*`, `.folding` and the `-viewport-segments-2` classes. What is always set once installed: a `device-posture` class (`continuous` unless half opened), the first segment's `--viewport-segment-*-0-0` variables, and `--vertical-tab-bar-bottom`.
+
+For safe areas, write `var(--safe-area-inset-top, env(safe-area-inset-top))`. Capacitor injects those variables on **Android** from 8.3 with `insetsHandling: 'css'`, where `env()` is unreliable before WebView 140; on iOS nothing sets them and the `env()` fallback is what resolves.
+
+## Two pages, one either side
+
+```css
+.reader { display: grid; gap: 12px; }
+
+.fold-vertical .reader {
+  position: fixed;
+  inset: auto 0 0 0;
+  top: calc(var(--safe-area-inset-top, env(safe-area-inset-top)) + 56px);
+  display: block;
+  border: 0;
+}
+
+.fold-vertical .reader .page {
+  position: absolute;
+  top: 0;
+  bottom: 0;
+  padding: 14px;
+  box-sizing: border-box;
+  overflow: auto;
+}
+
+.fold-vertical .reader .page:first-child { left: 0; width: var(--fold-left); }
+.fold-vertical .reader .page:last-child { left: calc(var(--fold-left) + var(--fold-width)); right: 0; }
+```
+
+`position: fixed` with `inset` is what makes the viewport coordinates line up, and `top`/`bottom` on the pages is what makes them fill the container. Keep a border off the container: unlike padding, a border shrinks the containing block and shifts both pages off the fold. The pages carry their own padding, with `box-sizing: border-box` so it eats into the width instead of overflowing the crease.
+
+## A grid whose gutter is the crease
+
+Give the crease its own column, so the normal gutter survives when `--fold-width` is zero, and pin the tiles to the columns either side. Do not rely on a `::before` to reserve the crease column: with no explicit rows, `grid-row: 1 / -1` spans row 1 only, and auto-placement drops tiles into the crease from row 2 down.
+
+```css
+.grid { display: grid; grid-template-columns: repeat(2, 1fr); gap: 16px; }
+
+.fold-vertical .grid {
+  --grid-inset: 16px; /* viewport left edge to this element's content box */
+  grid-template-columns: calc(var(--fold-left) - var(--grid-inset)) var(--fold-width) 1fr;
+  column-gap: 0;
+}
+
+.fold-vertical .grid > *:nth-child(odd) { grid-column: 1; }
+.fold-vertical .grid > *:nth-child(even) { grid-column: 3; }
+.fold-vertical .grid > * { margin: 0 8px; }
+```
+
+The crease is always the middle track, so the pinning selectors have to skip it. `nth-child(odd)` and `nth-child(even)` is the two column special case; with four columns the tracks become
+
+```css
+.fold-vertical .grid {
+  grid-template-columns:
+    repeat(2, calc((var(--fold-left) - var(--grid-inset)) / 2))
+    var(--fold-width)
+    repeat(2, 1fr);
+}
+
+.fold-vertical .grid > *:nth-child(4n + 1) { grid-column: 1; }
+.fold-vertical .grid > *:nth-child(4n + 2) { grid-column: 2; }
+.fold-vertical .grid > *:nth-child(4n + 3) { grid-column: 4; }
+.fold-vertical .grid > *:nth-child(4n) { grid-column: 5; }
+```
+
+Apple asks for an even number of columns so content divides cleanly. Either way the tracks left of the crease must add up to `--fold-left` minus your inset, so use explicit widths there rather than `1fr`.
+
+## Controls below the crease in tabletop
+
+Tabletop is a posture, so it comes from JavaScript. Set a class yourself and let CSS follow:
+
+```typescript
+const apply = ({ posture }: { posture: string }) =>
+  document.documentElement.classList.toggle('tabletop', posture === 'tabletop');
+
+apply(await Foldable.getFoldState());
+const handle = await Foldable.addListener('foldStateChange', apply);
+// later: await handle.remove();
+```
+
+```css
+.tabletop .stage {
+  position: fixed;
+  inset: 0;
+  display: grid;
+  grid-template-rows: var(--fold-top) 1fr;
+  row-gap: max(12px, var(--fold-height));
+}
+```
+
+`position: fixed; inset: 0` matters here too: `--fold-top` is measured from the top of the viewport, and a `.stage` sitting under a header is not.
+
+## Pause work while the hinge moves
+
+```css
+.folding .spinner { animation-play-state: paused; }
+```
+
+`animation-play-state` is not inherited and only affects elements that carry a CSS animation, so put it on the animated element itself. For a chart or anything driven by JavaScript, listen to `foldingChange` and stop redrawing instead. The class appears as the hinge starts moving and goes half a second after it stops, and only on devices that report a hinge angle: an Android foldable without a hinge sensor never gets it.
+
+## What not to do
+
+- Splitting at `50%`. The coordinates are relative to the web view, and on iPhone Duo the band has width.
+- Relying on `--fold-width` for visual separation. It is `0px` on a seamless fold.
+- Treating `.fold-horizontal` as tabletop, or writing a separate layout per posture. Let one layout expand, and move only what must move.
+- Styling only `.fold-vertical`. iPhone Duo's crease is vertical in landscape and horizontal in portrait, so both need an arm or the layout flattens when the phone turns.
+- Building layout on the polyfilled `--viewport-segment-*` variables. They only describe two segments while the fold actually separates the window, so an open-flat device gives you one segment; the `--fold-*` variables are there either way.

package/skills/capacitor-foldable/references/ionic.md

@@ -0,0 +1,50 @@
+# Ionic apps
+
+## The tab bar belongs on the side
+
+On iPhone Duo the system moves native toolbars and tab bars to the side of the display as a floating pill. Ionic's `ion-tabs` is HTML, so it stays a full width bar at the bottom, next to a status bar that has already moved.
+
+```typescript
+import '@erkamyaman/capacitor-foldable/ionic-tabs.css';
+```
+
+That turns `ion-tabs` into a side pill exactly where native bars go, and only where the system actually puts bars there. It keys on the `vertical-bars-leading` and `vertical-bars-trailing` classes, which `installFoldablePolyfill()` sets, so the stylesheet does nothing on its own. There is also `ionic-tabs-ios26.css`, which gives the horizontal bar iOS 26's floating look on every iPhone.
+
+**Angular cannot import CSS from TypeScript.** That is TypeScript's error rather than Angular's: a side-effect import of a `.css` file has no type declarations, which TypeScript 6 reports as TS2882 (`noUncheckedSideEffectImports` is on by default there) and older versions as TS2307. Angular's `styles` array in `angular.json` is the other normal route. Put it in `src/global.scss` instead, and **as the first rule in the file**, because Sass rejects `@use` after any other rule, including the `@import` lines a stock Ionic `global.scss` starts with:
+
+```scss
+@use '@erkamyaman/capacitor-foldable/ionic-tabs.css';
+
+@import "@ionic/angular/css/core.css";
+// ...the rest of the Ionic imports
+```
+
+React and Vue import it from the entry file as usual, since their bundlers ship type shims for CSS.
+
+## A fold fires a keyboard event
+
+iPhone Duo sends a keyboard event when the device folds. Ionic's keyboard controller measures the app container's height the first time the keyboard opens and caches it, then waits for that exact height before showing the tab bar again. After a fold the height no longer matches, so the bar never comes back. Opt in to the fix:
+
+```typescript
+await installFoldablePolyfill({ ionicKeyboard: true });
+```
+
+It swallows Capacitor's raw keyboard events in the capture phase and puts a `foldable-keyboard-open` class on `<html>` only when something is genuinely focused. That class does nothing on its own: `ionic-tabs.css` carries the rule that hides the bar while the keyboard is up, so take both or neither. The `ios26` stylesheet does not carry that rule. Off by default, since it takes over those events.
+
+## Two views of one screen
+
+If your app has two modes that are really one screen, swap the view in place rather than routing between tabs. Routing mounts a lazy page on every tap, which shows as a blank frame, and Ionic's page transition then slides the new page in sideways, which is very visible on a wide inner display.
+
+```typescript
+readonly mode = signal<'game' | 'meter'>('game');
+```
+
+```html
+@if (mode() === 'game') { <app-game /> } @else { <app-meter /> }
+```
+
+If you do route, `provideIonicAngular({ animated: false })` removes the slide, but be aware it disables every Ionic animation app-wide, including modals and ripples.
+
+## Styling gotcha
+
+`ion-tab-bar` ships `contain: strict`, which brings size containment with it. The moment you let either dimension come from its contents, it lays out as if empty and collapses: height in the side pill, width in the iOS 26 variant. Both shipped stylesheets set `contain: none` for that reason.

package/skills/capacitor-foldable/references/iphone-duo.md

@@ -0,0 +1,54 @@
+# iPhone Duo
+
+Needs iOS 27.1 and Xcode 27.1 or later. Older versions compile and simply report no fold.
+
+## Measured geometry
+
+Inner display 951 x 669 points in landscape, outer 466 x 678. The fold arrives in JavaScript as `hingeBounds` of x 456, width 40, and a separate `hingeMargins` of 20 points left and right. Those margins are *inside* the band rather than extra to it, so the crease itself is the zero width centre and the whole 40 points is the keep-clear area.
+
+UIKit reports the region on a half point, and the plugin rounds to whole CSS pixels.
+
+## The fold is inactive when flat
+
+A fully open iPhone Duo still has a fold, but the system marks that region inactive. The plugin always asks for inactive regions, which is why `--fold-left` is set whether the device is open flat or half folded. Below 20 degrees the plugin drops the fold, so a closed device reports no `hingeBounds` and no `--fold-*` on the outer display, even though `getReservedRegions()` still lists the region.
+
+Writing native code beside the plugin, the same call needs it spelled out:
+
+```swift
+if #available(iOS 27.1, *) {
+    let regions = view.reservedRegions(kind: .division, options: .includeInactive)
+}
+```
+
+## The hinge status lags the angle
+
+Apple's header suggests preferring `status` when you only need open, closed or partly open. In practice it updates lazily, so the two disagree while the device moves, which is this plugin's own observation rather than documented behaviour. The plugin decides the fold state from the angle whenever a fold region exists, falling back to the status otherwise, and `getHingeAngle()` returns both so you can see the disagreement yourself.
+
+## Vertical bars and safe areas
+
+The system moves bars to the side, and the web view's safe areas follow. Measured on the simulator: with bars on the side, the strip arrives as `env(safe-area-inset-right)` of 84 points on both displays. Calling `setVerticalBarBehavior({ behavior: 'disabled' })` moves it to `env(safe-area-inset-top)` of 82 and drops the right inset to zero, live and without a reload.
+
+So for most layouts, padding with the safe-area insets is enough, and `getBarPlacement()` is for when you are positioning your own chrome to match the system's.
+
+The opt-out needs the plugin's view controller in `ios/App/App/SceneDelegate.swift`:
+
+```swift
+import Capacitor
+import FoldablePlugin
+
+window?.rootViewController = FoldableBridgeViewController()
+```
+
+`FoldablePlugin` is the module name for a Swift Package install, which is what `npx cap add ios` sets up for a new Capacitor 8 app. On a CocoaPods install the module is `ErkamyamanCapacitorFoldable`. Older apps that build the controller in `Main.storyboard` set the class there instead.
+
+## The web view pauses between displays
+
+When the app moves between the outer and inner display, the web view stops running: timers freeze and events queued during the fold arrive late. That is this project's own observation from the simulator rather than documented behaviour, but it is consistent and worth designing around. If your app reads the hinge continuously, refresh state on `visibilitychange`, `focus` and `resize` after a fold, and keep a slow poll as a safety net.
+
+The window can also report its previous size for a moment after a fold. The polyfill already measures again on the next frame and once more shortly after, so CSS variables settle by themselves.
+
+## What crosses the crease
+
+Keep interactive and readable content out of the fold band; continuous visual content such as a photo, a map or a drawing canvas can cross it, and so can scrolling content.
+
+Apple's own fold guidance is to prefer a layout container that adapts by itself, to "prefer an even number of columns so content divides cleanly" in a grid, to "use the `ReservedRegion` API to keep important elements clear of the center if the system doesn't move them automatically", and to favour small adjustments over rearrangement as the device folds.

package/skills/capacitor-foldable/references/testing.md

@@ -0,0 +1,53 @@
+# Testing a foldable layout
+
+## iPhone Duo simulator
+
+Needs the iOS 27.1 runtime, which the device type refuses to go below, and Xcode 27.1 to build against the 27.1 SDK. Build against the 27.0 SDK and the app fills more of the inner display but still leaves gaps; build against anything older and it runs in compatibility mode inside a black border with no fold reported. The iOS 27.2 beta runtime does not run iPhone Duo at all, as observed on this beta. In Xcode 27 the simulator lives inside **DeviceHub.app**, not `Simulator.app`.
+
+```bash
+open "$(dirname "$(xcode-select -p)")/Applications/DeviceHub.app"
+npx cap run ios     # pick the iPhone Duo
+```
+
+If several Xcodes are installed, check `xcode-select -p` first, or set `DEVELOPER_DIR` to the 27.1 one for the build, or the app compiles against the wrong SDK and reports no fold.
+
+Fold it with the hinge slider in DeviceHub; hold Option for finer control. The inner and outer displays are separate windows.
+
+Screenshots from the terminal, where display 1 is the outer screen and display 3 the inner. The ids are not guaranteed, so `xcrun simctl io <udid> enumerate` lists them:
+
+```bash
+xcrun simctl io <udid> screenshot --display=3 inner.png
+```
+
+Driving the hinge from the terminal is far more repeatable than dragging the slider, using [`hinge`](https://github.com/artemnovichkov/hinge):
+
+```bash
+hinge -d <udid> sweep 180 60 2   # 180 to 60 degrees over 2 seconds
+hinge -d <udid> get
+```
+
+Sweep rather than jumping: an instant change can confuse the simulator's display switching.
+
+Known limitation: taps and key input do not land on the Duo simulator through automation ([XcodeBuildMCP #537](https://github.com/getsentry/XcodeBuildMCP/issues/537)), so scripted UI tests cannot drive it yet. Screenshots work from the terminal with an explicit `--display`; through tooling that cannot pass one, a folded screenshot comes back black because it always targets the inner panel.
+
+## Android foldable emulator
+
+Create a Pixel 9 Pro Fold or 7.6" foldable AVD, then fold it from the extended controls, or:
+
+```bash
+adb emu fold                             # folded
+adb emu unfold                           # unfolded
+adb shell cmd device_state print-states  # this device's state ids
+adb shell cmd device_state state <id>    # force one, ids differ per device
+adb shell cmd device_state state reset   # release the override
+adb emu sensor set hinge-angle0 90       # a specific angle
+```
+
+`adb emu` only talks to an emulator; `cmd device_state` works on real devices too. The state ids are device specific, so print them rather than guessing.
+
+## What to actually check
+
+- Open flat, half open, and closed, so you see **both displays**. These are hands-on checks in DeviceHub, since scripted drivers cannot tap the Duo. A layout only ever seen flat has not been tested.
+- Nothing interactive sits inside the fold band: `var(--fold-width)` wide from `var(--fold-left)`, or `var(--fold-height)` tall from `var(--fold-top)` for a horizontal fold.
+- The app survives being folded shut and opened again, which on iOS suspends and resumes the web view.
+- Text stays readable when the window is short and wide (the inner display held sideways, 951 x 669) and when it is tall and narrow (the outer display upright, 466 x 678). Both panels rotate, so check the other orientation of each.