App launches without crashing on supported OS versions
Why it matters
A crash on launch is the highest-severity rejection — the reviewer cannot evaluate any other part of the app. Apple tests on multiple OS versions and device types; an unhandled exception in root initialization code (unguarded useEffect, top-level JSON.parse, missing optional chaining) will crash on at least one configuration. CWE-390 (detection of error condition without action) and ISO 25010:2011 fault-tolerance both classify this as a fundamental reliability failure. One uncaught rejection in a startup async chain means the entire binary is rejected.
Severity rationale
Critical because a launch crash makes the app completely unreviable — no functionality can be evaluated and rejection is immediate.
Remediation
Add a root error boundary in App.tsx and wrap all startup async operations in try/catch.
// App.tsx
import { ErrorBoundary } from 'react-error-boundary';
export default function App() {
return (
<ErrorBoundary FallbackComponent={({ error }) => (
<View><Text>Something went wrong. Please restart the app.</Text></View>
)}>
<NavigationContainer>
<RootNavigator />
</NavigationContainer>
</ErrorBoundary>
);
}
For startup data fetching, always add a catch block: useEffect(() => { fetchConfig().catch(console.error); }, []). Test launch on the minimum supported OS version using Simulator (iOS) or AVD (Android) before every submission.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the App Store Review Blockers Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-390 — Detection of Error Condition Without Action
- iso-25010:2011 · fault-tolerance — Fault Tolerance (ISO 25010 Reliability)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from app-store-review-blockers·automated