Mobile App Design Guidelines: A Practical 2026 Checklist

Mobile app design guidelines are the rules a product has to pass on a real phone in a real hand: can people get in, trust what they are asked for, read and hit what is on the screen, and move through the task the way their operating system taught them to. Most apps that “need a redesign” fail those rules before users ever reach the screens the team wants to repaint. A shinier interface on top of an onboarding that never ends is lipstick on a pig. The pig still does not sign up.

In our mobile design and redesign work, the story that walks through our door has barely changed. “We have no monetization. Let’s update the design.” Then we open the funnel, and the problem is not on the screen they want to refresh. It is in the questions, the permissions, the trust signals and the phone the founder tested on — which, by pure coincidence, is always the biggest one Apple sells.

This article is the review we run before anyone touches the visuals. It starts where users actually leave, moves through the physical rules of a small screen, separates what iOS and Android can share from what they cannot, and ends with a checklist you can run on your own product before handoff or release.

Really important: the non-negotiable mobile checklist

Before reviewing decoration, check the main task on the smallest supported phone:

• Keep three to five meaningful primary destinations; do not overload the tab bar or hide core tasks under More.
• Provide hit areas of at least 44 × 44 points on iOS and 48 × 48 dp on Android, with space between neighboring controls.
• Resolve nested scrolling, carousels, swipe actions and system-edge gesture conflicts; keep an alternative to a gesture-only action.
• Open the right keyboard at the useful moment, keep the focused field and next action visible, and make Next advance where appropriate.
• Do not require dismissing the keyboard and then tapping the same Next action again.
• Put frequent actions within comfortable thumb reach and test both right- and left-handed use.
• Define adaptive layouts for wider or resizable windows, rotation and supported foldables rather than enlarging one phone frame.
• Preserve progress and selection through interruptions, keyboard changes and layout changes.
• Test large text, assistive technology, reduced motion and realistic loading, error and offline states.

These checks are about the usable hit area and behavior, not only the visible icon or a screenshot’s dimensions. Use the supported-platform guidance and actual devices for acceptance.

What mobile app design guidelines are — and what they are not

Guidelines are the building code. Trends are the paint colour. A building code tells you how wide the stairs must be, where the fire exit goes and how much weight the floor has to carry. Nobody tours a house to admire the stair width — but everybody notices when they fall down the stairs.

Mobile guidelines work the same way. They cover the things that decide whether a person can use the product at all: the order of the flow, the size of what they touch, how readable the text is at arm’s length, what happens when the network drops, how permissions are asked, how the app behaves when the system does something the team did not plan for. Apple’s Human Interface Guidelines and Google’s Material Design are the official versions for each platform, and they are worth reading. They are also written for every app on Earth, which means they cannot tell you what your product specifically gets wrong.

Trends are what this year’s showcase phones look like: glassy blur, oversized headers, gradient everything. There is nothing wrong with a trend, the same way there is nothing wrong with designer wallpaper. It just does not matter if the house has no front door.

So the useful question is never “does our app look current?” It is “which rule does our app break, for whom, and what does it cost us?” Every section below answers that in the same order: the task the guideline protects, the failure it prevents, the design decision it changes, and how you check it.

The funnel leaks before the first screen

Here is the thing nobody wants to hear when they book a redesign: mobile products very often do not get signups at all. People download, open, start filling things in — and abandon. You can watch it happen in the analytics like water running out of a bath with no plug.

And on a phone you are not competing for screen space. You are competing for attention. A chat notification or another task can interrupt the flow at any point. If the user switches away mid-signup to do something else, your app joins the pile of open apps — and gets opened again only when the phone runs out of memory, starts to lag and they swipe the whole stack closed. By then you have already spent your customer acquisition cost on that person, and you have nothing to show for it: no registration, not even an email to bring them back with.

Fintech is the loudest example. Identity verification can be lengthy, and products can add unnecessary work: every document up front, every field mandatory, no progress saved if the user steps away to find their passport. Confirm mandatory steps and permitted sequencing with the responsible product and compliance owners. People start, get halfway, close the app and never come back. You paid for that install. You paid again for the retargeting ad that brought them back to the same wall.

Consumer apps do it to themselves too. We worked on an app built around measuring your internal energy “battery”. To get inside, a new user had to wade through what felt like 150 questions and grant access to Apple Watch, Activity and Health — before seeing a single thing the product could do for them. Another app, about growing taller, wanted your parents’ heights, your own height, and a huge imperial-versus-metric switcher on every field. There is a reason to collect genetics for a height app. There is no reason to collect all of it before the user has seen a single useful result.

