Designing a mobile app is about journeys, sizes and screen states, not about picking colours and fonts. The mobile part begins where the web ends: a finger instead of a cursor, gestures the system has already claimed, safe areas and cutouts, permissions and life without a connection. Apple and Google have written these rules down, and design work starts there.
Key takeaways
Three things set it apart: finger input instead of a cursor, written platform rules instead of free-form layout, and a product that has to work offline. Habits that serve you well on the web break on a phone: a small icon cannot be hit, hover does not exist, and a custom swipe fights a system gesture.
| Point of comparison | Mobile app | Website |
|---|---|---|
| Input | Finger and gestures: aim is approximate, there is no hover state | Cursor and keyboard: aim is precise, hover and focus exist |
| Design rules | Apple and Google guidance plus a store review before release | W3C standards and the team's own judgement |
| Navigation | The system owns part of the gestures: back, app switching, the shade | The browser back button and address bar |
| Connectivity | Screens open offline, data lives in a cache on the device | No connection means no page |
| Updates | Through the store: part of the audience stays on an old build for months | Everyone gets the new version on their next visit |
What UX and UI are, how an interface moves conversion and retention, and which stages the work goes through are covered in our article on UX/UI design for websites and digital services. From here on this piece stays on the mobile side.
The lower limits come from three documents: Apple's guidance for iOS, Android's guidance and the WCAG 2.2 accessibility standard. This is the one part of mobile design with exact numbers, and arguing with them is pointless — they are also what the app is measured against at review.
Apple puts the rule plainly: make controls at least 44 by 44 points so they can be tapped accurately with a finger, and keep text at 11 points or larger so it stays legible without zooming. Android asks for a focusable area of at least 48 by 48 dp on every interactive element and adds that larger is better.
WCAG 2.2 is a W3C standard published on 12 December 2024. It calls for a contrast ratio of 4.5:1 for body text and 3:1 for large text, while success criterion 2.5.8 sets a minimum pointer target of 24 by 24 CSS pixels at level AA. The platform figures of 44 pt and 48 dp are stricter, so on a phone they are the ones to design against.
Mistake An icon is drawn at 24 by 24 and the same box is left as the tappable area. The visible element may stay small — what has to grow is the area that responds to a finger, through transparent padding around the icon.
What differs is behaviour rather than looks: how a person goes back, where the main sections live and which screen edges the system keeps for itself. The visual style stays the same across platforms — what travels between them are your brand rules, not system elements.
| Element | iOS | Android |
|---|---|---|
| Going back | A button at the top left and a swipe from the left edge | A system gesture from a side edge or a button in the navigation bar |
| Main sections | A tab bar at the bottom of the screen | A bottom navigation bar or a drawer |
| Primary screen action | A button in the top bar or inside the content | A floating action button over the content |
| Hardware quirks | The home indicator at the bottom, a notch or island at the top | Hundreds of models with different cutouts and edges, plus foldables |
| Leaving the app | A journey ends by closing the screen | The back gesture on the first screen closes the app |
Hence the working rule: a mock-up describes not one screen but its behaviour on both platforms. The more components the two share, the cheaper support becomes — which is a separate argument when choosing between native and cross-platform development.
The safe area is the part of the screen that system elements never cover: the status bar, the camera cutout, the home indicator and the gesture zones. Everything a person taps lives inside it; backgrounds may run beyond it.
With Android 15 this stopped being advice: apps built against API level 35 are drawn edge to edge by default, and content slides under the system bars unless the developer handles insets. The designer hands over a layout that shows where the background ends and the safe area begins.
The first launch loses more users than any other screen, almost always for two reasons: a long tour before any value, and permission prompts with no explanation. Both are fixed by the order of steps rather than by the wording on a slide.
Store rules agree with common sense here. Under clause 5.1.1 Apple requires that purpose strings clearly and completely describe how the data is used, forbids asking for access unrelated to core functionality and separately forbids pressuring people into consent. The same section carries rule 5.1.1(v): if an app supports account creation, it must also offer account deletion inside the app.
Notification permission is a conversation of its own: when to ask, how channels work and which scenarios earn their place are covered in our article on push notifications in an app.
A screen is not one picture but a set of states, and half of the design work goes into the ones that never reach a presentation. A state nobody drew will be invented by a developer — usually as blank space or a raw error message.
In Uzbekistan there is one more item: three interface languages. The whole Syntra Health interface exists in Russian, Uzbek and English, and line lengths differ between them — a button that fits in Russian wraps onto two lines in Uzbek.
The order of the work is the same for an app of any size; only the depth of each step changes. Below are the stages and the deliverable the client keeps after each one.
A design system pays off on the tenth screen rather than the first: in the QADAM project a fourteen-section brand book described the mark, the palette, the icons and the states before development began, which turned assembling new screens into mechanical work.
The same mistakes repeat from project to project, and every one of them is visible in the layout — before it reaches the code and the store reviews.
A redesign without diagnosis is a mistake of its own. If people do not reach payment, changing the palette will not help: first find the step where they leave, then fix that step.
Interface quality is measured by behaviour, not by opinions about a layout. For a mobile app the set of indicators differs from a website: installs, permissions and store ratings join the funnel.
Numbers show where the problem is but never explain it. The reason is found with live people: a short journey test with a handful of users before the build costs less than reworking finished screens — how that is organised is described in our article on UX/UI design for digital products. Store requirements for the build and its metadata are covered in the piece on publishing to the App Store and Google Play.
We start with the journey and the data rather than a layout: which screens a person passes on the way to the goal, what they already know and what the app is obliged to ask them. A prototype comes next, the logic is tested on it, and only then does the visual layer appear — together with a design system, so that the following screens come together quickly.
That is how the KruchuVerchu app was built: a dish configurator with an honest price for every extra, a product card with weight and ingredients, a basket always in view and courier tracking — a set of screens assembled around a single ordering journey. We do not sell interface design as a separate service: it is part of building the product, as in website and platform development, where design, build and analytics come as one package.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
The visual style transfers in full; behaviour does not. Going back, the placement of main sections, the primary screen action and system gestures all stay different. In practice teams draw one design system and two sets of navigation screens rather than two separate apps.
Count states, not screens: a single catalogue screen means loading, an empty result, no connection, an error, a plain list and a filtered list. If an estimate lists only ‘screens’, half the designer's work is invisible in it, and the developer ends up inventing those states later.
A small product does fine with the basics: buttons, fields, cards, notifications, spacing rules and state colours. A full system becomes worthwhile once more than one person works on the app or new sections ship on a regular schedule.
Without a prototype, a structural mistake only surfaces once the app is already built. Fixing it then pulls in the front-end, the back-end and a new store review, and some users end up stuck on the old version for months. On a prototype — clickable draft screens — the same mistake is fixed in a single pass.
Start by looking at the data: where people drop off, what support gets asked about, what reviews say. If the problem sits in two or three scenarios, fixing them is cheaper. A full rebuild is justified when a new feature simply doesn't fit into the current structure.
Three things are checked against the design before the build: whether text reads against its background (contrast of at least 4.5:1 under the WCAG 2.2 accessibility standard), whether buttons are no smaller than the platform minimums — 44 × 44 pt on Apple and 48 × 48 dp on Android — and whether the screen still holds together if someone enlarges the font in their phone settings. After the build, the checks are repeated on a real device.
Sources
