Guide

Splash screen sizes for iOS and Android

October 17, 2026 · 4 min read

A splash screen must adapt to many display shapes and system launch behaviors. Build around a flexible layout and the current platform APIs rather than exporting one bitmap for a single phone model.

Use the platform launch model

iOS launch screens and Android launch screens are configured differently, and supported APIs can change with OS releases. Check the current native project guidance for the platforms and versions you support.

Protect the central mark

Keep the logo or key symbol within a safe central area that tolerates status bars, cutouts, and varying screen ratios. Test portrait and landscape only where your app supports both.

Plan color and theme variants

Choose background and foreground colors that work with system appearance and the first screen shown after launch. Avoid a sudden visual flash between the splash and the app interface.

Test on several screen sizes

Review the result on devices or simulators with different aspect ratios and insets. Look for clipped marks, unexpected stretching, and content that appears too close to system UI.

Keep the handoff brief

A launch screen is not a place to add a marketing sequence or delay the app artificially. Let it transition to the actual interface as soon as the app is ready.

Why one universal pixel table is misleading

Modern launch screens are generally composed or drawn using platform layout rules and scaled assets, not selected from a hand-maintained bitmap for every phone resolution. Safe areas, aspect ratios, and system launch APIs matter more than a single list of pixel widths.

On Android 12 and later, the system splash screen has a defined icon and background treatment. iOS launch screens use a launch storyboard or supported project configuration; follow the current native documentation for the app’s deployment target.

A practical layout test

Preview a small central logo on the narrowest and widest supported screens, with and without a display cutout. Verify the background reaches every edge, the status area looks intentional, and the first app frame uses a compatible color.

Test a cold launch, a warm launch, and a return from background. The operating system may not show the launch screen in every case, so check the transitions that actually occur rather than designing a long branded sequence.

What to check on iOS and Android

On iOS, verify the launch storyboard or project configuration against current launch-screen guidance and test its layout on devices with different insets. On Android 12 and later, inspect the system splash icon and background treatment rather than assuming a full-screen custom bitmap will be shown.

The launch presentation should lead into the first app view without a color flash or sudden logo jump. Match the background and mark placement across both native and application-rendered states.

Do not use marketing artwork as a launch screen

A launch screen is a short transition into the app, not another store listing. Avoid promotional captions, offers, or controls that imply a person can interact with the static launch surface.

Keep the visual simple enough to render quickly and consistently. If a custom image is not needed, a solid background and a centered mark are often easier to maintain across screen sizes.

A compact device test matrix

Include one narrow phone, one device with a prominent cutout, and a tablet if the app supports tablets. Record orientation, system appearance, and launch outcome so each test checks a meaningful layout difference.

Look for a clipped logo, stretched background, inconsistent status area, or color flash when the first app screen appears. Fix the layout at its source instead of adding a device-specific bitmap for every resolution.

Prepare related store artwork

Use the device canvases to prepare listing screenshots for the same supported screens.

Open App Snaps

More guides

All guides