The more questions, the more of these requests, the more the user simply flows out of the funnel. You can see it very clearly in the analytics.

A mobile onboarding is a school entrance exam. If you make a seven-year-old sit a three-hour exam before they are allowed to see the classroom, most of them go home — and the ones who stay are not the ones you most wanted. Ask for what the first useful result needs, show the result, then ask for the rest when the user has a reason to answer.

Trust is a design decision, not a legal page

People do not read your privacy policy. They read your interface. And the interface tells them, in about two seconds, whether handing over their bank login or their heart rate is a good idea.

The energy-battery app asked for Health and Apple Watch access with no explanation of why. It dressed itself as something light and fun — a fancy, playful interface — and then asked for data that feels medical. That is a mismatch users feel in their stomach even if they cannot name it. They decline, or they leave.

Then there is the worst version we have seen. A personal finance manager came to us after launch. The client had spent at least 10 to 15 thousand dollars on development and more than 5 thousand on ads. His TikTok videos went viral, and roughly 8 thousand people launched the app. The funnel looked healthy until the very end: zero completed signups. Not low. Zero.

The last step asked for card details typed straight into a plain form on the iPhone — no Stripe, no Apple Pay, no recognisable payment sheet. The whole app looked like it was built in 2015: fixed frames, a layout that did not adapt, nothing that said “a real company stands behind this”. It looked like a scam. The founder had very good reasons in his own head — he did not want to give Apple its cut, everything was already wired, it all worked. It did work. Nobody trusted it.

You can be endlessly right in your confidence. The user still won’t type their card number into something that looks like a scam.

Trust on mobile is built the way a new babysitter earns a key to your flat: an agency you recognise, references you can check, and nobody asking for the spare key on the first visit. In an app that means payment through a sheet people already know, sensitive requests explained in plain words right before they are needed, a visual quality that matches the stakes, and security cues where money or health data is involved.

Wrong category signal: when the concept is the bug

The second most common request we hear is “our monetization is weak, let’s redesign”. Most of the time the problem is not the design. It is the concept, the idea, or the complete absence of art direction — usually because the app copies a popular product from a different category, and the client loves how that product looks.

A fintech app cannot borrow the look of a meditation app. Soft pastel waves and slow breathing animations say “relax, nothing here matters much”, which is exactly the wrong thing to say to someone deciding whether to connect their bank account. A kids’ learning app dressed like a trading terminal fails the same way in the opposite direction. Every category has a visual language users read before they read a single word: fintech says control and safety, health says care and precision, entertainment says fun.

It is putting the cart before the horse: polishing the screens before anyone has decided what the product is and who it is for. When the client does not want to hear that, the result is a well-drawn app that tells users the wrong story — and a redesign bill for something that was never broken.

Hierarchy and navigation: one screen, one job

Once people are inside, the next question is whether they can find what they came for. On a small screen there is no room for a menu of everything. A mobile screen is a single-purpose tool, like a screwdriver: the moment you try to make it a Swiss Army knife, the main blade gets harder to open.

The checks are simple and unforgiving:

• One primary action per screen. If two buttons compete for the thumb, the user hesitates, and hesitation is where drop-off starts.
• Navigation that matches the platform. A tab bar for the few top-level destinations, a clear way back, no hidden hamburger holding half the product.
• Information architecture built from tasks, not from the org chart. The menu should read like the user’s jobs, not like your departments.
• Chunked content. Long flows split into short, labelled steps with progress, so nobody feels they are filling in a tax return on a bus.

Forever Beauty is a good example of how expensive the opposite gets. It was a live AI and AR skincare app with real users and a backend nobody was allowed to touch. Unclear navigation and no guidance meant people abandoned the app before reaching the actions that made it worth using. The fix was not a new engine. It was a screen-by-screen audit, a new information architecture and a calm interface laid over the logic that already ran — the whole case is on our site as Forever Beauty.

Tabs and More are information architecture decisions

Use three to five primary destinations as a practical starting point, then test the actual task model. More is for secondary material, not a hiding place for booking, payment or the product’s central action. Keep labels understandable and the current destination clear; changing the order to promote a campaign can break learned navigation.

Sailo shows why the booking task needs more than an attractive search screen: full charges, captain choice, temporary hold, confirmation and cancellation each have a defined place. The design spans iOS and a responsive browser experience; ANODA did not implement its integrations. For that complete reservation scope, see booking app design.

A finger is not a cursor

