Users say the app takes two or three seconds before the home screen appears—should we just put a splash screen over it?

First distinguish cold start, warm start, and hot start

Conclusion first: when an app opens to a white screen and takes two or three seconds before the home screen appears, it is usually not because the splash screen is missing, but because main-thread initialization is packed too full—analytics, push, maps, and logging initialize synchronously during startup, and first-screen APIs wait in serial. Based on 2026 mobile delivery experience, the acceptable cold start to first frame range on mid-range devices is commonly 1.5–2.5 seconds. Beyond that range, the cause can usually be found in initialization order and first-screen data, rather than by replacing a splash image first.

What users call “opens to a white screen” corresponds in engineering to at least three states, and mixing them together makes the root cause hard to find. Cold start means the process was killed and is recreated; the system must allocate the process, load code, run the app entry point, and then render the first frame. Warm start means the process is still alive but the page was reclaimed, saving part of the loading. Hot start means switching back from the background, which usually should not have noticeable waiting. User reports of “waiting several seconds” mostly happen in cold start, while test colleagues repeatedly switch to the background on their own flagship phones and mostly see hot start—this is a common reason the two sides disagree.

• Cold start: process recreation; time includes system overhead, app entry, and first-screen rendering.
• Warm start: process alive, page reclaimed; time is mainly first-screen reconstruction.
• Hot start: switching back from background; normal experience should finish within a few hundred milliseconds.
• Measurement rule: take the median of three consecutive cold starts on the same device to avoid misjudging from a single fluctuation.

Find where the white screen is stuck: a four-phase cold-start breakdown method

Startup time is a chain. Looking only at total duration has limited value; it must be split into four phases with separate timing to decide which phase to change. The reason for this split is that each phase has a different owner and change cost. Discussing optimization without splitting them often means changing the higher-cost phase first.

1. System and window phase: from tapping the icon to before the app entry executes. Affected by package size and hardening approach; commonly 300–600 ms. If clearly longer, check package size first.
2. Initialization phase: from app entry to first-screen page creation. Analytics, push, maps, and similar SDKs are often initialized synchronously. This phase is the main source of the white screen; an experience range of 400–800 ms is controllable.
3. Data phase: from first-screen API request to response. When APIs are serial and wait on the main thread, over 1 second is common; parallel requests plus cache fallback can usually reduce it to a few hundred milliseconds.
4. Rendering phase: from data to visible first frame. Affected by layout depth and image decoding; deeply nested lists are a common drag.

Only after splitting phases can trade-offs be discussed: if time is concentrated in the initialization phase, prioritize SDK lazy loading and deferred initialization; if concentrated in the data phase, prioritize caching and skeleton screens; if none of the four phases is long but total time is still high, look back at whether hardening or multiple processes are slowing it down. Changing code without phase timing data has a high probability of rework.

Cost comparison of three optimization approaches

The same white screen can be handled in three directions: “looks fast,” “actually fast,” and “faster next time.” Their investment and risk are not the same. A common approach is to do the second one first, and use the first only as a fallback.

• Approach A: splash screen fallback—hold a fixed splash image for 1–2 seconds before entering the home screen. Small change and intuitive effect, but it does not shorten real time, and splash ad slots involve platform review requirements; if used poorly, it may be judged as deliberately extending startup.
• Approach B: initialization breakdown and deferral—move SDKs not required for the first screen to initialize after the first frame, and issue first-screen APIs in parallel with cache fallback. Medium change scope; depending on the number of integrations, the experience range is commonly 3–10 working days, with relatively stable results.
• Approach C: preloading and warm-up—server-side prefetch, local cache, and process warm-up. Benefits depend on whether the home screen structure is stable and whether return visits are frequent; for one-off utility apps, the benefit is limited.

The comparison dimensions can be simplified to three: change scope, actual impact on first-frame time, and whether there are compliance or experience side effects. Doing only A and not B means users will still feel it is slow the second time they open the app. A with B, then deciding whether to add C based on return visit rate, is a common 2026 combination.

Common rework points in delivery

A common situation in projects is this: the timeline has been compressed to two or three months, while the first screen is required to include a map, a recommendation feed, and a campaign pop-up. The client wants “content as soon as it opens,” so developers put all initialization into the entry point. The constraints are a tight timeline and unfinished assets and APIs. A common approach is to use a splash image to cover the visuals first and design APIs to be degradable. The cost is a slower first-version cold start. After APIs stabilize, going back to split initialization often requires changing the first-screen data structure and caching strategy as well—a typical second round of rework. A less troublesome order is to list the SDK checklist and first-screen API checklist as verification items before development, and defer non-essential ones until after the first frame.

• Waiting on network requests on the main thread: the first frame is held hostage by API response time, and on a weak network it becomes a long white screen.
• Writing logs, reporting, and upgrading the database during startup: each item is small, but combined they often exceed 500 ms.
• First screen depends on multiple serial APIs: if any API is slow, the overall wait is amplified.
• Splash screen uses an animated or remote image: iOS splash screens only accept static assets; a remote image shows white first and then the image.
• Testing only flagship phones but not mid-range and low-end phones: the same version commonly differs by more than 1x in startup time across device models, so acceptance criteria should state the device range clearly.

Applicable scenarios and boundaries

Scenarios suitable for investing in startup optimization: apps with high DAU, users opening them multiple times a day, and a first screen that is a feed or dashboard; also versions that app store review has asked to revise because of splash ads or startup redirects. For these apps, controlling cold start to around 2 seconds on mid-range devices (experience range) commonly reduces “opens too slowly” feedback noticeably.

There are also cases where a dedicated project is not necessary: internal employee tools that are opened once or twice a day; and first screens that are themselves heavy scenarios such as maps, cameras, or AR, where instant open is not realistic in engineering. In those cases, giving loading feedback is more reasonable than compressing startup time. The boundary is clear—the benefit of startup optimization depends on opening frequency; for low-frequency apps, spending budget on feature completeness is more worthwhile.

FAQ

What cold start to first frame time is acceptable?

There is no unified standard. Based on 2026 delivery experience, the common acceptable range on mid-range devices is 1.5–2.5 seconds, and on low-end devices it can be relaxed to around 3 seconds. The key is to compare with similar products first before setting the acceptance line.

Does adding a splash screen mean startup speed is optimized?

No. A splash screen only replaces the white screen with a brand image; real time is unchanged. It is an experience fallback. To judge whether optimization happened, look at whether phase timing data has decreased.

If the first-screen API is slow, can we put up a skeleton screen first?

Yes, but a skeleton screen only improves the perception of waiting. If the API itself takes more than 1 second, a common approach is parallel requests plus local cache, showing the previous data first and then refreshing.

Can all third-party SDKs be initialized with delay?

Most analytics, push, and sharing SDKs can be deferred until after the first frame; those involving crash capture and login state usually need to complete near the entry point. Follow each platform’s official documentation initialization requirements.

How should startup time be accepted to avoid disputes?

Agree on device tiers, the number of cold starts, and the sampling method (commonly the median of three runs), and list splash screen hold time separately to avoid counting artificial delay as real time.

If you are ready to start, do one thing first: add phased startup timing to the current version, run three consecutive cold starts on the same mid-range device, see which phase the time is concentrated in, and then decide whether to change initialization order or add caching. This suits apps with high DAU and high opening frequency. For internal tools or heavy first screens, making loading feedback clear is more worthwhile than compressing those few hundred milliseconds. API and SDK checklists can be verified before development. Following enterprise project delivery habits, Xiyue Company generally includes these two items in the startup-specific checklist.