Designing for iPhone Duo: Adaptive Layouts, Fold-Aware Interactions, and Creative Apps

A practical guide to adaptive layouts, fold-aware interactions, and creative apps

A bigger display is easy to fill. A changing display is harder to design for. Someone might open a document on the outer screen, unfold the device to compare two passages, bring up the keyboard, and then close it again while walking. The useful question is what should remain stable through that sequence, and what should change.

For an existing app, I would approach iPhone Duo in two passes. First, make today's experience reliable at changing sizes. Then add one interaction that makes a real task easier. A reading app, a drawing tool, and a music player have different relationships between their content and controls. Giving all three the same split screen would miss that distinction.

This guide combines Apple documentation, developer-published product descriptions, creator videos, and design analysis. Platform facts link to their sources. Recommended workflows and concept diagrams describe approaches to evaluate in your own app. The diagrams are schematic illustrations, not device screenshots, hardware specifications, or evidence of an implemented feature. No firsthand device-testing claim is made here.

Author affiliation: I work on DuoKits, where I collect app and interaction references. The sources below link directly to Apple and the original developers.

1. Start with a three-stage adaptation plan

Apple's preparation checklist distinguishes SDK behavior: older builds use a compatibility presentation; the iOS 27 SDK uses more of the inner display; iOS 27.1 enables edge-to-edge presentation and vertically arranged system controls. Rebuilding with a newer SDK changes the available presentation, but it does not prove that every custom view is ready. Apple preparation checklist

For a small team, a three-stage plan keeps this manageable:

Stage one: preserve the existing task. Choose the three flows people use most. For a reader, that might be opening a book, returning to a position, and searching within it. For an editor, it could be importing, making a change, and exporting. Record a baseline before redesigning anything. You need to know whether the new layout makes a working task less reliable.

Stage two: improve the use of space. Find places where additional context could save a navigation step. A persistent outline might help a writer; an always-visible layer panel might help an illustrator. Add only the context that helps the current task. An expanded screen does not need to display the entire product at once.

Stage three: add a fold-aware interaction. Pick one hypothesis, such as keeping playback controls separate from video. Define what success would look like before implementing it. Fewer accidental taps, less hand occlusion, or an easier comparison are testable outcomes. “Feels futuristic” is too vague to guide a release decision.

Each stage should have a stopping point. Ship a dependable adaptation before committing to a collection of experimental modes. This also gives a small team a useful rollback boundary: a creative feature can remain optional without undoing basic resizing improvements.

2. Design from the available space

Apple recommends local geometry and size classes rather than assumptions based on device idiom, interface orientation, or a permanently cached screen size. Standard navigation containers such as NavigationSplitView and UISplitViewController already adapt between constrained and spacious presentations. Safe-area insets can be asymmetric, so each edge needs its own treatment. Apple's preparation talk

A useful audit begins with your existing code and screenshots. Search for layout decisions that answer “what device is this?” when they should answer “what space does this component have?” Then examine each instance in context. A fixed width is not automatically a bug: a readable text column may intentionally have a maximum width. The risk is treating one fixed width as a complete screen strategy.

Consider an article reader with an outline. In a compact presentation, the article owns the screen and the outline is a separate navigation destination. In an expanded presentation, the outline sits beside the article. The content column should still have a comfortable reading measure; stretching every line across all available width would waste the improvement.

Try three variations before choosing a layout:

• Content first: maintain the article width and use surrounding space for margin.
• Context added: introduce a secondary outline, inspector, or reference panel.
• Comparison enabled: allow two related items to remain visible together.

Select the variation by task, not by which screenshot looks fullest. A comparison panel is useful while comparing; it may be distracting while reading continuously.

Also test the reverse journey. Remove space gradually and decide which element yields first. Perhaps the inspector becomes a sheet, the outline becomes navigation, and the primary document remains. Write down that priority order. It prevents a layout from becoming a collection of unrelated breakpoint fixes.

3. Keep the work separate from its presentation

The most damaging adaptation bug may be invisible in a screenshot: the interface changes shape and loses the user's work. A draft resets. The selected layer changes. Playback restarts. An upload is accidentally launched twice because a view appeared again.

A practical architecture review should separate three categories of state:

Task state is the work itself: document contents, selected media, an editing operation, or a queued export. Navigation state describes where the person is: selected item, opened detail, or active route. Presentation state concerns the current interface: which panel is expanded, whether a temporary sheet is visible, or how controls are arranged.

