Games on iPhone Duo

SkillDev tools

Adapt a game to iPhone Duo — filling the screen across every device pose, orientation locking, aspect ratio versus letterboxing, keeping touch controls out of the fold, and consistent text and control sizing while resizing. Use when the project is a game or uses a game engine such as Unity, Unreal, Godot, SpriteKit or Metal.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Games on iPhone Duo skill

What this skill tells your AI

The instructions your AI receives, as published by mirzaaghazadeh/iphone-duo-skills in skills/iphone-duo-games/SKILL.md and read by ahel’s review.

Games get a carve-out from most of this device's UI guidance — no toolbars to send vertical, no split views to adapt. What they don't get a carve-out from is resizing. The screen changes size and shape underneath a running game every time someone opens, closes, folds or rotates the device, and a game that assumed a fixed viewport will letterbox, stretch, or drop controls off the edge.

You may lock orientation. You may not stop filling the screen.

Locking to portrait or landscape is fine and supported. What is not fine is treating that lock as permission to assume a fixed size.

Two reasons it doesn't hold here:

  1. The device has two displays with different dimensions, and your game moves between them mid-session.
  2. The inner display doesn't honor supported interface orientations. An orientation lock that has held on every previous iPhone stops holding on the inner display.

UIRequiresFullScreen behaves the same way — still honored, but your game still resizes when the device opens and closes. Plan for the resize regardless.

So: pick your orientation, then make sure the game fills the screen in every pose. That is the actual requirement.

Aspect ratio beats letterboxing

When the viewport shape changes, you have three options, in order of preference:

1. Change the aspect ratio. Show more or less of the world. This is the preferred answer: extend the camera frustum, widen the visible field, let the scene breathe into the space it has been given. The game stays full-bleed and feels native to whatever pose it's in.

2. Letterbox or pillarbox with artwork. If the design genuinely can't take a variable aspect ratio — a fixed puzzle grid, a precisely tuned platformer camera — then bars are acceptable, but fill them. Extend the background, continue the scene's artwork, or run themed framing into the padding. The goal is that it reads as a deliberate frame rather than a game that failed to fit.

3. Bare black bars. Avoid. This is what "didn't adapt" looks like.

Keep text and controls the same size

When the viewport resizes, resist the urge to scale the whole scene uniformly. Uniform scaling shrinks your HUD text and touch targets along with the world — so opening the device to the larger display can make text harder to read and buttons harder to hit, which is exactly backwards.

Scale the world; keep UI in its own layer sized in points. Text and controls should stay as close to a constant physical size as you can manage across every pose. On-screen touch controls in particular must not shrink below a comfortable target just because the aspect ratio changed.

The fold is a real problem for touch controls

This is the iPhone Duo-specific issue most likely to hurt a game.

When the device is partially folded, the inner display curves through the middle, and that region is genuinely harder to see and to tap. A virtual joystick, a fire button, or a drag target that lands in the curve becomes unreliable — not invisible, just worse, which is harder to diagnose from a bug report.

Games rarely use the system components that get fold avoidance for free, so this one is on you:

  • Query reserved regions and keep interactive controls out of the division region (the fold). See ../iphone-duo-adaptive-layout/SKILL.md for the API and the displacement patterns.
  • Anchor touch controls to the outer edges rather than centering them. Edge anchoring is more robust across every pose and costs nothing when flat.
  • Watch the occlusion regions too: the outer front camera is always present, and the inner camera appears whenever it activates.

Purely visual, non-interactive content can cross the fold. It's touch targets and critical readouts that need to move.

Poses worth designing for

You don't need a bespoke layout per pose, but two are worth a thought:

Tabletop / laptop. The device stands on a surface, half the display facing up and half facing the player. This is a genuinely new play position — the lower region is a stable touch surface and the upper region is a viewing surface. A game with a board-and-controls split maps onto it naturally.

Tent. Standing on its edges, hands-free. Good for idle, spectator, ambient or turn-based games.

Treat both as bonuses. Don't tie any functionality to a pose someone might never use.

Split View

Games participate in Split View multitasking like everything else — your game can end up in half the inner display. It will be smaller and a different shape than anything you designed for. Make sure it still renders correctly and doesn't drop controls off the edge; you are not obliged to make it a great play experience at that size, but it must not break.

The hinge as an input

The hinge angle is available as a live, continuous value — coarse status plus an angle — via onHingeChange in SwiftUI or UIHingeInteraction in UIKit. For a game engine, bridge it the way you'd bridge any other native sensor.

It is a genuine novelty input, and worth considering for effects, camera parallax, or a mechanic. Two cautions: guard for a nil hinge, since the same binary runs on every non-folding iPhone, and never make it the only way to perform an action. Details in ../iphone-duo-hinge-and-scenes/SKILL.md.

Engine notes

Most engines expose the viewport as a resize event and a safe-area inset query. Wire both, and treat resize as a first-class event rather than a startup value:

  • UnityScreen.safeArea, and handle resolution changes at runtime rather than reading once in Start().
  • Unreal — safe zone / title safe values, and re-evaluate on viewport resize.
  • Godot — the safe area API plus a stretch mode that tolerates changing aspect ratios.
  • SpriteKit / Metal — you already get the resize through the view; the work is making the scene respond rather than assuming the initial drawable size.

Reserved regions and the hinge angle are iOS 27.1 APIs with no engine-level equivalent, so those need a native plugin. The bridging pattern is the same one described in ../iphone-duo-flutter/SKILL.md and ../iphone-duo-react-native/SKILL.md.

Checklist

  1. Handle viewport resize as a live event — not a value read at launch.
  2. Fill the screen in every pose, whatever your orientation lock.
  3. Prefer changing aspect ratio; if you letterbox, fill the bars with artwork.
  4. Keep HUD text and touch targets at a consistent physical size across poses.
  5. Anchor interactive controls to edges, and keep them out of the fold.
  6. Verify the game still renders correctly in Split View.
  7. Test every pose in the iPhone Duo simulator in Device Hub — open, closed, folded, rotated.

Signals

GitHub stars
20
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
iphone-duo-games
Source
github.com/mirzaaghazadeh/iphone-duo-skills