Splash screen does not persist for excessive duration

An artificially extended splash screen — one that holds for a hardcoded timer rather than dismissing when the app is ready — violates Apple's HIG and Android's launch screen guidance and is flagged during App Store review as an indication of poor app quality. Beyond rejection risk, every extra second of splash increases abandonment: research on mobile startup performance shows user drop-off begins at 2 seconds and accelerates sharply past 3. A 5-second hardcoded delay loses a measurable percentage of first-run users before they ever see the app. ISO 25010:2011 performance-efficiency applies here directly — launch time is a contractual quality attribute, not a cosmetic preference.

Remove all hardcoded setTimeout or sleep calls from the splash lifecycle and tie dismissal to actual app readiness. Heavy initialization (API prefetch, database hydration) must move off the critical path.

// Wrong — artificial delay
await new Promise(resolve => setTimeout(resolve, 5000));

// Correct — dismiss when ready
await Promise.all([authCheck(), configLoad()]);
SplashScreen.hideAsync();

For Expo, call SplashScreen.preventAutoHideAsync() at module load and SplashScreen.hideAsync() only after fonts and critical data are loaded. Profile cold-start time on a real mid-range device (not a simulator) using Xcode Instruments or Android Profiler before submitting.