All in-app links, buttons, and navigation paths lead to real content

Dead-end screens are a leading cause of App Store rejection under Apple's guideline 2.1 (completeness). Reviewers systematically navigate every registered tab and screen — a blank render or immediate crash on any reachable route results in an automatic reject. ISO 25010:2011 functional-completeness defines this failure directly: functionality that exists in the navigator but cannot be used provides zero functional value and destroys reviewer trust, putting the entire binary at risk regardless of how polished the rest of the app is.

Audit every screen registered in your navigator before submission. Remove or replace any that render null or an empty <View />.

// app/(tabs)/settings.tsx — replace null renders with real content
export default function SettingsScreen() {
  // Was: return null;
  return (
    <View style={styles.container}>
      <Text>Settings coming in v2</Text>
    </View>
  );
}

For screens not ready for launch, remove them from the navigator file entirely rather than leaving them registered. A tab that doesn't exist beats a tab that crashes.

• ID: all-links-functional

• Severity: critical

• What to look for: Count all relevant instances and enumerate each. Examine the navigation structure (root stack navigator, tab navigator, drawer navigator, or Expo Router file-system layout). Look for: screens registered in the navigator that render null or an empty <View />; navigation links (navigation.navigate('ScreenName')) pointing to screens that throw errors or show blank content; tab bar items pointing to placeholder screens; deep link handlers that resolve to empty screens. In Flutter, check MaterialApp routes or GoRouter for routes with empty builders. In Swift/Kotlin, check UINavigationController push targets and NavHost destinations.

• Pass criteria: All screens reachable from the main navigation have meaningful content. At least 1 implementation must be verified. No dead-end routes that render empty or crash immediately. A partial or placeholder implementation does not count as pass.

• Fail criteria: Any navigable screen (reachable without special credentials or edge cases) that renders blank, throws an exception, or shows placeholder copy.

• Skip (N/A) when: Never — every registered route must have real content.

• Detail on fail: "SettingsScreen is registered in tab navigator but renders null — navigating to it shows a blank screen" or "'Help' tab navigates to HelpScreen which immediately throws 'Cannot read property of undefined'"

• Remediation: Reviewers systematically explore every tab and navigable screen.

  1. Audit your navigator file and list every registered screen
  2. Verify each screen has a non-trivial render (not return null, not return <View />)
  3. For screens not ready for launch, either remove them from the navigator entirely or implement a proper "coming soon" placeholder that you first verify won't cause rejection (a single informational screen with no dead links is acceptable — a blank screen is not)
  4. Test by navigating to every screen in a release build on a physical device

  Review the configuration in src/ or app/ directory for implementation patterns.