These categories are an architectural recommendation, not a new Duo API. The goal is to avoid making the survival of a document depend on the survival of one particular panel.

For a photo editor, imagine this sequence: open an image, choose a crop, unfold, adjust the crop, and close the device. The image identifier and pending crop should remain associated with the editing session. The toolbar may move or collapse. A temporary help popover may reasonably disappear. Those decisions should be intentional rather than accidental consequences of rebuilding views.

Create a short “continuity contract” for each important flow. List what must survive, what may change, and what must never happen twice. For example:

• Preserve the selected document and unsaved text.
• Preserve playback position and playback intent.
• Permit an inspector to collapse when space becomes scarce.
• Do not create a second upload or save operation during a layout transition.

Use identifiable sample data when testing. “Paragraph 18, second sentence” is easier to verify than “somewhere in the article.” A visible pending-edit marker can make an otherwise subtle state loss obvious during a review.

4. Make the fold useful without making the interface restless

Apple's adaptive-layout talk introduces reserved regions and arrangement views. It distinguishes division and occlusion regions, and describes split and overlay arrangements for different content relationships. It also cautions that arrangements do not replace navigation infrastructure and are unsuitable in some scrolling-container compositions. Use the actual API documentation and availability requirements when implementing these tools. Adaptive layouts talk

The design decision comes before the API choice. Ask which elements need to stay together and which elements benefit from separation. A transport control belongs to the media it controls. A reference panel relates to the current document. A destructive action should not suddenly appear where a harmless action was a moment earlier.

Start with a paper sketch containing only three labels: primary content, supporting content, and frequent action. Rearrange them into two regions. If you cannot explain why the new arrangement is easier to use, keep the ordinary adaptive layout.

For a video player, a candidate layout puts the picture in one region and a compact control group in another. For a reading experience, the candidate might preserve a page-like relationship between two pieces of text. For an editor, it might leave the working surface clear while making a few frequent tools easier to reach. These are different experiments, even when their sketches all contain two rectangles.

Avoid reacting visibly to every small movement. A person adjusting how they hold the device is not necessarily asking the app to switch tasks. Review whether your transitions preserve orientation: can they still find the selected item, the main action, and the way back?

Test touch behavior as well as composition. A beautiful arrangement can still fail if two frequent controls are crowded together or if a moving control lands under a finger. Record the moment of transition, not just its final frame. Ask a reviewer to continue a task while the layout changes, rather than posing the device and admiring the result.

5. Treat navigation and controls as different problems

A sidebar answers “where can I go?” A transport panel answers “what can I do to the current item?” Combining both into one large secondary panel can turn extra space into visual noise.

Try a simple inventory. Mark each interface element as navigation, content, action, or feedback. If a region contains all four at equal weight, decide what deserves priority. The answer may change by task, but the hierarchy should remain understandable.

In a media library, browsing can benefit from an expanded list-and-detail layout. During playback, the same space might be better used for subtitles, queue context, or transport controls. Do not preserve a panel merely because it existed on the previous screen. Preserve the user's intent instead.

For custom bars, evaluate long labels, localization, larger text, and disabled states. A layout that works with three short English labels may collapse when one action becomes a longer phrase. Prefer reducing simultaneous controls over shrinking them until they become difficult to use.

Make the destination of overflow predictable. If an action disappears from a toolbar, it should move to a clear menu or another consistent location. It should not become available only in a particular pose. Essential operations need a usable path on the outer display and in constrained windows too.

An effective review question is: “Could a person finish this task without knowing that a special layout exists?” If the answer is yes, the enhanced layout can remain a benefit rather than a dependency. That makes the app easier to learn and keeps the adaptation valuable for users who rarely unfold their device.

6. Know where the platform boundaries are

Apple separates hinge-driven effects from layout decisions: hinge information can drive interactions, while arrangement and region APIs are intended for layout. Its multidisplay talk also describes system-controlled scene accessories. The camera capture accessory can supplement an inner-display camera interface with outer-display content under specific conditions, including an active camera session and full-screen presentation. Availability can change. This does not establish unrestricted two-display canvases for every application. Multiple displays and scenes

That boundary should appear in the product brief before a designer spends days on an unsupported concept. Write a short capability note beside each idea: documented, needs a prototype, or unsupported assumption. A camera rehearsal tool and a general two-sided dashboard may look similar in a mockup while having very different implementation requirements.

