Flutter Splash Screens vs Native Android Startup Screens

The Problem

A client wanted a highly customized, complex, animated Flutter-style splash screen to play the moment the user tapped the app icon. They wanted their branding to animate immediately, replacing the “boring” default app launch experience.

Context

When an Android application launches, there is an unavoidable window of time where the OS loads the app process into memory. During this time, Android displays a system-controlled launch screen. With the introduction of Android 12, Google enforced the SplashScreen API, standardizing this experience to show the app icon and a background color.

Flutter operates inside an Android Activity. The Flutter engine must initialize, load the Dart isolate, and render the first frame. This takes time.

What I Tried

The client wanted the animation to start instantly. I initially tried putting the animation directly into the first Flutter widget loaded by runApp().

What Failed

This resulted in a jarring experience:

1. User taps app.
2. System shows Android 12 static splash screen (icon + background).
3. System splash disappears.
4. White flash (briefly, as Flutter attaches).
5. Flutter animated splash screen begins.

It looked like two separate splash screens playing back-to-back.

What Worked & Technical Explanation

The actual limitation is that the system-controlled Android launch splash occurs before the Flutter UI is ready, especially under Android 12+ splash-screen rules. A Flutter animation can begin after the Flutter engine/UI becomes available, but it does not replace the system launch sequence in the same way.

The correct approach was a hybrid hand-off:

1. Configure the native Android 12 SplashScreen via styles.xml to match the exact background color and static logo of the first frame of the Flutter animation.
2. Use the flutter_native_splash package to hold the native splash screen up until Flutter is fully rendered.
3. Once Flutter renders its first frame, immediately begin the complex Flutter animation from the exact state the native splash left off.

<!-- android/app/src/main/res/values-v31/styles.xml -->
<style name="LaunchTheme" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/brand_background</item>
    <item name="windowSplashScreenAnimatedIcon">@drawable/launch_icon</item>
    <item name="postSplashScreenTheme">@style/NormalTheme</item>
</style>

Lessons Learned

You cannot fight the OS. The Android lifecycle dictates what happens before your application code runs. Understanding the boundaries between native Android processes and the Flutter engine is critical for smooth UX.

What I Would Do Differently

I will clarify the distinction between “OS Launch Screen” and “App Onboarding Animation” to clients early on. Managing expectations around what happens in the first 500ms of an app’s lifecycle prevents impossible requests later.