Put actions in the thumb zone
The primary action belongs in the lower part of the screen. A top-right confirm button on a 6.7-inch phone requires regripping, and people regrip by putting the phone down.
Mobile App UI Designs
App design is constrained in ways web design is not. There is one hand, a reachable area that covers maybe the bottom two thirds of the screen, an operating system with opinions, and a store reviewer who can reject the whole thing over a screenshot size.
The screens collected here are organised by the moment they appear in — first launch, routine use, something went wrong — because those three moments have nothing in common. Onboarding gets one shot and has no data to work with. A daily-use screen is competing with muscle memory. An error state is the only screen that has to work when everything else has failed.
0 layouts in this category.
No layouts in this category yet
Put the image in public/assets/lander/ and add an entry to src/data/landers.ts with its real pixel width and height.
What makes this layout work
Design the empty state first
Every list, feed and dashboard starts empty, and that is the screen a new user actually sees. A blank area with no explanation is where most installs are abandoned.
Onboarding should ask for one thing at a time
Permissions, account, notifications and a tour on first launch is four rejections in a row. Ask for a permission at the moment it is needed, with the reason visible.
Respect the platform where it costs nothing
Back gesture on Android, swipe-back on iOS, system share sheets, native date pickers. A custom control that behaves almost like the native one is worse than the native one.
Store screenshots are part of the design
They are the only screens most people see before deciding, and both stores reject wrong dimensions automatically. Design them as marketing, not as raw captures.
Mistakes that cost the most
Hamburger menu as primary navigation
It hides the app from its own users. Anything behind it gets a fraction of the use of the same item in a bottom tab bar.
Tap targets under 44px
Both platforms publish a minimum for a reason. A dense list of 30px rows produces mis-taps, and mis-taps produce uninstalls.
A loading spinner where a skeleton belongs
A spinner says wait. A skeleton says what is coming and makes the same delay feel shorter.
Text baked into screenshots in one language only
It makes every later localisation a redesign, and it is the most common reason store listings go stale.
Frequently asked questions
Should an Android and an iOS app look identical?
The content and the brand should match. The navigation and the controls should not. Users judge an app against the other apps on their own phone, so a design that ignores platform conventions reads as unfinished on whichever platform it was not designed for.
What screenshot sizes do the app stores need?
Both stores publish an exact required set and both reject submissions automatically when the dimensions are wrong. Check the current requirement in Play Console and App Store Connect at the time you submit — the lists change, and a stale blog post is the usual reason a first submission bounces.
How long should app onboarding be?
Short enough that someone can reach the thing they installed the app for. If onboarding explains features, it is too long — explain a feature at the point of use instead, where it is relevant and cannot be skipped by accident.
Do I need a designer before I can publish?
No, but you need the required assets at the right dimensions, a store listing, and the privacy forms filled to match what the app actually does. Those are the things that block submission, and they are mechanical rather than creative.
Want this built, not just looked at?
A layout is the easy half. The rest is the build, the hosting it runs on, and the renewal price nobody shows you at signup.