Mobile App Design That Follows Platform Convention

Should iOS and Android look identical?

They should share brand and structure, not component behavior. Forcing pixel-identical apps across both platforms means at least one of them fights conventions its users already know.

The differences that matter are concrete: navigation patterns and where back lives, system components like pickers and sheets, typography defaults, and how gestures behave. Users are not consciously aware of these until something violates them, at which point the app feels subtly broken.

The practical answer is one design language, two implementations of the platform layer. Your brand stays consistent; navigation and system interactions follow each platform.

Why does our app feel like a website in an app?

Usually because it is one — either literally a wrapped web view, or a design produced by scaling web layouts to phone width without rethinking interaction.

The tells are recognizable. Navigation that lives in a top bar rather than where the platform puts it. No gesture support, so back only works via an on-screen button. Hover-dependent affordances that do nothing on touch. Scroll behavior that does not match the OS. Long forms designed for a keyboard and mouse.

Fixing it is not a styling pass. It means revisiting the navigation model, the interaction patterns and often the task structure — which is why we start there rather than at the visual layer.

How do you design for offline and poor connection?

By treating them as normal states rather than errors. Mobile apps run on trains, in basements and on congested networks, and an app that only works on good wifi will be judged on the times it did not.

What that means in design: showing cached content with a clear indication it may be stale, queueing actions taken offline and confirming when they sync, distinguishing "loading" from "failed" clearly, and never losing input a user has typed because a request failed.

The last one causes the most damage. An app that discards a half-completed form when the connection drops teaches users not to trust it with anything long — and that lesson is very hard to un-teach.

How much does app design depend on the developers?

More than web design does, because platform behavior is easy to specify and easy to lose. Gestures, transitions, safe area handling and system component usage all get approximated if the handoff does not state them.

Native, React Native and Flutter each change what is straightforward to implement, so the build approach is worth knowing before design is finalized. A transition that is trivial in one is awkward in another.

This is why our handoff is written for mobile developers specifically — per-platform component differences, gesture behavior, transition specs and safe area treatment. A design that assumes the developer will infer these produces an app that is close to the design and does not feel like it.

How closely should you follow platform conventions?

Closely for navigation and system behavior, freely for everything that is distinctly yours.

The reason is not purity. It is that people have learned their phone, and every departure from what they expect costs them a moment of confusion. A back gesture that does not work, a control that looks like a system one and behaves differently — those are small individually and corrosive together.

Both platforms publish detailed guidance, and both app stores apply some of it during review. Ignoring it risks rejection as well as confusion, which turns a design preference into a schedule risk.

Where brand belongs is in typography, color, imagery, tone and the parts of the experience that are actually yours. That is more than enough room to be distinctive without redesigning the parts of the phone people already know.

Should iOS and Android look identical?

They should feel like the same product and behave like native apps on each platform. Identical is a goal that serves the design team rather than either set of users.

The differences that matter are structural — where navigation sits, how back works, what a share action looks like, how dates and pickers behave. Forcing one platform's pattern onto the other produces an app that feels subtly wrong to half its users without anyone being able to name why.

What should be identical is everything that carries your brand and your content. Colors, type, imagery, tone, information architecture and the sequence of a task should not vary by platform.

The practical approach is one design system with platform-specific components. Shared tokens, shared content, shared flows; navigation and system controls native to each. It costs more than designing once and considerably less than designing twice.

How do you design for poor connections?

By treating a bad connection as a normal state rather than an error, because for many users in many places it is the usual condition.

The first decision is what works offline. Content already fetched should remain readable. Actions taken offline should queue and sync rather than failing, and the interface should say clearly that this has happened rather than pretending everything is fine.

Loading states need to distinguish between slow and broken. A spinner that runs forever tells a user nothing; a message that says it is taking longer than usual, with a way to retry, respects them. And placeholders that reserve the right space prevent the layout jumping when content finally arrives.

The hardest case is a partial failure — some data loaded, some not. Designing for it means deciding, per screen, what is essential and what can be absent, so the screen degrades usefully instead of showing an error over content that was perfectly fine.

What does onboarding need to do?

Get someone to the first useful moment as quickly as possible, and nothing else.

Most onboarding is designed backwards — a tour of features before anyone has a reason to care, or an account demanded before any value has been shown. Both ask for commitment in exchange for a promise, at the point where the person has the least trust they will ever have.

The better pattern is to let people do something real first. Delay the account until it is genuinely needed — to save something, to sync something — at which point it is obviously worth it rather than an obstacle.

Permissions follow the same logic. A location request on first launch, before context exists, gets declined and is then difficult to recover. Asked at the moment it is obviously needed, it gets granted. The timing is a design decision with a direct, measurable consequence.

How much does design depend on the developers?

Enough that designing without them produces work that gets quietly reinterpreted during the build.

Every platform has things that are cheap and things that are expensive. A custom transition that looks trivial in a prototype may be days of work; a standard component with a slightly different appearance may be minutes. A designer who does not know which is which spends the budget in the wrong places.

The other dependency is state. Applications have far more states than websites — loading, empty, error, offline, permission denied, partially synced. Developers know which ones will occur in practice, and the ones nobody designs get built as whatever was quickest.

The arrangement that works is designers and developers reviewing together early and often, with the design system implemented as real components rather than delivered as a document. It removes the interpretation step, which is where most of the drift happens.

What do the app stores require of the design?

More than most projects plan for, and the requirements are published rather than mysterious.

Both stores review submissions against guidelines that include interface expectations, and rejections for design reasons are routine rather than exceptional. Reading the relevant guidance before designing is considerably cheaper than after a rejection.

The store listing itself is a design deliverable that is frequently forgotten — icon, screenshots and preview video are what decide whether anyone installs, and they are produced at the end under time pressure more often than not.

The icon carries the most weight and has the tightest constraints. It appears at small sizes among many others, it cannot rely on text, and it needs to be recognizable at a glance on a crowded home screen.

Screenshots are the second, and they are marketing rather than documentation. Showing the most valuable screens with a clear caption does more than showing the app in order, which is how most listings are assembled.