Plan a fallback at the same time as the enhanced mode. If a supplementary display becomes unavailable, what information remains essential? Where does it go? Does the primary workflow continue, pause, or ask for a deliberate choice? A camera app should not leave a recording interface in an ambiguous state because supporting content disappeared.

Treat transitions as normal conditions rather than exceptional failures. A user closing the device, switching windows, or leaving the relevant screen is part of ordinary use. Avoid promising that an accessory will always be present. A control for an unavailable feature should communicate its state clearly, and the rest of the app should remain useful.

This is also a good place to control scope. A single well-defined enhancement with a clear fallback is easier to maintain than a feature whose requirements quietly include every possible display combination.

7. Learn from real products, not just two-rectangle mockups

The following examples make the design choices more concrete. Their product descriptions come directly from the developers' App Store listings. They are not firsthand device tests. The recommendations after each description are my design analysis, not claims about the apps' internal implementation.

Chiptune: separate the pattern from the controls

Chiptune's App Store release notes describe an inner-display landscape layout with a pattern grid on one side and sound controls and note keys on the other. This is a more useful reference than a generic “desktop-style” music interface: the two regions have distinct jobs within the same activity.

Borrow the relationship, not the appearance. A creator needs to see what they are composing while adjusting how it sounds. An equivalent arrangement in a photo editor might pair the image with adjustments; a presentation editor might pair a slide with its properties. The benefit comes from keeping the result visible during manipulation.

For your own prototype, identify the few controls used repeatedly in that loop. Preserve the selected pattern, playback position, and pending edits when the arrangement changes. Then compare it with your compact interface. Are controls easier to reach? Is the work less obscured? If the second region mostly contains rarely used settings, the split is probably solving the wrong problem.

Hingami: make the physical action meaningful, with an alternative

Hingami's developer description explains its paper-folding puzzle mechanic and conventional-iPhone drag alternative. The crease is part of the activity rather than a decorative divider. The fallback matters just as much as the novel input.

The transferable idea is to define an action in your task model independently of how it is triggered. “Change the paper fold” can have a physical input and an on-screen input. That separation makes the experiment easier to test and gives people a choice when a physical gesture is inconvenient.

For an educational tool, the equivalent could be opening a diagram in stages. For a creative toy, it could be changing a shape. Do not assume continuous movement is always comfortable or precise. Prototype the ordinary control first, then ask whether the physical interaction adds understanding or pleasure beyond novelty.

Halves: design around who can see what

Halves' developer description outlines shared-device activities, including a private word paired with a public drawing and a private key paired with a shared grid. The important distinction is not primary versus secondary content. It is private versus shared information.

That creates a different test plan. A layout can be visually correct and still spoil the game by exposing an answer during a transition. For your own shared-device prototype, draw an information-access map before drawing the interface: what should each participant know, when should it become visible, and what happens if the device is moved?

Do not treat screen arrangement as a security boundary. Viewing angles and physical handling require observation on the relevant hardware. Build a deliberate reveal or handoff interaction where secrecy is essential, and avoid promises that a mockup cannot establish.

Three creative directions from creator prototypes

Accorduon, by Artem Novichkov, uses the accordion metaphor: the hinge becomes the bellows. Treat this as a concept demonstration, not a claim of a released product. The useful question is whether the physical action has an understandable relationship to the output. A successful metaphor can teach an interaction with very little explanation. It still needs an ordinary alternative and careful treatment of responsiveness. Original creator post

Pinball, by Julian Schiavo, explores using the hinge as a paddle. It is also a concept, not evidence of hardware durability or a recommendation for repeated forceful movement. As an interaction study, it prompts a useful comparison: when does a physical input make a game more expressive, and when does a button give the player better control? Original creator post

TranslateCat, by Vasanth, explores a conversation with content facing the other participant. The design problem is two audiences with different reading needs. Keep that product question separate from API feasibility: a creator's concept does not establish that arbitrary simultaneous inner and outer display content is available to every app. Check the platform boundaries in section 6 before committing to this architecture. Creator video

8. Watch the interaction, then write a testable question

Static illustrations explain the structure. Video is useful for seeing timing, transitions, and the relationship between movement and response. The following links point to original creator videos. Their demonstrations are references for analysis, not independent verification of real-device performance or comprehensive support.

Watch Accorduon on the creator’s original post. The captured simulator view is useful for discussing continuous input; it does not establish a shipped app or validated hardware behavior.

Watch Pinball on the creator’s original post. Use the prototype to discuss board/control separation, then test reachability and accidental input in your own implementation.

