16 dpLayout unit
dp → Size and spacing
Padding, card dimensions, corner radius, icon sizes. Density-independent so the same UI remains visually consistent across resolutions.
A visual guide for product & UI designers
Same design.
Different screens.
Should you change font sizes for every phone? Usually, no. Understand the difference between density, text scaling, and responsive layouts—then try the live preview.
The 15-second answer
In Compose Multiplatform, we define spacing and component sizes in dp, and text sizes in sp. The framework handles screen density; sp also follows the user's text-size preference. We adjust layout for width, not every font just because a phone has more pixels.
16 spText unit
sp → Font size
Like dp, plus accessibility font scaling. Text can grow when the user increases the preferred text size on Android or iOS.
320 → 768Window width
Width → Responsiveness
A narrower screen wraps content. A wider layout may show more columns. Font-size changes are optional, intentional design decisions.
01 — Try it yourself
Interactive layout lab
Change one variable at a time to see what actually changes.
Shared Compose UI (illustrative)
390 dp · 2× density · 100% text
Change widthCards reflow at breakpoints.
Change densityUI stays the same logical size.
Change text scaleText grows; content needs room.
02 — The pixel illusion
Why 16 dp ≠ 16 physical pixels
Resolution and density are not the same thing as screen width.
One button, three densities
Each blue bar is exactly 160 dp wide in logical layout. A higher density uses more physical pixels to render that same size.
1× display160 dp = 160 px
2× display160 dp = 320 px
3× display160 dp = 480 px
Simplified scale-factor examples. Actual Android device densities can be fractional, and real devices may apply display scaling.
Now compare text and layout
Two independent rules explain most designer-to-developer handoffs.
dp
16.dp padding
Stays at 16 logical layout units, even when you switch from a 1× to a 3× display.
sp
16.sp text
Keeps the same typography token across phones, but system font preferences can enlarge its rendered text.
↔
320 dp vs 768 dp
A larger available window may use different columns, spacings, or an intentional tablet type scale.
Physical px are output pixels. They are not the unit designers should normally use for mobile UI dimensions.
03 — Cross-platform handoff
What to specify in Figma
For the native apps and shared Compose Multiplatform screens.
One design system, platform-aware implementation
At a standard 1× design reference, use logical design values—not screenshots multiplied by device scale.
| Design property | Compose Multiplatform | Native Android | Native iOS |
|---|---|---|---|
| Spacing, icon & component size | dp e.g. 16.dp | dp e.g. 16dp | pt (points) e.g. 16pt |
| Text sizes | sp e.g. 16.sp | sp e.g. 16sp | pt + Dynamic Type Prefer semantic text styles |
| Accessible text scaling | sp supports Android font settings and iOS Dynamic Type | System font settings; Android 14+ may scale nonlinearly | Dynamic Type when implemented with scalable text styles or metrics |
| Responsive decisions | Available window width / size classes | Available window width / size classes | Size classes / available width |
| Figma handoff | Specify logical spacing and reusable type tokens | 1× reference dimensions map to dp values | 1× reference dimensions map to point values |
✓
Designer takeaway: Design a consistent typography scale (for example, body 16 and heading 24), specify spacing separately, and define responsive breakpoints when layouts must change. Test with larger accessibility text; do not assume more device pixels mean bigger fonts. Android and iOS can still look slightly different because font rendering and metrics vary.