Designers work on big monitors with a mouse pointer one pixel wide. Users work with a thumb, on a bus, holding a coffee. A finger is not a cursor. A finger is a sausage. When you test your app, you can literally take a sausage and try to tap with it — and you will immediately see which buttons were designed for a mouse.

That is not a joke. It is the cheapest usability test there is. If you have to bring your finger close and aim to hit a button, the touch area is too small, and the app is already junk in the user’s hand. The platforms put numbers on this: Apple asks for hit targets of at least 44 × 44 points, Google’s Material guidance asks for at least 48 × 48 dp. The visible icon can be smaller; the tappable area cannot.

Reach matters as much as size. On a large phone held in one hand, the top corners are a stretch, and the bottom of the screen is where the thumb lives. Put the frequent actions where the thumb is, not where the designer’s eye went first.

Gestures bring their own trouble. Both platforms reserve screen edges for the system: swipe back, swipe home, pull down notifications. A carousel that swipes from the edge, or a custom gesture in the same place, fights the operating system — and the operating system always wins.

Resolve competing gestures and test both hands

A horizontal carousel inside vertical scrolling needs an intentional gesture-recognition rule. A swipe-to-delete row beside an edge-back gesture needs room and a visible alternative. Avoid several nested scroll regions when one clear flow will work. Test interrupted gestures, slow movement, overscroll and system Back rather than assuming the prototype’s swipe means the same thing in code.

Move a frequent action into comfortable reach without favoring only one hand. Test right- and left-handed use, one-handed and two-handed, with the actual keyboard and system navigation visible. Do not make an irreversible action easy to hit accidentally simply because it is near the thumb.

Readable at arm’s length, on the phone users actually have

If people have to bring the phone up to their eyes to read something, it is unreadable — and it is junk. People hold phones at arm’s length, in sunlight, on a moving train. Small grey text on a light grey background is a design that only works in Figma at 200% zoom.

This is also where we lose patience with the big, beautiful, blue header. Why? Yes, you are successful, and you are checking the design on the biggest Pro Max on the market. Your user may have an iPhone SE or the smallest phone that still gets updates. On that screen your header eats half the view, and the part the user actually needs is left with a scroll area the size of half a finger. The task disappears under the branding.

Designing for the showcase phone is like hanging a classroom’s coat hooks at the height of the tallest teacher. It looks tidy in the photos, and every kid in the class needs a chair.

What we do not negotiate on, on any mobile product:

• Text that scales. Support Dynamic Type on iOS and font scaling on Android, and check the layout at the largest sizes.
• Contrast that survives sunlight. At least 4.5:1 for body text, per WCAG — more is better outside.
• Colour coding with meaning, used the same way everywhere, and never as the only signal.
• Icons that lower cognitive load: understandable, in one style, clean. A set of icons from three different libraries is visual garbage, and on a small screen garbage has nowhere to hide.
• The smallest supported viewport as the design baseline, not the largest.

Forms and keyboards are where the money is

Every signup, payment and booking on mobile runs through a form, and a form on a phone is a small act of hostility unless someone designed it to be otherwise. The keyboard covers half the screen. Every extra field costs a few seconds of thumb-typing and a small chance the user gives up.

The rules are old and still broken daily:

• The right keyboard for the field. Numbers get a number pad, emails get the email keyboard, and nobody should switch layouts to type a phone number.
• Autofill everywhere it is allowed. Names, addresses, passwords and one-time codes. On iOS the code arrives as a suggestion above the keyboard; on Android, supported verification flows can use SMS Retriever or SMS User Consent rather than requesting broad access to messages. Different mechanics, same goal: the user should never retype six digits from a notification.
• Useful unit defaults. Locale can suggest a unit system, but it does not establish where a user lives or what they prefer. Show the unit, allow a correction and preserve it across fields rather than adding an oversized switcher everywhere.
• Errors next to the field, in plain words, before the user hits submit — not a red banner at the top after they did.
• Progress that is saved. A user who leaves step four of KYC to find a document should come back to step four, not to step one.

Make the keyboard part of the flow

Bring focus to the field when input is needed, not while the person is reading an explanation. Keep the active field, its validation and the next action visible above the keyboard and safe areas. Use Next to advance to the next appropriate field, and Done or a labeled submit action at the end. Multiline fields still need Enter to insert a line break; do not silently submit them.

A person should not have to close the keyboard and tap Next again to perform the same action. Test hardware keyboards and missing return keys as well as common software layouts. On validation failure, retain values, reveal the affected field and announce the error appropriately.

