A wireframe for a mobile app,
before you design a thing.
Before color or copy, you need a wireframe for mobile app screens: a plain, boxes-and-labels layout that shows what goes where, with nothing styled to distract from whether the flow actually works. This guide covers the real difference between a wireframe, a mockup, and a prototype, the standard iOS and Android screen dimensions to design against, and a step-by-step process for building your own. If you are earlier than this, idea in hand but nothing scoped yet, this fits right before taking an app idea to launch, as the first concrete artifact you produce.
The short version
A wireframe is a floor plan, not a photo.
A mobile app wireframe is a plain layout of a screen, boxes, labels, and placeholder shapes, that shows what goes where and in what order, with no color, no real copy, and no imagery. It is deliberately unfinished-looking, because the point is to test the structure of a screen before anyone spends an hour picking a font for it.
It sits before a mockup (the styled, static version) and a prototype (the clickable simulation) in the usual sequence. Design at real device sizes, iOS in points, Android in density-independent pixels, and use the same handful of wireframing conventions everyone else does, and you will have something worth building from in under an hour.
The distinction
Wireframe vs mockup vs prototype.
These three words get used interchangeably, and that causes real confusion on a team. Each one answers a different question, and each one is meant to take less effort than the one after it. Nielsen Norman Group notes that wireframes can range from a quick sketch to a detailed layout depending on their purpose, but they never carry the final visual design, that is the mockup’s job.
| Wireframe | Mockup | Prototype | |
|---|---|---|---|
| Answers | What goes where? | What does it look like? | How does it work? |
| Visual detail | None, boxes and placeholder shapes only | Full, real color, type, imagery, spacing | Inherited from whatever it is built on |
| Interactive? | No, or click-through order only | No, fully static | Yes, tappable and navigable |
| Typical tool | Pen and paper, or a wireframe kit | Figma, Sketch, or similar | Figma prototyping, or a real build |
| Time per screen | Minutes | 30 to 60 minutes | Hours, once wired up |
Fidelity is a separate axis from this table entirely, and it applies to wireframes on their own, before mockup or prototype even enter the picture. A wireframe can be a two-minute sketch or a detailed, content-accurate layout, fidelity is a choice you make for the stage you are at, not a fixed property of the word itself. Pick a level below to see what changes.
Low fidelity, pen and paper
Minutes per screen
Boxes, arrows, and a few labels. No real device frame, no exact spacing. Built to be thrown away, not kept.
- Hand-sketched or rough digital shapes
- No exact spacing or real device frame
- Fastest way to test whether a flow makes sense
An example
A mobile app wireframe sample, labeled.
Most mobile app wireframe examples reuse the same handful of shapes. Here is one screen built from exactly those conventions, with each piece labeled on the right.
- Thick bar near the top: a header or nav, drawn heavier so it reads as a fixed, structural element.
- Boxed x where an image will go, a placeholder, not a suggestion of what the image contains.
- Thin lines stacked below it: body copy, their width hints at roughly how much text will sit there.
- One solid block, the primary action on the screen, sized to a real tap target, not squeezed into a corner.
- Small dots at the bottom: a tab bar, with one marked to show which section is active.
Standard dimensions
Wireframe design for a mobile app starts at the right size.
A wireframe drawn at an arbitrary canvas size lies to you about how much fits on a real screen. iOS and Android measure layout differently, points on one, density-independent pixels on the other, so a mobile app wireframe template should start from real device numbers, not raw pixels.
iPhone 16 & 15, the most common iOS frame to design against
Minimum iOS tap target, per Apple's Human Interface Guidelines
Minimum Android tap target, per Material Design 3
Android's compact breakpoint, covers 99.96% of phones in portrait
iOS: design in points, not pixels
A point is a resolution-independent unit, one point can be two or three physical pixels depending on the screen. Apple’s Human Interface Guidelines publish exact point dimensions for every current device, a few of the ones you will actually design against:
| Device | Points | Pixels |
|---|---|---|
| iPhone 17 Pro Max | 440 x 956 pt | 1320 x 2868 px @3x |
| iPhone 17 / 17 Pro | 402 x 874 pt | 1206 x 2622 px @3x |
| iPhone 16 / 15 | 393 x 852 pt | 1179 x 2556 px @3x |
| iPhone 16e | 390 x 844 pt | 1170 x 2532 px @3x |
| iPad Pro 13-inch | 1032 x 1376 pt | 2064 x 2752 px @2x |
The 44pt tap target
Apple’s guidelines are specific here too: “a button needs a hit region of at least 44x44 pt” so people can select it easily with a fingertip. Draw your wireframe’s buttons at something close to that, even as empty boxes, or you will design a mockup with tap targets too small to actually use.
Android: breakpoints, not one device list
Android does not publish one master device table the way Apple does, phones vary too much in screen size across manufacturers. Instead, Google defines width window size classes to design against, measured in dp (density-independent pixels, Android’s equivalent of a point):
| Size class | Width breakpoint | Typical device |
|---|---|---|
| Compact | Under 600dp | 99.96% of phones, portrait |
| Medium | 600dp to 840dp | Most tablets, portrait |
| Expanded | 840dp to 1200dp | Most tablets, landscape |
| Large / extra-large | 1200dp and up | Large tablets, desktop |
The 48dp touch target
Material Design 3 sets the minimum target size for a tappable icon or button at 48dp, a little more generous than Apple’s 44pt. A safe, practical mobile app wireframe template for a phone screen is a compact frame roughly 360 to 412dp wide, whatever device you pick, with buttons boxed out at close to that 48dp minimum from the first sketch.
The process
How to wireframe a mobile app.
If you have not scoped your idea yet, start with i have an app idea where do i start first, and if you are about to show the idea to a contractor or a partner, it is worth also reading i have an app idea how do i protect it. Once you know roughly what the app does, wireframing it is five steps.
| Way to wireframe | Cost | Speed | Fidelity ceiling | Best for |
|---|---|---|---|---|
| Pen and paper | Free | Seconds per screen | Low fidelity only | Exploring a flow alone, fast |
| Digital wireframe tool | Free to ~$15/mo | Minutes per screen | Low to high fidelity | Sharing with a team, reusable components |
| Skip to a real screen | Varies by tool | As fast as you can describe it | Already styled, not a wireframe | Simple apps, or once the flow is already clear |
- 1
List every screen in the core flow
Write down the screens someone touches to complete the app’s main job, sign up, home feed, item detail, checkout, done, nothing more. Most mobile app wireframe examples fail not because the boxes are drawn badly but because a screen or a state (empty, loading, error) was never listed at all.
- 2
Pick a device frame and stick to it
Use one real frame size for every screen, 390x844pt is a reasonable default for iOS, a 360 to 412dp compact frame for Android, so what you draw actually reflects how much content fits. Include the device chrome, status bar, home indicator or nav bar, so you are not accidentally designing over space you do not control.
- 3
Draw the biggest shapes first
Block out navigation, then headers, then the largest content area, before any small detail. A mobile app wireframe sample screen usually reads, top to bottom, as a nav bar rectangle, a thick line for the header, a boxed x for an image, and thin lines for body copy, the same handful of shapes reused on every screen.
- 4
Fill in buttons, fields, and small controls
Add the smaller pieces last, buttons, dropdowns, checkboxes, text fields, at roughly their real tap-target size (44pt iOS, 48dp Android). Mark the primary action on each screen so it is obvious, even in outline form, what someone is supposed to do next.
- 5
Walk the flow, out loud, screen to screen
Trace every button to where it leads, ideally with someone else watching. Gaps show up fast this way, a button with nowhere to go, a screen no path reaches, a missing back option, and they are nearly free to fix now, versus expensive to fix once a mockup or a real build exists.
Check your work
Ready to move to mockups?
Check off each line as it is genuinely true of your wireframe. It is not a formal audit, just a way to catch the gaps before you spend real time on visual design.
What’s next
From wireframe to mockup.
What comes next is the visual layer: colors, type, spacing, imagery, and the dozens of small decisions that turn grey boxes into something a user would recognize as an app. Those choices deserve more than a paragraph tacked onto the end of a wireframing guide, so they get their own — Newly’s mobile app design basics starts exactly where the boxes and labels leave off.
Where Newly fits
A wireframe is prep work, not a requirement.
Newly is an AI app builder, from $25 a month: you describe the app you want and it generates a real, native iOS and Android app, not a clickable mockup of one. That changes what a wireframe is for. You are not drawing boxes so a designer can turn them into screens later, you are drawing them so your own description is specific enough to build from on the first try.
For a simple app, a few sentences might be enough and you can skip wireframing entirely. For anything with more than a handful of screens, ten minutes of boxes still pays for itself, it is the cheapest way to know what you are asking for before you ask for it. A wireframe that survives that scrutiny is also the best possible input for the step-by-step tutorial on building your first app, which turns exactly that kind of sketch into a working build on a real phone.
FAQ
Wireframing a mobile app, answered.
A wireframe for a mobile app is a plain, low-detail layout of a screen that shows what goes where, without color, real copy, or imagery. It uses simple shapes, boxes for buttons, an x through a rectangle for an image placeholder, thick lines for headers, thin lines for body text, to communicate structure and hierarchy, not visual style. Its job is to answer where does each thing go before anyone spends time on how it should look.
Boxes drawn? Build the real thing.
Once your wireframe holds up, describe it to Newly and get a real, native iOS and Android app, not another mockup, from $25 a month.