Mobile App Spacing: The 8-Point System Explained
Mobile app spacing made simple: the 8-point grid, a token scale, iOS and Android margins, touch targets, and a worked example you can copy into any app.

This guide is for founders, developers and junior designers whose app screens look "almost right" but somehow cramped or uneven. Good mobile app spacing is the cheapest fix for that feeling. You will get the 8-point system explained in plain terms, a ready-made spacing scale, the iOS and Android numbers that matter, and a worked example you can apply to your own screens today.
TL;DR: Use multiples of 8 (8, 16, 24, 32, 48) for most spacing, with 4 for tight adjustments. Put less space inside a group than between groups, use 16pt or 16dp side margins on phones, and keep every tap target at least 44pt on iOS and 48dp on Android. Name the steps as tokens so design and code use the same numbers.
What the 8-point system actually is
The 8-point system is a rule: every margin, padding, gap and component size is a multiple of 8. A card has 16 of padding, sits 24 below a heading, and a section break is 32 or 48. Small details such as the gap between an icon and its label use the 4-point half step.
It is not magic, and 8 is not the only valid base. It wins because:
- •It divides cleanly across the screen densities phones use. iOS renders at 2x and 3x, Android at densities from 1x up to 4x; 8 scales to whole pixels on all of them, which avoids blurry half-pixel edges.
- •It reduces decisions. Choosing between 8, 16 and 24 is fast. Choosing between 13, 15 and 18 is a debate.
- •It matches the platforms. Material Design uses an 8dp grid for layout with a 4dp baseline for smaller elements, and most iOS defaults (16pt margins, 44pt rows) sit on or near the same rhythm.
- •It matches code. Tailwind's spacing scale is built in 4px steps (p-2 is 8px, p-4 is 16px, p-6 is 24px), so an 8-point design maps directly to utility classes.
A spacing scale you can copy
Name your steps once and use only these values. Here is a scale that covers nearly every mobile screen:
| Token | Value (pt or dp) | Typical use |
|---|---|---|
| space-1 | 4 | Icon to label, badge offset, tight text stacks |
| space-2 | 8 | Gap between related items, chip padding, list item internal gaps |
| space-3 | 12 | Text block padding inside small components, compact cards |
| space-4 | 16 | Screen side margins, card padding, gap between form fields |
| space-5 | 24 | Space between groups, below section headings |
| space-6 | 32 | Section breaks, space above a primary button |
| space-7 | 48 | Large section separation, empty state padding |
| space-8 | 64 | Hero spacing, top of onboarding screens |
Twelve is the one non-multiple of 8 worth keeping: it is 3 times 4, and many compact components need something between 8 and 16.
In code, the same scale becomes tokens:
:root {
--space-1: 4px;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--space-5: 24px;
--space-6: 32px;
--space-7: 48px;
--space-8: 64px;
}
In SwiftUI or Jetpack Compose, define the same names as constants so Spacing.md means 16 everywhere.
The platform numbers that matter
| Rule | iOS (Apple HIG) | Android (Material 3) |
|---|---|---|
| Unit | Points (pt) | Density-independent pixels (dp) |
| Base grid | 8pt rhythm is common practice | 8dp layout grid, 4dp for small elements |
| Side margins on phones | 16pt standard layout margin; 20pt on larger iPhones in some system layouts | 16dp on compact windows |
| Minimum tap target | 44 by 44pt | 48 by 48dp |
| Standard list row | 44pt minimum height | 56dp one-line, 72dp two-line, 88dp three-line |
| Tab or navigation bar | Tab bar about 49pt plus the home indicator area | Navigation bar 80dp |
| Safe areas | Respect status bar, Dynamic Island and home indicator insets | Respect status and navigation bar insets (edge-to-edge) |
Two things in that table cause most real bugs. First, margins: content that runs closer than 16 to the screen edge looks broken on a phone. Second, safe areas: spacing is measured from the safe area, not from the physical screen edge. Check yours with the notch and safe area simulator, and see how they differ per device in our guide to safe areas and the Dynamic Island.
The one rule that makes spacing feel right
Inside a group, use less space than between groups. This is the Gestalt principle of proximity, and it does more for readability than any colour or font choice.
- •A card's title and subtitle: 4 apart. The card's padding: 16. The gap to the next card: 12 or 16. The gap to the next section heading: 32.
- •A form label and its field: 8 apart. Field to next field: 16. Last field to the submit button: 32.
If every gap on a screen is 16, nothing is grouped, and users have to read everything to understand the structure. Vary the spacing deliberately, in steps from your scale.
Worked example: a settings-style list screen
Imagine a "Notifications" screen with a large title, two groups of toggles, and a footer note. Here is how to space it:
- •Top: start content below the safe area. The large title sits 8 below the navigation bar area, then 24 to the first group header.
- •Group header: a small uppercase or semibold label, with 8 between it and the first row.
- •Rows: each row is at least 44pt tall on iOS (56dp on Android). Inside the row, 16 left padding, 12 between an icon and its label, and the toggle aligned to the right margin of 16.
- •Between rows: 0 gap with a hairline divider inset to the text, or 8 if rows are separate cards. Pick one style per app.
- •Between groups: 32. This is what tells the eye "new topic".
- •Footer note: 8 below the group it explains, in caption-size text.
- •Bottom: keep the last element at least 24 above the home indicator so it never feels jammed against the edge.
Every number came from the scale. Nothing was "eyeballed", and a developer can reproduce it exactly.
Spacing and typography work together
Line height is spacing too. A 17pt body text with a line height of about 22pt sits naturally on a 4-point rhythm, and headings that use line heights in multiples of 4 keep vertical rhythm consistent with the rest of the layout. Generate a scale that does this with the type scale generator, and see our mobile app typography guide for sizes per platform.
When text is involved, measure spacing from the text's bounding box consistently — Figma and code can disagree about where a text box starts, so agree on "box to box" as the rule.
Spacing for components
| Component | Padding | Notes |
|---|---|---|
| Primary button | 16 horizontal, height 48–56 | Full-width on phones with 16 side margins |
| Text field | 12–16 horizontal, height 48–56 | 8 between label and field, 4 to helper text |
| Card | 16 all sides | 12 for dense lists, 24 for feature cards |
| Chip or tag | 8–12 horizontal, height 32 | Keep the tap target 44 or 48 with invisible padding |
| Bottom sheet | 24 top, 16 sides | Grabber 8 from the top edge |
| Empty state | 48 above the illustration, 16 between title and body, 24 to the button | Centre vertically in the available space |
Corner radius should relate to padding too: an inner element's radius is roughly the outer radius minus the padding between them, which keeps nested rounded shapes looking concentric. The border radius generator helps you test this.
Common spacing mistakes
- •Using arbitrary values. 15, 18 and 22 creep in when people nudge by eye. Snap everything back to the scale.
- •Equal spacing everywhere. It flattens hierarchy. Vary gaps by group.
- •Forgetting tap targets. A 24 icon can stay visually small, but its tappable area must reach 44 or 48.
- •Ignoring dynamic type. When users enlarge text, fixed-height rows clip. Use minimum heights and let rows grow.
- •Margins that change between screens. Pick 16 and keep it, unless you switch to a deliberate wider layout on tablets.
- •Measuring from the screen edge, not the safe area. Content collides with the notch or home indicator.
Spacing audit checklist
Use this before handoff:
- •Every spacing value is on the scale (4, 8, 12, 16, 24, 32, 48, 64).
- •Side margins are consistent on every screen.
- •Groups are separated by more space than their contents.
- •All interactive elements have at least a 44pt or 48dp tap area.
- •Content respects top and bottom safe areas.
- •Rows and buttons grow with larger text sizes.
- •Tokens have names, and the same names exist in code.
If you are generating screens with AI, you can ask for this explicitly — for example, in floow you can prompt "use an 8-point spacing scale with 16pt margins" and then check the output against this list.
FAQ
Why is 8 used instead of 10 for spacing?
Eight divides evenly when screens scale at 1.5x, 2x, 3x and 4x, so edges land on whole pixels. Ten does not split cleanly at 1.5x or 3x in every case. Eight also fits Material Design's grid and Tailwind's 4px-based scale, so design and code line up.
Is the 8-point grid the same on iOS and Android?
The idea is the same, but the units differ: iOS uses points and Android uses dp. Both are density-independent, so 16pt on iOS and 16dp on Android look roughly the same size. The main platform differences are tap targets (44pt vs 48dp) and component heights such as list rows and navigation bars.
What margin should a mobile app use?
Use 16pt on iOS and 16dp on Android for most phone layouts. Some apps use 20 or 24 for a more spacious feel; that is fine as long as it is consistent across screens. Always measure margins from the safe area.
Should I use 4 or 8 as my base unit?
Use 8 as the base for layout and 4 as a half step for small details like icon gaps and text stacks. Using 4 as the base everywhere gives you too many choices and less consistent screens.
Design it with floow
You can generate screens that follow your spacing scale from the first draft and refine them through chat. Try this in floow: "Design an iOS notifications settings screen using an 8-point spacing scale: 16pt margins, 44pt rows, 32pt between groups, 8pt between group headers and rows."
Design your mobile app with AI.
Generate pixel-perfect iOS and Android screens in seconds, then export to Figma or code.
You might also like…
Insights12 November 2026Uizard Review 2026: Worth It for Mobile App Design?An honest Uizard review for mobile apps: Autodesigner, screenshot and sketch scanners, prototyping, handoff limits, and who should pick something else.By floow.design
Insights11 November 2026Dating App Design: Profiles, Matching and Chat ScreensDating app design guide: profile creation, discovery and matching patterns, chat, safety features, store rules and premium screens, plus an MVP spec.By floow.design
Insights11 November 2026Paywall Design: 10 Layouts That Convert Free UsersPaywall design for mobile apps: 10 proven layouts, the anatomy of a converting paywall, App Store and Google Play rules, copy and what to test.By floow.design