Blackstar provides an actual investment design example: onboarding can be saved and exited, Active and Auto Invest are distinct paths, and an unconfirmed bank payment stays Still Processing. ANODA delivered the app redesign, system and subsequent responsive website; the client built them. The screens give users a clear next action while verification or payment is still pending.

Feedback, loading, empty, error and offline states

A mobile app is used on a train that goes into a tunnel. If the design only covers the happy path on office Wi-Fi, it covers the least likely situation there is.

Feedback comes in three forms, and good apps use all three with restraint: visual (the button changes, the item moves), sound where it helps, and haptics — a small vibration that confirms “done” without the user looking. Speed is feedback too. If a tap takes a second to answer, people tap again, and now you have two orders.

Then the states nobody designs until production:

• Loading that shows real progress or the shape of what is coming, not an eternal spinner.
• Empty screens that tell a new user what to do first, instead of a sad illustration and nothing else.
• Errors that say what happened and what to do next.
• Offline behaviour that keeps what the user typed and tells them what will sync later.

Clearwater Wellness shows why this matters beyond politeness. The app interfaces with a physical cold-plunge unit, so temperature, timing and connection states need clear product feedback. The interface distinguishes connection status, command progress and recovery so users can tell what the device is doing. We designed states such as connected, connecting, lost, countdown and error, and you can see them in the Clearwater Wellness case.

Permissions, notifications and system UI

Permissions are where mobile design meets the operating system, and the operating system has opinions. Ask at the wrong moment and you do not get a second chance: on iOS a declined permission sends the user to Settings to change their mind, and on Android repeated refusals turn into “don’t ask again”.

The rule is simple: ask when the user is about to do the thing that needs it, and explain why on your own screen first. Camera access when they tap “scan”, not on the splash screen. Location when they open the map. Health data when they start the first measurement, with one sentence about what you will do with it.

Notifications follow the same logic. Both platforms now require explicit permission — Android since version 13 — and a prompt on first launch mostly collects refusals. Earn the permission with a moment where a notification is obviously useful: “remind me when my session starts”. Then use it sparingly. Push notifications are a megaphone in someone’s pocket; shout too often and they take the batteries out — that is, uninstall.

Personalisation sits here too, and it should match the trust you have earned. Recommendations built from what someone did in your app feel helpful. Recommendations that reveal you know more than they told you feel creepy, and creepy is a very short step from deleted.

System UI completes the picture: the status bar, the home indicator, the notch and the camera cut-outs, the keyboard. Your layout has to live around them on every phone, not only on the one in the mock-up.

Accessibility and reduced motion

Accessibility on mobile is not a separate feature for a small group. It is the same work as everything above, done properly: large enough targets, readable text, contrast, clear labels. The people who benefit include your users with low vision, your users with tremors, and your users with one hand busy holding a child or a coffee.

The checks that catch most problems:

• Screen readers. Turn on VoiceOver and TalkBack and complete the main task with your eyes closed. Unlabelled icons and buttons that read as “button” are found in minutes.
• Text scaling at the largest sizes, without clipped labels or overlapping controls.
• Reduced motion. Respect the system setting: parallax, auto-playing animation and big transitions become simple fades.
• Colour never alone. Status needs an icon or a word, not just red and green.

Responsive, adaptive layouts and device changes

Phones are not one size, and they do not stay in one shape. They rotate, split the screen, fold open, change text size in the middle of a session and switch between light and dark. A layout drawn for one frame is a suit tailored for a mannequin: it fits beautifully until someone moves.

Design the smallest supported phone first, then show how the layout grows: which columns appear on a large phone, what happens on a tablet or a foldable, what stays fixed and what scrolls. Clearwater had to hold up across phones and tablets because people control the unit from whichever device is nearest, so the responsive UI was designed as part of the product, not as a resize at the end.

For the web side of the same product, we cover the layout rules separately in our guide to mobile responsive design best practices — this article stays on native apps.

Adapt the task when a window changes

Define behavior by the available space and input, not a single device name. A wider view can use list and detail panes; a compact view needs a clear route between them. Keep the selected record, draft and navigation position when rotating, resizing or moving between supported screen arrangements. Check system insets and posture-related constraints on the devices in scope rather than inventing a universal foldable layout.

The test matrix should include small and large windows, portrait and landscape, split-screen where supported, text scaling, software and hardware keyboards, both platform back patterns, slow networks, realistic long content and interrupted work. Record the actual supported combination; not every operating system offers the same window behavior.

iOS and Android: share the product, respect the platform

