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

‍

It is a sensible question. Reusing good work should be the starting point, not an afterthought.

‍

Apple says an app that already supports resizing on iPad is well positioned for Duo's multitasking. That is a useful head start, but it does not establish that the same arrangement of navigation, content, and controls will be right everywhere.

‍

Reuse the system. Review the layout.

‍

The opportunity is to create one recognizable product across regular iPhone, iPhone Duo, iPad, and iPad mini, without forcing each device into the same composition.

‍

🚀 Extending your app across iPhone Duo and iPad? Let's scope it together →

‍

Similar workflows do not mean identical interfaces

‍

Apple's Duo bar guidance describes controls moving to the side in landscape, with horizontal bars on the inner display in portrait. On iPad, Apple provides tab and sidebar patterns that adapt to the app and available space.

‍

That difference matters before anyone starts resizing a Figma frame:

• Where should navigation sit on iPhone Duo? Consider the appropriate vertical or horizontal system-bar behavior for the current configuration.
• Where should navigation sit on iPad and iPad mini? Consider the tab-bar or sidebar presentation appropriate to the app and available width.
• What changes around the hardware on Duo? Account for the fold and reserved regions when relevant.
• What changes on iPad? Account for the tablet's window and safe areas, without a fold through the display.
• Can either app assume it owns the full display? No. Include multitasking and resizing behavior where supported.
• What should remain consistent? The user's task, vocabulary, destinations, and selected content.

‍

A universal "put everything on the right" rule would be as unhelpful as a universal "copy the iPad sidebar" rule.

‍

What should you reuse?

‍

Start with the product decisions that should not depend on the frame.

‍

Your brand, visual language, names for important destinations, content types, and core user goals should remain recognizable. Components such as conversation rows, attachment cards, buttons, and form fields are good candidates for reuse with appropriate variants.

‍

What deserves another look is the composition: which elements share a view, how much room each needs, how navigation is presented, and what happens when the available space changes.

‍

At Orizon, we treat a design system as more than a collection of styled components. Our approach includes tokens, states, example flows, and documentation tied to the product's priorities. That is the useful foundation for adaptation.

‍

Consistency does not mean putting every element in the same position. It means preserving what those elements mean.

‍

‍

A concrete example: one conversation, three layouts

‍

For our illustrative messaging concept, the main destinations are Home, Projects, Messages, and Account.

‍

Messages is selected everywhere. The "Product launch" conversation is open everywhere. The messages, attachment, and draft belong to the same task.

‍

Only the amount of visible context changes.

‍

Regular iPhone, portrait

‍

Main app navigation stays in bottom tabs, with Messages selected. The person can return to the conversation list when needed. The active task is reading and replying in Product launch.

‍

iPhone Duo, open landscape

‍

The same top-level destinations can adapt into a right-edge rail. A left column reveals the conversation list, with Product launch selected. The main pane continues the same conversation.

‍

The right rail answers "Which part of the app am I in?" The left column answers "Which conversation am I reading?"

‍

iPad mini, sidebar expanded

‍

A left sidebar can contain the same top-level destinations, with Messages selected. Conversation switching can sit below the selected section, while the main pane keeps Product launch open.

‍

This is a proposed layout for this app, not a requirement that every product use these exact columns. The regular iPhone example is also not a representation of Duo's closed outer display.

‍

Adding both a conversation list and top-level app navigation can be useful when they serve different purposes. Duplicating the same navigation in multiple places would not be. Nor would changing a messaging app into a dashboard just because the larger screen has space for a few charts.

‍

🧭 Not sure which journey to start with? Book a scoping call with Orizon →

‍

Decide what disappears before deciding what to add

‍

An expanded design is only half a specification.

‍

Imagine the same messaging view becoming narrower. Should the conversation list collapse? How does someone reopen it? Does the active conversation remain selected? Does an unsent reply remain available?

‍

Define those rules before polishing another wide mockup.

‍

Apple's standard navigation containers support adaptive behavior, including collapsing or revealing columns. Teams should understand what the platform already handles before designing a separate custom arrangement for every configuration.

‍

The design brief can then focus on the decisions the product actually needs: which context is most useful, which actions must stay accessible, and what the person should see when returning to a wider view.

‍

A coherent adaptation should reveal or hide context, not make the user start over.

‍

‍

Extend the design system with behavior

‍

"Make it responsive" leaves too much open to interpretation.

‍

