There are tiny phones, huge screens, notches, status bars and tablets — and your layout has to look good on all of them. The secret isn't designing in pixels, but thinking in logical units, respecting safe areas and letting the layout adapt on its own. It is one of the first topics where a junior stumbles and one of the first that interviewers ask about.

Physical pixel vs logical pixel

Two phones can have the same physical size but very different pixel counts: one has a "normal" screen, the other a "retina/high-density" one with twice the pixels in the same space. If you positioned everything in physical pixels, a 100px button would be gigantic on one screen and tiny on the other.

That's why platforms use logical units: dp (density-independent pixels, Android) and pt (points, iOS). You say "I want 16 units of space" and the system multiplies by the screen density to arrive at the actual physical pixels.

The analogy: dp/pt are like the "centimeters" of the mobile world — a measure that means the same apparent size on any screen. Physical pixels are like counting grains of sand, which vary from beach to beach.

Why measure in dp/pt

Measuring in dp, an 8 dp spacing looks the same on the intern's phone and on a flagship. The system handles the conversion. Interviewers often ask you to explain the difference between px and dp and why you should never hardcode physical pixels — the expected answer is exactly this density independence.

The hardcoded pixels trap

// BAD: assumes a fixed width in pixels
image.width = 320      // overflows on small screens

// GOOD: relative to the available space
image.width = "100%"   // or use constraints/flex
image.height = aspect(16, 9)

Hardcoding a width of 320 breaks on a 4-inch device and wastes space on a tablet. Day to day, this bug shows up as clipped text, a button off the screen or a layout that "overflows" on certain models.

Safe areas: notch, status bar and home indicator

Not all of the rectangular screen is usable. At the top there's the status bar (clock, battery) and the notch/island; at the bottom, the gesture bar or home indicator. The safe area is the region where your content isn't hidden behind these elements.

+---------------------+
| [status bar / notch]|  <- don't put buttons here
|                     |
|   SAFE AREA         |
|   (your content)    |
|                     |
| [home indicator]    |  <- nor here
+---------------------+

Ignoring the safe area makes the title disappear behind the notch or the action button end up under the gesture bar, where the user can't tap it properly.

From small phones to tablets

Adapting isn't just stretching. Use constraints (iOS Auto Layout), flexbox (React Native) or flexible widgets (Flutter, ConstraintLayout on Android) so elements rearrange according to the available space. On tablets, it's common to change the layout itself: a list that becomes list + detail side by side (master-detail).

• Proportions, not fixed sizes: "take up half the width" instead of "240 dp".
• Breakpoints: switch from a single-column layout to two columns above a certain width.
• Text that scales: respect the font size increased by the user (accessibility).

You don't design for a device; you design adaptation rules. Think "how does this behave when the space shrinks or doubles", not "how many pixels are here".

Conclusion

Measuring in dp/pt, respecting safe areas and using constraints/flex instead of hardcoded pixels is the tripod of responsive mobile layout. Whoever internalizes the difference between physical and logical pixels avoids the most frequent visual bugs and delivers screens that work from the smallest phone to the largest tablet.