Fixing Safe Area & Notch Display Issues in Rork Apps

There's a moment when you first run a Rork-generated prototype on a real iPhone 15 Pro and something feels off. The header you placed at the top is cutting into the notch. The tab bar at the bottom is being eaten by the home indicator. Everything looked fine in Rork's web preview — but the moment you shipped to TestFlight, the layout fell apart. The first time I pushed a Rork app to TestFlight, I spent a solid half hour staring at this exact problem.

This isn't a Rork-specific bug. It's a layout issue that hits every React Native / Expo app when the developer doesn't account for safe areas, and Rork's generated code tends to include only minimal safe area handling — which makes the problem surface quickly. In this article I'll walk through why the problem shows up, and the exact patterns you can drop into your Rork code to fix it.

Why Rork's preview doesn't catch this

Rork's web preview renders the app into a flat rectangular frame. There's no notch, no Dynamic Island, no home indicator, no Android gesture bar. Content that sits flush against the edge of the preview looks clean — but the moment it hits a real device, it collides with system UI regions like these:

• The iPhone X-and-later notch / Dynamic Island (roughly 44–59pt at the top)
• The iPhone home indicator (about 34pt at the bottom)
• Android's status bar (about 24dp at the top)
• Android's navigation bar (about 48dp, though gesture nav differs)

React Native gives you two tools to keep content out of these regions: SafeAreaView and useSafeAreaInsets. Rork's generated code often has one but not the other, or places them in a nesting order that silently breaks them.

The minimal fix: wrap in SafeAreaView

The simplest fix is wrapping the screen in SafeAreaView. For a plain list screen with no header or footer, that's all you need.

import { SafeAreaView } from "react-native-safe-area-context";
import { ScrollView, View, Text, StyleSheet } from "react-native";
 
export default function ArticleList() {
  return (
    <SafeAreaView style={styles.safe} edges={["top", "bottom"]}>
      <ScrollView>
        <View style={styles.header}>
          <Text style={styles.title}>Articles</Text>
        </View>
        {/* list items */}
      </ScrollView>
    </SafeAreaView>
  );
}
 
const styles = StyleSheet.create({
  safe: { flex: 1, backgroundColor: "#fff" },
  header: { padding: 16 },
  title: { fontSize: 22, fontWeight: "700" },
});

The critical detail: import SafeAreaView from react-native-safe-area-context, not from react-native itself. The React Native built-in version is iOS-only and does nothing on Android. Expo projects ship with react-native-safe-area-context by default, so the import works out of the box.

The edges prop lets you pick which sides to apply. On screens with a custom bottom tab bar, use edges={["top"]} and handle the bottom manually — which brings us to the next pattern.

For screens with tab bars or custom headers: useSafeAreaInsets

Screens with a tab bar or a custom header can't rely on SafeAreaView alone, because the content region and the bar region need different padding math. Use useSafeAreaInsets to read the raw numbers and apply them yourself.

import { useSafeAreaInsets } from "react-native-safe-area-context";
import { View, Text, StyleSheet, TouchableOpacity } from "react-native";
 
export default function TabBarLayout({ children }: { children: React.ReactNode }) {
  const insets = useSafeAreaInsets();
 
  return (
    <View style={styles.container}>
      {/* Custom header: add notch padding */}
      <View style={[styles.header, { paddingTop: insets.top + 8 }]}>
        <Text style={styles.headerTitle}>Home</Text>
      </View>
 
      {/* Content region */}
      <View style={styles.content}>{children}</View>
 
      {/* Custom tab bar: add home indicator padding */}
      <View style={[styles.tabBar, { paddingBottom: insets.bottom + 8 }]}>
        <TouchableOpacity style={styles.tab}>
          <Text>Home</Text>
        </TouchableOpacity>
        <TouchableOpacity style={styles.tab}>
          <Text>Profile</Text>
        </TouchableOpacity>
      </View>
    </View>
  );
}
 
const styles = StyleSheet.create({
  container: { flex: 1, backgroundColor: "#fff" },
  header: {
    paddingHorizontal: 16,
    paddingBottom: 12,
    borderBottomWidth: 1,
    borderBottomColor: "#eee",
  },
  headerTitle: { fontSize: 18, fontWeight: "600" },
  content: { flex: 1 },
  tabBar: {
    flexDirection: "row",
    paddingTop: 8,
    paddingHorizontal: 16,
    borderTopWidth: 1,
    borderTopColor: "#eee",
  },
  tab: { flex: 1, alignItems: "center" },
});

Expected behaviour: on iPhone 15 Pro the header gets roughly 59pt of top padding and the tab bar gets roughly 34pt of bottom padding. On iPhone SE the top is about 20pt and the bottom drops to 0. Android gets the status bar and nav bar heights reflected automatically.

Common gotchas

SafeAreaProvider isn't wrapping your app

useSafeAreaInsets returns zeroes for everything if it isn't inside a SafeAreaProvider. Rork-generated code sometimes ships without it in _layout.tsx or App.tsx. Wrap your root like this:

// app/_layout.tsx (Expo Router) or App.tsx
import { SafeAreaProvider } from "react-native-safe-area-context";
import { Stack } from "expo-router";
 
export default function RootLayout() {
  return (
    <SafeAreaProvider>
      <Stack />
    </SafeAreaProvider>
  );
}

Background color shifts visibly at the notch

If the area outside your SafeAreaView has a different colour than the inside, you get a visible seam around the notch. When you want a header colour to bleed all the way up behind the notch, skip SafeAreaView and use a plain View as the root, then apply paddingTop: insets.top inside. The colour extends edge to edge and the layout still clears the notch.

SafeAreaView inside ScrollView

SafeAreaView is meant to be a screen-level wrapper. Putting it inside a ScrollView doesn't do what you'd expect. Put the ScrollView inside the SafeAreaView instead. If you want scroll content to extend to the bottom edge with proper spacing, the idiomatic pattern is contentContainerStyle={{ paddingBottom: insets.bottom }}.

Insets read as zero inside a modal

Inside an iOS modal (presentation: "modal"), the modal's own rounded top avoids the notch, so insets.top ends up near zero by design. The home indicator is still there though, so keep using insets.bottom for the bottom padding inside modal screens.

Testing on a real device

None of this shows up in Rork's web preview, so you have to validate on hardware or in Expo Go. The fastest loop is to export your Rork project to GitHub and open it in Expo Go.

1. Export to GitHub from the top-right of the Rork editor
2. Run npx expo start locally
3. Scan the QR code with Expo Go on your iPhone
4. Check three devices: iPhone 15 Pro, iPhone SE, and any Android device

When it looks right on a notched device and an unnotched device, you're done. Expo Go has a "Device Frame" toggle that makes it easy to flip between device profiles without leaving the preview.

This topic overlaps a lot with other Rork layout issues. If iOS and Android are diverging, the iOS vs Android behavior difference guide is worth a read. For keyboard overlapping input fields, see the keyboard avoidance fix guide. And if you're hitting responsive layout issues in general, the layout and responsive design troubleshooting guide pairs well with this one.

Open your app's top-level _layout.tsx first and check whether SafeAreaProvider is there. Adding it takes five minutes and kills more than half of these layout issues on its own. The rest you can mop up screen by screen with useSafeAreaInsets, and your Rork app will finally look as clean on real devices as it did in the preview.