Flutter splash screen setup guide

Choose a maintainable setup

A package such as flutter_native_splash can generate platform resources from project configuration. Check its current compatibility, documentation, and generated-file behavior before adding it to an existing app.

Configure native assets

Set the background and logo assets in the package configuration, then run its generation step as documented. Keep source images separate from generated output so a brand change can be applied consistently.

Account for Android 12

Android 12 uses a system splash screen with its own layout and icon behavior. Use the package’s current Android 12 settings and verify the result on the minimum and target Android versions.

Support the intended theme

If the app supports dark appearance, configure the corresponding launch colors and assets where the platform allows it. Preview the transition into Flutter to catch a bright flash or a mismatched logo.

Test the first-frame handoff

Launch from a cold start and confirm the native screen disappears when the first useful Flutter frame is ready. A splash should not hide a blank or stalled app by remaining visible for a fixed delay.

Keep generated output reproducible

Store the package configuration and source artwork in version control, then run the generator as part of the documented asset update process. Review the generated iOS and Android changes instead of editing them by hand and losing the edits on the next generation.

Use the package’s current settings for Android 12 and theme variants. A package upgrade can change generated resources, so build both platform targets after upgrading and inspect the resulting launch screens.

Verify the transition to Flutter

Compare the native background with the first Flutter frame in light and dark themes. If the initial Flutter page loads data, show its loading state after the native splash is gone rather than holding the branded screen until a network request completes.

Test release builds as well as debug builds. Startup timing and asset packaging can differ, and a debug-only launch check may miss a flash or missing image in the shipped bundle.

Regenerate after configuration changes

When changing the logo, background, or dark-mode values, rerun the documented generator and inspect the resulting native project changes. Keep the package configuration committed so CI and other developers can recreate the assets.

If the app uses flavors or multiple bundle identifiers, verify that each target receives the intended launch resources. A correct default configuration does not guarantee every flavor is using it.

Test cold starts on supported platforms

Run the release build on iOS and Android, including an Android 12-or-later device. Check the icon treatment, background color, and exact moment the Flutter first frame replaces the native screen.

If startup depends on remote configuration, show the app shell and a clear loading state when possible. A slow service should not turn into a branded screen that appears stuck.

A release checklist for Flutter

Confirm the configuration is committed, generated resources are reproducible, and every flavor points to the right icon and background. Build both platform targets after changing the generator or its version.

Test cold starts in release mode on the oldest supported Android and iOS versions. Look for an unexpected blank frame, outdated logo, wrong dark-theme background, or a native-to-Flutter transition that waits on a network call.