Add a Screen to Expo Router by Creating One File
Skip manual navigator registration: in Expo’s managed workflow, a new file under app/ becomes a route—here is how to add it, wire it into a tab layout, and verify it.
14 Oct 2025, 18:42 UTC

You should not need to edit a navigator to add a screen
You inherit an Expo project that uses Expo Router. The existing screens are registered inside a tab navigator component, and adding a new screen means editing that component, importing the screen, and listing it alongside the others. You want to add a Settings screen without touching Xcode, Android Gradle files, or a central navigation registry.
The useful takeaway: in Expo’s managed workflow, Expo Router treats the app/ directory as the navigation source of truth. You add a navigable screen by creating a file, then verify it through Metro rather than by rebuilding native code.
How file-based routing works in the managed workflow
Expo Router is a file-system router for React Native. Files placed under app/ are mapped to routes automatically. A folder in parentheses, such as (tabs), is a route group: it organizes files without adding a URL segment. A file named _layout.tsx is a layout file; it wraps child routes with shared UI, such as a tab bar, and preserves state while the user moves between screens.
Because this runs in the managed workflow, Expo config plugins—Expo’s mechanism for modifying native project files during builds—generate the native navigation setup. You do not edit Xcode or Android Studio project files for standard navigation, and you do not run expo prebuild just to add a screen.
Worked example: add a Settings tab
Assumptions: the project uses Expo SDK 50 or newer, expo-router v3 or newer, and already has an app/(tabs) group with a tab layout. Check your versions before starting:
grep expo-router package.json
grep sdkVersion app.json
Run these in the project root with normal user permissions. No sudo is required. Compare the expo-router version against your Expo SDK version; major mismatches can change file conventions.
Step 1: create the route file
Create app/(tabs)/settings.tsx. If the directory already exists, this is safe; if settings.tsx already exists, back it up first because this command overwrites it.
mkdir -p app/(tabs)
cat > app/(tabs)/settings.tsx <<'EOF'
import { View, Text, StyleSheet } from 'react-native';
export default function SettingsScreen() {
return (
Settings
);
}
const styles = StyleSheet.create({
container: { flex: 1, padding: 16 },
});
EOF
Run this in the project root. The file creates the /settings route. No native code is generated by this step alone.
Step 2: expose the route in the tab layout
Open app/(tabs)/_layout.tsx and add a Tabs.Screen entry inside <Tabs> so the screen appears in the tab bar:
<Tabs.Screen href='/settings' options={{ title: 'Settings' }} />
Placement in the layout controls tab order. Save the file.
Step 3: verify the route
Start the development server:
npx expo start
Run this in the project root. Ensure port 8081 is free; Metro will fail if another process holds it. Inspect the terminal output for the generated route list and confirm /settings appears. Then open the app on an emulator or device and tap the Settings tab.
If the tab does not appear, stop Metro, clear the cache with npx expo start --clear, and retry. Metro caching can make a newly created file invisible until the bundler restarts.
Limitations to keep in mind
- Structure is navigation. Renaming
app/(tabs)/settings.tsxtoapp/(tabs)/account.tsxchanges the route from/settingsto/account. Any links or deep links pointing to the old path break. - Version sensitivity. Expo Router conventions change between major versions. A folder or layout pattern that works in one release may behave differently after an SDK upgrade.
- Config plugin interactions. Custom native modules often bring their own config plugins. When upgrading Expo SDK, verify that those plugins remain compatible with Expo Router’s plugin in
app.json. - Refactoring risk. Moving route files around is riskier than editing an explicit navigation object because the navigation graph is inferred from disk, not declared in code.
Practical check and rollback
After adding or renaming any route file, run npx expo start, check the Metro route list for the expected path, and open the corresponding screen in the app. If you use deep links, verify the scheme and Expo Router plugin configuration in app.json still match the new route.
Because adding a file changes project state, rollback is straightforward: delete app/(tabs)/settings.tsx, remove its Tabs.Screen entry from app/(tabs)/_layout.tsx, and restart Metro.
Closing
Before your next screen, confirm the SDK and expo-router versions align, create the file under app/, add it to the relevant layout if it needs shared chrome, and confirm the route appears in Metro. Treat a file rename as a route change, not just a file move.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.