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.

• ID: splash-screen-duration
• Severity: medium
• What to look for: Check the splash screen implementation in app.json for any delay/timeout configuration, or in native code for how long the splash screen displays before the app UI becomes interactive. Look for excessive delays in ios/[AppName]/LaunchScreen.storyboard or android/app/src/main/res/drawable/launch_screen.xml. The splash screen should appear only during app initialization (typically <1-2 seconds on modern devices).
• Pass criteria: Splash screen displays only during cold start and dismisses within 3 seconds as the app UI becomes interactive. Count all hardcoded delays (setTimeout, sleep, delay) in the splash screen flow — no more than 0 artificial delays should exist. The splash screen lifecycle must be controlled by app readiness, not timers.
• Fail criteria: Splash screen persists for longer than 3 seconds, or there is an artificial delay exceeding 500ms added that extends the splash display unnecessarily.
• Skip (N/A) when: Never — excessive splash screen duration creates poor user experience and stores may reject apps with slow startup times.
• Cross-reference: The Mobile Offline & Storage audit (mobile-offline-storage) checks state restoration on launch, which directly affects splash screen duration.
• Detail on fail: Specify the issue. Example: "Splash screen includes a 5-second hardcoded delay before showing app UI" or "App takes >3 seconds to initialize, splash screen persists for entire duration"
• Remediation: Fast app startup improves user experience and store approval odds. Optimize splash screen display:
  1. Ensure splash screen displays only during app initialization, not artificially extended
  2. In app.json, do NOT add delays:

     "splash": {
       "image": "./assets/splash.png",
       "resizeMode": "contain",
       "backgroundColor": "#ffffff"
     }
     

  3. Remove any hardcoded delays in native code (e.g., setTimeout, sleep())
  4. Move heavy initialization tasks (API calls, database loading) off the critical path:
     • Show minimal UI first
     • Load data in background
     • Update UI as data arrives
  5. Test startup time on real devices — emulators may be slower
  6. Use performance profiling tools to identify bottlenecks:
     • iOS: Xcode Instruments
     • Android: Android Profiler