Video references: the links below open each original creator video. These are source-linked viewing references, not locally rehosted videos; availability and playback have not been verified in this document.

Video	Reference type	What to look for
Accorduon · Artem Novichkov	Concept	Whether the bellows metaphor communicates input and feedback clearly.
Pinball · Julian Schiavo	Concept	How a physical paddle idea changes precision and effort compared with touch.
TranslateCat · Vasanth	Concept	How information is assigned to two participants, then which capabilities require validation.
HanziAgain · Doran Gao	Store-linked demo	The reference highlights a side rail and a roomier writing page. Consider what should stay fixed while the page gains space.
Countdown2Binge · Craig Clayton	Store-linked demo	The reference highlights a settings card moving away from the crease. Consider readable placement and continuity during that move.

A store-linked demo is not automatically a currently verified support claim. A concept may communicate a worthwhile idea without being a released product. Preserve those labels when sharing references with your team.

After watching, write one question you can investigate in your own prototype. “Can a person keep writing while controls move out of the way?” is actionable. “Make it like that video” is not. Capture a transition sequence and compare it with the starting layout, rather than judging only the most impressive frame.

9. Keep the evidence attached to the example

Trovu's App Store history describes a useful media-player reference: book pose distributes content across two page-like regions, laptop pose places controls lower, and the outer screen retains an iPhone-style presentation. A later update mentions larger controls and more spacing near the scrubber. These are developer-published descriptions, not independent certification. Trovu version history

The value of a reference is the question it helps you ask. In this case: should a player's controls move away from its picture, and which controls need more space? Copying the visible arrangement without understanding its task would be less useful.

Build a small reference board with three fields for each example: claimed behavior, evidence source, and relevance to your own workflow. Add an observation only after you have actually made it. Keep store descriptions, simulator results, and physical-device checks visibly separate.

This habit is useful when discussing support publicly. “The developer describes a laptop-pose layout” is precise. “Perfectly optimized” asks readers to trust a much broader conclusion. Your own release notes can be equally concrete: name the changed flow and what was checked, rather than making a sweeping quality claim.

10. Test the journey between layouts

A screenshot confirms one arrangement at one moment. A transition test checks whether someone can continue working. Both are useful, but they answer different questions.

For each important workflow, choose a recognizable starting state. Enter distinctive text, select a particular image, or pause at an identifiable playback position. Change the presentation, perform one more action, and return. Verify the task state, navigation, control placement, and feedback after each step.

A compact test matrix can cover six journeys:

• Editing: keep unsaved input, selection, and a clear save state.
• Reading: preserve a meaningful position and make the new context understandable.
• Playback: retain progress and avoid accidental restart or duplicated controls.
• Navigation: keep the selected item and a clear path back.
• Presentation: inspect sheets, menus, alerts, and keyboard interactions.
• Accessibility: repeat key flows with larger text and alternative interaction needs.

Run the same journeys with less space available. An app can look excellent fully expanded and still fail when a second task takes part of the display. Keep three arrangements distinct: two panes inside one app, two apps sharing space, and multiple windows. They are not interchangeable support claims. Apple's multiple displays and scenes talk. Include long titles, empty states, errors, and slow-loading content. These states are often where polished mockups stop resembling the real product.

Apple documents the Duo simulator and Device Hub pose controls as tools for repeatable layout checks. Use them to reproduce transitions, while keeping simulator findings distinct from physical-device validation. Apple preparation talk

For each failure, save the exact starting state and sequence. “Toolbar broken” is difficult to reproduce. “Open item B, show the keyboard, change to the constrained layout, then open its menu” gives the next developer a useful path to investigate.

11. Ship a small, explainable improvement

A first adaptation does not need every creative idea in this article. Choose the improvements you can explain and verify: reliable resizing, preserved task state, usable controls, and perhaps one fold-aware arrangement. Keep a record of what remains experimental.

Before release, review the product copy alongside the actual behavior. If an example is a concept, label it. If a support claim comes from a developer's statement, identify that source. If a screen was checked only in a simulator, do not rewrite the result as device testing. These distinctions make later feedback easier to interpret.

Start with one important task. Make it survive changes in space. Add context where it saves effort, and add a fold-aware behavior only when its benefit is clear. That produces an adaptation worth using, not merely a screenshot worth sharing.

Editorial note: Fully Autonomous AI disclosure: This article was generated by AI using the linked sources and reviewed by the account owner before publication. Sources were checked October 31, 2026. All six illustrations are explanatory concepts. This article does not claim firsthand development or physical-device test results.