A more useful specification would say: show the conversation list beside the active thread when both remain usable; collapse the list when space becomes constrained; keep a clear route back to it; preserve the current thread and draft throughout.

‍

Apply the same level of detail to important controls and content. Document when labels shorten, how attachments resize, which actions can move into an overflow menu, and how empty or loading states fit each arrangement.

‍

You do not need a different brand or a separate component library for every device. You do need to make the adaptation rules explicit.

‍

Those rules should be reviewed with engineering, especially where the app uses custom navigation or components whose behavior differs from the platform defaults.

‍

Scope one journey before expanding the whole app

‍

We would begin with a representative journey that has both user value and enough complexity to reveal the difficult decisions.

‍

For a messaging product, that might be selecting a conversation, opening an attachment, and replying. For a planning tool, it might be comparing a shortlist with a map. For an AI product, it might be refining a result alongside the conversation that produced it.

‍

Review that journey across the intended devices. Agree on the hierarchy, component variants, navigation behavior, and continuity rules. Then apply the proven approach to related journeys.

‍

This produces a more useful project brief than "redesign the phone version and the tablet version." It also makes clear where you are reusing existing work and where you are asking the team to solve something new.

‍

There is no need to make every screen multi-column. A focused reading, viewing, or capture task may be better served by strong proportions and well-placed controls.

‍

One product, considered for each screen

‍

A strong cross-device experience does not look identical everywhere. It feels related everywhere.

‍

Orizon can help extend your existing app and design system across iPhone Duo, iPad, and iPad mini, with clear decisions about what to reuse, what to adapt, and what to build next.

‍

Key Takeaways

‍

• Reuse your design system as the starting point. It carries brand, components, and product decisions that should not depend on the frame.
• Similar workflows do not mean identical interfaces. iPhone Duo bars and iPad sidebars serve the same intent through different patterns.
• Preserve what elements mean, not where they sit. Destinations, vocabulary, and selected content should stay recognizable across devices.
• Specify what disappears when space contracts, not only what appears when it expands. That is where most cross-device experiences fall apart.
• Extend the system with behavior rules: collapse conditions, label rules, overflow, empty and loading states, and continuity of in-progress work.
• Scope one representative journey first. Solve the hierarchy and continuity questions there, then apply the pattern across the product.
• Not every expanded screen needs a sidebar. Give the space to the task when the extra column adds little.

‍

Ready to plan the adaptation across your product?

‍

‍Book a call with Orizon 🚀

‍

‍

FAQs

‍

Can we keep our existing iPad design system for iPhone Duo?
Usually it should be the starting point for the design review. Keep the components and rules that serve the product well, then add or refine the variants needed for different layouts. Do not replace the system merely because a new device exists.

‍

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, preserve the space for content instead. The messaging layout shown here is an example, not a universal template.

‍

Can one design engagement cover iPhone Duo and iPad mini?
Yes. Define the shared journeys and the device-specific arrangements in one brief. That lets the design team coordinate the system instead of treating each surface as an unrelated project. Engineering implementation and validation should still be scoped explicitly.

‍

Is iPhone Duo closer to iPhone or iPad in how it should be designed?
Both, depending on the pose. The outer display and multitasking states behave like iPhone. The open inner display shares more with iPad in terms of available space, but uses Duo-specific bar patterns and has to account for the fold. Treat it as its own device that borrows from both.

‍

Where do most iPad-to-Duo adaptations go wrong?
Copying the iPad sidebar directly onto the Duo inner display, ignoring the fold and multitasking configurations, and failing to define what happens when the layout contracts. The result feels like an iPad screen shrunk down, which is exactly what iPhone Duo users notice first.

‍

How much of our component library will we need to rebuild?
Usually very little. Tokens, typography, and most components carry over. What tends to need work is navigation containers, list-and-detail patterns, and any component that assumes a fixed width or a single-column layout.

‍

Should we design the iPhone Duo and iPad versions in parallel or one after the other?
In parallel, from a shared journey brief. Designing them separately almost guarantees drift in navigation, terminology, and interaction patterns. A shared brief keeps the product coherent while allowing each surface to use the right platform pattern.

‍

Can Orizon help extend our app across iPhone Duo and iPad?
Yes. Orizon can audit your existing system, define the shared journeys, and adapt the priority flows across iPhone Duo, iPad, and iPad mini with clear handoff to engineering. Book a call to scope your project.