iPhone Duo Isn't a Small iPad. Don't Design It Like One.

“We already have an iPad app. Can we use that design for iPhone Duo?”

Yes, as a starting point. Not as a copy-and-paste layout. Your brand, components and product logic can carry over. Navigation, columns and continuity still need to respond to Duo's displays, folding behavior and available window space.

Key takeaways

• Reuse the system: brand, components and familiar destinations.
• Adapt the composition: navigation, columns and controls.
• Preserve the task: selected content, drafts and progress.

Duo and iPad solve similar problems differently

An iPad layout is a useful head start, particularly when it already supports resizing. But extra screen space does not make the devices interchangeable. Apple describes multitasking on Duo as another reason to design for the app's actual window, not a single full-screen mockup.

Start with a consistent product hierarchy. A conversation list chooses a thread; primary navigation chooses an app section; reply and archive act on the current message. Those jobs should stay recognizable even when the controls change position. Avoid both a universal “put everything on the right” rule and a universal “copy the iPad sidebar” rule.

One product, three different layouts

The references below show why each configuration deserves a considered layout. The two Duo images follow the same email, so you can see exactly what moves. The iPad mini image is a separate platform example, not the same app or a claim that every iPad app needs identical controls.

iPhone Duo, open portrait

On Duo's inner display in portrait, system bars return to a horizontal arrangement. That differs from its closed outer display, where controls can sit along the side. In this Mail example, the selected message takes the main canvas and its actions sit below the content.

Design decision: use the extra room for comfortable reading and typing before adding another column. A detail-first view can work well here, with a clear route back to the list. Don't introduce permanent navigation simply to fill the wider frame.

iPhone Duo, open landscape

Landscape can reveal useful context beside the primary task. The same email now appears beside its inbox, while actions move to the right edge. Apple's bar guidance explains this adaptation; it is not a reason to invent new destinations or mix unrelated actions together.

Design decision: keep the two sides purposeful. In our messaging concept, the left column switches conversations and the right rail selects Home, Projects, Messages or Account. In Apple's Mail reference, the right-side icons are message actions. Similar placement does not make them the same navigation model.

iPad mini: follow the tablet's conventions

On iPad, navigation can use a tab bar or an expanded sidebar, depending on the app and available space. Apple's tab and sidebar guidance is the relevant starting point, not Duo's side-control arrangement. A compact tablet also needs careful decisions about how much secondary content remains useful.

Design decision: expose hierarchy only when it helps. A messaging sidebar might group destinations and conversations; a presentation app might show slide thumbnails. Neither should crowd out the active task. The image above illustrates tablet multitasking, not a current navigation specification for every iPadOS app.

Adapting an existing app for iPhone Duo?
Explore our iPhone Duo App Design service →

Reuse the system, not the composition

Keep the product decisions that should not depend on the frame: brand, vocabulary, content types and core goals. Conversation rows, attachment cards, form fields and buttons are good reuse candidates. Review their states and sizing before promising that every component will transfer unchanged.

The layout needs a separate set of rules. Define when columns appear, how attachments resize, when labels shorten, which actions can enter an overflow menu, and where empty or error states belong. A design system should explain behavior, not just appearance. Our design-system work connects components, states and documentation so those rules can be reused across the product.

Agree these decisions with engineering early. Standard navigation containers may already provide part of the adaptation; custom controls need their own review. The aim is to extend a working system, not create a disconnected library for every device.

Design what disappears, not just what appears

An expanded screen is only half the specification. Imagine someone opening a conversation, writing a reply, then narrowing the app. The list may collapse, but the conversation and unsent text should remain. There should also be an obvious way to switch threads without losing that draft.

Document the transition alongside the screens: what remains visible, where collapsed content goes, and which selection or focus is preserved. Then test it with the keyboard open, longer labels and larger text. Revealing less context should not mean restarting the task.

Apple's adaptive-container guidance helps developers understand the native behavior. Design still needs to specify the product's expected result, especially when custom navigation or unsaved work is involved.

Start with one important journey

For a messaging app, start with selecting a conversation, opening an attachment and replying. Design that journey across the intended layouts, agree the component variants and continuity rules, then extend the approach to related screens.

This creates a concrete scope: shared components to reuse, layout decisions to solve, and behavior for engineering to verify. It also leaves room for focused experiences that do not need extra columns. Reading, viewing and capture screens may benefit more from good proportions than from a permanent sidebar.

Still deciding how much work your app needs? Start with our seven-point iPhone Duo readiness checklist.

One product, considered for each screen

Orizon can review your existing app and adapt its priority journeys across iPhone Duo, iPad and iPad mini. You get a clear direction for what to reuse, what to redesign and what your developers need to implement.

Let's talk about your app →

Frequently asked questions

Can we keep our existing iPad design system?

Use it as the starting point. Preserve components that serve the product well, then review navigation containers, fixed-width assumptions and adaptive states. The amount of new work depends on the current system, not just the new device.

Does every expanded screen need a sidebar?

No. A sidebar should expose useful hierarchy or make frequent switching easier. When it adds little to the task, give the space back to the content. A larger display is an opportunity, not a requirement for more navigation.

Is Duo's closed display the same as a regular iPhone?

Do not assume so. Apple's Duo guidance includes side-positioned controls on the outer display. A regular iPhone mockup with bottom tabs is not an accurate substitute for reviewing that configuration.

Should we design Duo and iPad together?

Use a shared journey brief, even when delivery is phased. That keeps vocabulary, destinations and behavior aligned while allowing each layout to follow the appropriate platform conventions.

Can Orizon cover both design and developer handoff?

Yes. The engagement can include a prioritized review, high-fidelity flows, updated components and behavior specifications across the agreed devices. Implementation and validation should be scoped with your engineering team rather than assumed to be included in the mockups.