A shared interface for iOS and Android is fine. Most of the product — the flows, the content, the brand — can and should be the same. What cannot be the same is how the app plugs into each system.

The differences are not cosmetic. The hierarchy of permission requests differs. Access to SMS differs: on iOS an app cannot read messages and only gets the one-time code as a suggestion above the keyboard, while Android offers SMS Retriever and SMS User Consent APIs for supported verification flows. Back navigation differs: Android has a system back gesture that has to work everywhere in the app, iOS relies on the navigation bar and the edge swipe. How an app goes to the background and returns differs. Where the system reserves touch areas differs.

What we see far too often is a team trying to save money with one universal app and one codebase — a reasonable decision — and then ignoring every nuance of how each system works. The design is made for iOS. Android is treated as an afterthought, whatever is left over. Then the Android users, who are often the majority of a market, get the leftovers and leave reviews to match.

Android deserves an explicit review alongside iOS. The system is heavily fragmented, and so are the screens: sizes, aspect ratios and pixel densities vary far more than on iOS. A layout that looks perfect on two iPhones can break on a mid-range Android phone with an unusual density.

Plan platform review as part of the implementation scope. Design for iOS if that is your lead platform. Test on iOS. Then take a second device — an Android phone — and check everything on it, the whole flow, not a screenshot of the home screen.

Implementation review: the app your users get is not the Figma file

A design file is a promise. The build is what users actually get, and the two drift apart the moment development starts: a font falls back, a padding shrinks, a state was never implemented, a touch area became the size of the icon.

Review the build the way a site inspector reviews a house before the keys are handed over: not from the drawings, but walking through the rooms. On real devices, with real data, compare every key screen and state against the design, and log the differences with a screenshot, the device and the severity. The cheapest bug to fix is the one found before release; the most expensive is the one your users find in public.

For teams that need to know which problems will survive into real use, the next step is testing the riskiest tasks with real users on real devices — the kind of focused session we run in usability testing.

Measure the task, not just the visit

For each key journey, define an eligible start and confirmed success event, plus failure and recovery. Keep attempts separate from completed bookings, payments or submissions. Segment by app version, platform and relevant audience, and compare equivalent periods to see whether more people reach the value they installed the app for.

Pair useful completion and time-to-value with errors, unintended actions, support contacts and permission opt-outs. If analytics shows a drop, observe the task to explain it; a longer session can mean confusion and a shorter one can mean efficient completion. These definitions belong in the implementation handoff beside the flow and acceptance checks, so the design, build and measurement refer to the same job.

The review sequence we run

The order matters. Polishing screens before you know whether people can get in is rearranging deck chairs on the Titanic. This is the sequence we use on a live or nearly live mobile product:

1. Activation and funnel. Map every step from install to first value and find where people leave.
2. Trust and requests. Review every question, permission, payment and identity step: needed now, explained, recognisable?
3. Concept and category signal. Check that the product looks like what it is, for the people it is for.
4. Hierarchy and navigation. One job per screen, platform navigation, tasks before features.
5. Physical usability. Touch targets, thumb reach, gestures, readability at arm’s length on the smallest phone.
6. Forms, feedback and states. Keyboards, autofill, loading, empty, error, offline.
7. Platform behaviour. The iOS and Android differences, tested on a real device of each.
8. Accessibility and adaptivity. Screen readers, text scaling, reduced motion, rotation and size classes.
9. Build versus design. The implementation checked on real devices before release.

Mobile app design release checklist

Run it before handoff, and again before every release that changes a key flow.

If you want to see how these rules look in finished products, our collection of mobile app design ideas and inspiration is the gallery; this checklist is the inspection.

For a consumer product, B2C product design connects onboarding, repeated tasks and account control. Use this checklist to define what the mobile interface must do; retain its platform-specific acceptance checks in the handoff.

What to fix first

Review the activation logic, the trust signals, the platform behaviour and real-device usability before you polish a single screen. Every onboarding question, KYC step, permission request, unit choice, category cue, touch target, icon and decorative region has to earn its place by helping the user understand the value and finish the task.

Then test the whole flow the way your users live with it: at arm’s length, with an ordinary finger, on the smallest screen you support, on a real iPhone and a real Android phone. If the concept, the trust signal, the readability, the physical interaction or the operating-system integration is wrong, no amount of surface polish and no universal codebase will fix your monetization or your retention. Everything you don’t fix, you choose to keep paying for.

Platform references

• Apple button hit regions
• Android accessible touch targets
• Android SMS verification