Your App Might Work on iPhone Duo. That Doesn't Mean It's Ready.

Your app opens. The buttons respond. Nothing obviously breaks. That is a good start, not proof of a good iPhone Duo experience. Apple says existing apps can run without recompiling, while newer SDKs improve screen usage and standard controls. Your implementation still needs testing. See Apple's preparation guidance.

The useful question is whether the app becomes more capable as the available space changes. Before committing to a full redesign, review navigation, key journeys and the work people already have in progress.

Key takeaways

• Running is not the same as ready. Review the experience, not just compatibility.
• Adapt to available space. Don't design an unrelated interface for every pose.
• Keep the task intact. Navigation, selections and drafts must stay coherent.
• Prioritize useful changes. Not every screen needs a redesign.

Does your app need a full redesign?

Not necessarily. Some products need targeted navigation changes; others can make an important journey easier with a list-and-detail layout. Review shared components first, then the flows that depend on them. Preserve screens that already work well instead of treating a new device as a reason to rebuild everything.

1. Look beyond a closed/open pair

A compact mockup and an expanded mockup are not the whole experience. Duo supports side-by-side multitasking, so your app may occupy only part of the display. The six configurations above illustrate changing relationships between a message, its inbox and its controls, not six separate products to design.

Define what collapses as space tightens. In a messaging app, the conversation should remain usable when the list disappears, with a clear way to switch threads. Apple's design guidance recommends responding to available space and size classes rather than inventing a bespoke interface for each pose.

Review question: when space becomes tighter, what collapses first, and can the person still finish the task?

2. Move the controls, not the meaning

Apple's Duo bar guidance describes side-positioned controls on the outer display and open landscape layout, with horizontal bars on the inner display in portrait. Treat their placement as adaptive, but keep their purpose recognizable.

Main app navigation chooses a destination. A conversation list chooses a thread. Reply, archive and compose perform actions. Moving these controls should not mix up those jobs. Keep familiar labels and destinations, group related actions, and agree which controls can move into overflow when space is limited.

Review question: can someone understand what each navigation area does without learning a different app?

3. Make the extra space earn its place

Consider an AI workspace where the conversation and its generated document live on separate screens. An expanded view could show them together, allowing someone to request a change while seeing the result. That is a product improvement worth prototyping, not just a wider version of the same chat.

Start with the information people need simultaneously. Test whether bringing it together reduces back-and-forth without overwhelming the primary task. More cards and extra columns are not automatically better; a focused reading or capture flow may only need improved proportions.

Review question: what becomes easier in the expanded view, beyond seeing a larger screen?

4. Treat the fold as a layout condition

Apple's fold guidance distinguishes controls and grouped content from continuously scrolling articles or feeds. Some elements need to move away from a partially folded region. That does not mean every screen needs a permanent blank stripe through its center.

Review relationships, not just coordinates. A confirmation button and its explanation should still feel connected; a dialog should not land awkwardly across the fold. Check each safe-area edge independently and verify that an image crop still preserves its subject.

Review question: when elements move, do their relationships still make sense?

Not sure which journeys need attention?
Explore our iPhone Duo App Design service →

5. Protect work already in progress

Someone opens a conversation, writes half a reply, expands the view, then narrows it again. The acceptance criteria should be clear: the same conversation stays selected, the draft survives, and the person can continue without retracing their steps.

Document that alongside the layouts. Include the route back to any collapsed content and what happens to keyboard focus. A screenshot cannot prove continuity: design specifies the expected behavior, and engineering verifies it in the running app.

Review question: what must remain unchanged while the interface rearranges itself?

6. Review the less photogenic states

Open the keyboard. Increase text size. Use a long title. Show an empty list, a loading state and an error that requires action. Check screen-reader order and whether focus still reaches the intended controls.

In a messaging app, inspect the composer, latest message and conversation context together. These checks belong in the design brief, not in a last-minute instruction to “make it responsive.”

Review question: does the hierarchy still work when the content is inconvenient?

7. Turn the review into a prioritized scope

A useful audit leaves the team with decisions, not just a longer list of screens:

• Fix: a task or control becomes unusable.
• Explore: the expanded layout could improve an important journey.
• Keep: the existing screen already works well.

Estimate the agreed journeys, shared components, transitions and validation work together. A screen count alone misses the behavior between layouts and can turn a focused update into an unnecessary overhaul.

What a useful design handoff includes

The developer should understand when a column appears, where its content goes when it collapses, and which state survives. A useful package brings together a prioritized review, representative flows, updated components and behavior rules, with native and custom implementation responsibilities clearly distinguished.

Our mobile app design work connects product flows with reusable UI systems and developer-facing documentation. A Figma prototype establishes the intended experience; it does not replace implementation testing. Already have an iPad app? See what you can reuse for iPhone Duo.

Make the next screen size a product improvement

Orizon can help identify your adaptation scope, redesign the priority journeys and give engineering a clear direction across iPhone Duo, iPad and iPad mini. Start with the work that makes the product more useful, not a promise to redraw every screen.

Let's talk about your app →

Frequently asked questions

Should every screen be redesigned for iPhone Duo?

No. Review shared navigation and components first, then the journeys that rely on them. Change screens where there is a concrete usability issue or a worthwhile improvement. The review should also identify what can stay as it is.

What should we audit first?

Start with critical journeys, custom navigation, dialogs and fixed-size layout assumptions. Check narrowed windows, keyboard visibility and unsaved work. Ask engineering which behaviors the app's native containers already handle before estimating custom design or implementation.

How much of our existing design system carries over?

Brand, tokens and well-built components are useful starting points. Review navigation containers, list-and-detail patterns and fixed-width components individually. The reuse potential depends on the current system; it should not be promised as a percentage before the audit.

How long does an adaptation take, and what should we send?

Timing depends on the journeys, custom UI and validation required. Share the app, existing Figma files or design system, framework, priority flows and release goals. A focused review makes it possible to separate a targeted update from a broader redesign.

Can Orizon work alongside our developers?

Yes. We can review the experience, design the agreed flows, document adaptive behavior and support implementation reviews. Your engineering team remains involved in feasibility and testing, so the handoff covers how the product should behave as well as how it should look.