One design, two phones: what changes and what doesn’t

The question comes up in every design forum: one design for iPhone and Android, or follow each platform’s guidelines? The answer is both, split along one line. Everything about what the app is, design once. Everything about what the phone draws, let the phone decide. Here is where the line runs.

1. Design once: the structure

• Screens and what is on them. A diary, a booking, a client list: the same five screens, the same content, the same order.
• Navigation. Which tap goes where, and whether it is a tab switch, a pushed screen or a sheet. The graph is identical on both phones.
• Layout logic. What comes first on a screen, what groups together, what is primary.
• Words. Labels, empty states, error messages.

This is 90% of the design work and it is platform-free. A person switching from an iPhone to a Pixel should find the same app.

2. Let the phone decide: the materials

• The tab bar. On iOS 26 it is Liquid Glass: translucent, floating, shrinking as you scroll. On Android it is a Material 3 Expressive bar, solid and pill-shaped. Same tabs, different object.
• Typography. San Francisco on iPhone, Roboto (or the device’s font) on Android, each with its own scale.
• Controls. Switches, pickers, date selectors, the keyboard’s accessory bar. Each platform’s own.
• Sheets and dialogs. iOS half-sheets with a grabber; Android bottom sheets with Material shapes.
• Gestures. Swipe from the left edge to go back on iPhone; the system back gesture or button on Android.

Drawing any of these yourself to make them match is the one decision that makes an app feel foreign on both phones at once.

3. Why “identical” is the wrong goal

Users do not compare your app to its other-platform version. They compare it to the other apps on their phone. An iPhone user who sees an Android-style bar, or an Android user who sees an iOS-style switch, feels it instantly, even if they cannot name it. Native on both is the goal. Identical is a goal for the screenshot in your pitch deck, and nowhere else.

There is also an honesty point. The two platforms’ materials are different things, built by different companies, and claiming they look the same is a claim nobody can keep. Say native on both. Do not say parity.

4. What this means for a design tool

A tool that forces one look onto both phones is making the decision in section 2 for you, wrongly. The right tool stores the structure (section 1) once and renders it with each platform’s materials, so the design has one source and two faces. When you preview, switch between them and check the same screen on each: the content should be identical, the chrome should not.

5. Check with captures, not assumptions

Run the same screen on an iPhone simulator with iOS 26 and an Android emulator with Material 3 Expressive, side by side, and look at three things: the tab bar is the platform’s own; the first screen’s content is the same; nothing is drawn in a shape the other phone uses. Keep those pairs of captures as the record of what “native on both” means for your app.

Every starter in the App Builder is captured this way, on both simulators, and the preview switches between iOS and Android for any screen you design. Design the five screens once, then flip the switch and see what the phone changed.