The Safe Area Problem: Why Your App's Buttons Hide Behind the Notch and Home Indicator on Other Phones

You finish a new screen, run it on your own phone, and it looks perfect. Then a tester opens the app on a different device and the page title is half-hidden under the camera cutout, and the main button sits right on top of the home indicator bar. Nothing is technically broken, yet the app looks careless. Dolfy.ai sees this pattern constantly with founders who build on one device and ship to thousands of different ones.

This is the safe area problem, and it is one of the quickest ways to make a good app feel unfinished.

Key Takeaways

• A safe area is the part of the screen guaranteed not to be covered by hardware or system UI such as the notch, the Dynamic Island, the status bar, or the home indicator.
• Screens that look fine on one phone often break on another, because insets (the reserved edge distances) differ by device and by orientation.
• Hard-coded top and bottom padding is the root cause of most safe area bugs; read the real insets from the device instead.
• Treat insets as design tokens (named, reusable values) so every screen handles them the same way.
• Always test on at least three screen shapes before shipping: a small older phone, a notched phone, and a large phone in landscape.

What exactly is the safe area problem in a mobile app?

The safe area problem is when your app's content draws underneath parts of the screen that the device reserves for itself. Modern phones have rounded corners, camera cutouts, status bars with the clock and battery, and a thin home indicator bar at the bottom. Content placed under any of these is clipped, covered, or hard to tap.

The cause is almost always the same. A developer picks a number, such as 44 pixels of top padding, because it looks right on their test phone. That number is wrong for a phone with a taller cutout and wrong again for a device with no cutout at all. A layout that hard-codes the edges only works on the one device it was tuned for.

Real devices vary more than most people expect. The status bar alone can be roughly 20 points tall on an older iPhone and 47 to 59 points on newer models with a Dynamic Island. Android adds gesture navigation bars, three-button bars, and punch-hole cameras in different corners. Foldables add another set of shapes.

Why do safe area bugs slip past you until launch?

They slip through because you usually test on one or two devices, and both of them cooperate. If your own phone has a standard notch, you will never see what happens on a phone without one, or on a tablet, or in landscape mode, where the notch moves to the side and the left and right edges need protecting too.

Simulators help, but only if you actually switch between device types. Many solo founders run a single simulator for weeks. The bug then surfaces as a one-star review that says "the button is cut off on my phone," with no screenshot and no way to reproduce it.

There is also a timing trap. Safe area problems are cheap to fix on day one and expensive once forty screens each carry their own padding values. Finding it at launch usually means editing every screen by hand.

How do you read the real safe area values instead of guessing?

You ask the operating system for them. In React Native, the standard approach is the react-native-safe-area-context library, which exposes a hook that returns the exact top, bottom, left, and right insets for the current device. Expo projects include it by default, so there is nothing extra to install.

The idea is simple. Instead of writing paddingTop: 44, you write paddingTop: insets.top. On a phone with a tall cutout the value is larger, and on a phone with no cutout it is small. The layout adapts without you knowing the device in advance.

Two details save a lot of trouble. First, apply insets at the screen level or in shared layout components, not inside small reusable pieces like buttons. Second, remember that the bottom inset is often 0 on older phones, so combine it with your normal padding rather than replacing it: use a minimum spacing and add the inset on top.

Which parts of a screen need safe area handling?

Four areas need deliberate handling, and each fails in its own way.

The header. Titles and back buttons need the top inset so they never sit under the clock or camera. A common mistake is letting a scrolling header slide up behind the status bar, which makes the back button untappable.

The bottom bar and primary buttons. A tab bar or a full-width "Continue" button must clear the home indicator. If it does not, the button is both visually crowded and hard to press, because the system reserves that strip for its own swipe gesture.

The sides in landscape. When a phone rotates, the cutout can land on the left or right edge. Text that is fine in portrait can be cut off in landscape if you only handled top and bottom.

Full-bleed content. Photos and videos are allowed to extend under the status bar for a more immersive look, but the text and controls on top of them still need to stay inside the safe area. Decide per element: background can bleed, interaction cannot.

How do design tokens make safe areas consistent?

A design token is a named, reusable design value, such as a spacing size or a color, that every screen references instead of hard-coding a number. Treating safe area handling as part of your token system means the rule lives in one place.

For example, you might define a screen-padding token of 16 points for the sides and a rule that the bottom edge always equals the larger of 16 points or the device's bottom inset plus 8 points. Every screen then uses the same shared layout wrapper, and a fix to the rule fixes every screen at once.

Without tokens, each screen gets slightly different padding, and you end up with the cramped-here, empty-there feeling that makes an app look unpolished. A design system (a shared set of rules and components for how your app looks) exists to prevent exactly that drift. If you only build one reusable piece early, make it a screen wrapper that applies insets and standard padding.

How does Dolfy approach this in its design workflow?

Dolfy walks you through a five-step Design OS methodology: Product Definition, Data Model, Design Foundation, Screen Design, and Export. The safe area question belongs to the Design Foundation step, where you set up the design-token system that every later screen inherits. Settling spacing and layout rules there, before you design screens, is the same principle as the wrapper above: decide once, apply everywhere.

Because Dolfy exports production-ready React Native components styled with Tailwind and typed with TypeScript, the output is built to sit inside a normal Expo project, where the safe area library is already available. You can also check screens in the Expo Go or Web Preview before committing to them, which gives you an early look at how a layout behaves, though you should still confirm on real hardware for the notch and home indicator, since a browser preview cannot reproduce those exactly.

What is a practical safe area checklist before you ship?

Run this short list on every release. It takes about 15 minutes and catches the large majority of these bugs.

1. Test three shapes. One small older phone with no cutout, one phone with a notch or Dynamic Island, and one large phone. Use real devices if you can borrow them.
2. Rotate each device. Check landscape for side clipping, even if you plan to lock to portrait; some users will still try it.
3. Search for hard-coded edges. Look through your code for fixed top or bottom padding values such as 20, 44, or 34, and replace them with inset values.
4. Tap every bottom control. Confirm the primary button, tab bar, and any floating button are comfortably tappable above the home indicator.
5. Check keyboard and sheet screens. Inputs and slide-up panels interact with the bottom inset, so they are common places for a second bug to hide.
6. Test with large text. Increase the system font size and confirm headers still clear the status bar.

Frequently Asked Questions

Do I need to handle the safe area if I only target iPhones?

Yes. iPhones alone have several different status bar heights and bottom indicator sizes across models, and older devices have none of the cutout at all. Handling insets properly makes one layout work across all of them.

Is SafeAreaView enough, or should I read the insets myself?

A safe area wrapper component is a good starting point and covers the simple cases. Reading the inset values directly gives you finer control, for example when you want a header background to bleed to the top edge while keeping its text inside the safe area.

Does this apply to Flutter and native apps too?

The concept is identical everywhere. Flutter has SafeArea, SwiftUI has safe area insets, and Android has window insets. Only the API names change; the mistake of hard-coding edge values is the same on every platform.

How many devices do I really need to test on?

Three screen shapes cover most problems: a small phone without a cutout, a phone with a notch or Dynamic Island, and a large phone, ideally including one landscape check. Beyond that, emulators fill the gaps.

Make every screen look finished, not just the one on your phone

Safe area bugs are never dramatic. They are small, quiet signals that a product was tested on one device and shipped to many. The fix is also small: read the real insets, put them in one shared wrapper, and test across a few screen shapes. If you want a design foundation where spacing and layout rules are settled before you build a single screen, you can start with Dolfy and carry those decisions all the way into exported React Native code.