Custom-developed app always shows a white screen for a second or two on launch—if users haven’t complained, should we optimize it first?

Conclusion first: When a custom-developed app shows a white screen for one or two seconds on launch, whether to optimize it first cannot be based only on a feeling that it is “slow.” A more reasonable judgment is to first use system logs to measure cold-start time and break down the path from tapping the icon to the first screen becoming visible into four segments: process creation, initialization, home page rendering, and first-screen data. If one of the four segments is clearly high, then decide whether to change code, delay initialization, add placeholders, or defer. Based on 2026 delivery experience, most launch white screens can be traced to decomposable causes at the application layer, but when low-end device hardware bottlenecks, requirements undergo major changes every week, or there is a strong dependency on synchronous security checks at launch, optimization priority should be moved down.

Startup slowness: first distinguish cold start, warm start, and hot start

When users say “it opens slowly,” they usually mean cold start. A cold start must run process creation, initialization, home page rendering, and first-screen data in full, and its time is usually several times that of a hot start. The typical experience range is 2 to 10 times, depending on how many launch tasks there are. A warm start skips part of process creation but must restore the page; a hot start is mostly foreground/background switching and is usually not the optimization focus. The boundary is: if the business requires synchronous verification of login state or locally encrypted data at launch, you cannot make everything asynchronous just for speed, or you may skip security checks.

Use the four-part breakdown to locate: from tapping the icon to the first screen becoming visible

1. Process creation and system preparation: The system allocates memory and loads basic libraries. The app cannot change much, but an abnormally bloated installation package and too many dynamic libraries can slow it down; check package size first.
2. Initialization phase: Registering SDKs, initializing databases, reading configurations. Analytics, push, maps, payment, and other SDKs often start synchronously; those that can be delayed until after the first screen should be delayed.
3. Home page rendering: Layout creation, image decoding, font loading. Too deep a hierarchy, too many rounded corners and shadows, and uncompressed large images add time; modules that do not need to be displayed on the first screen should not be rendered yet.
4. First-screen data request and fill-in: API requests, JSON parsing, database queries. APIs that can run in parallel should not be serial; you can first use local cache to render a skeleton, then wait for network fill-in.

The four-part breakdown turns “slow launch” into verifiable hypotheses. A common 2026 project delivery habit is to record at least 10 cold starts on a real device and take the median; do not look only at simulator or developer machine data. Whichever segment has the highest share should be investigated first.

Which slowness is not worth changing code for: rule out artificial and boundary factors first

• Artificial dwell time on the splash screen: For branding or ads, forcing a 2- to 3-second stop makes users perceive it as slow.
• Synchronous initialization of third-party SDKs: Push, analytics, and sharing each take tens to hundreds of milliseconds; combined, they can exceed 1 second.
• First database open and migration: Creating tables and upgrading table structure on the main thread during first launch can easily cause stalls.
• WebView or hot update check: Initializing WebView for the first time and checking update packages on the launch path can add several seconds on weak networks.
• Batch reporting of analytics events: Concentrating historical event uploads at launch consumes network and main thread resources.

In these cases, changing the design is sometimes more direct than changing code. The applicable boundary is: only when user feedback is concentrated on launch white screens and first-screen visible time is clearly long is it worth scheduling; if requirements undergo major changes every week, first-screen content is undecided, or slowness mainly comes from low-end device hardware, prioritizing stability and core paths is more cost-effective.

Solution comparison: optimize code first, add placeholders, or switch frameworks?

• Code-level optimization: Delayed initialization, asynchronous loading, parallel APIs, image compression, and caching first-screen data. The experience cycle is several days to 2 weeks, cost is relatively low, it improves actual time, and it suits most apps already online.
• Launch placeholder or skeleton screen: Show structural placeholders before first-screen data returns. The experience cycle is a few hours to a few days; it improves perception but does not reduce actual time. It suits scenarios where APIs are stable but network fluctuations are large.
• Switch frameworks or refactor the launch path: For example, changing from a heavy cross-platform container to a native home page, or splitting modules. The experience cycle is 1 to 3 months or even longer, cost is high, regression scope is large, and it should be considered only when the launch bottleneck clearly comes from the framework layer and the business allows it.

When comparing, do not look only at how much faster launch becomes; also look at maintenance cost and regression risk. A more reliable order is: first measure the four segments, then do delayed initialization and first-screen caching, and only after that evaluate framework-level changes.

Acceptance criteria and applicable boundaries

• Cold-start first-screen visible: On mid-range Android devices, a common optimization target is around 2 seconds; around 3 seconds is still common; over 5 seconds is easily noticed by users; iOS is usually shorter, but it is also affected by device model.
• Main thread blocking: During launch, avoid long continuous synchronous tasks; specific thresholds can be checked against platform tool prompts.
• White screen and black screen: From tapping the icon to the first frame appearing, there should not be a long period without feedback; if waiting is necessary, there should be a clear placeholder or loading feedback.
• Regression verification: SDKs with delayed initialization must be verified for normal first call, to avoid faster launch but slower first use of a feature.

Scenarios suitable for optimization: the app is already online or in beta, users report launch white screens or startup stalls; first-screen visible time is clearly long on similar device models; the launch path is piled with multiple SDKs or APIs not required for the first screen. Situations not suitable for prioritizing optimization: requirements are still undergoing major changes every week; first-screen content is undecided; slowness mainly comes from low-end device hardware or system reclamation; the business strongly depends on synchronous completion of security checks at launch. Boundary sentence: if launch time has not exceeded the typical range of similar apps and user feedback has not concentrated on it, prioritizing stability and core paths is more appropriate.

Delivery context: how to prioritize in a one- to two-week window

A common constraint is that only a one- to two-week optimization window is given, there is no analytics data, and upgrading third-party SDK versions is not allowed. The approach is usually not to rewrite, but to first add launch-phase time records, or use system logs to pull out the four segment times; prioritize the two segments with higher shares, such as delaying analytics and push SDK initialization until after the first screen, and changing two serial first-screen APIs to parallel. The result commonly reduces perceived launch waiting by 20% to 50%, at the cost that some SDK first calls are delayed by a few hundred milliseconds and require additional regression testing; otherwise, after release, you may receive feedback that “a certain feature is slow the first time it is opened.” According to project delivery habits, launch time and first-screen API time should be recorded separately to avoid mistaking slow network for slow code.

Common questions

Is it normal for an app splash screen to stop for 3 seconds?

A 3-second artificial stop on the splash screen is usually too long, and users easily mistake it for an ad or a freeze; in experience terms, keeping first-screen visible time around 2 seconds is more reliable, and if a brand page must be displayed, it is recommended not to exceed 1 to 2 seconds and to allow skipping.

Is slow cold start related to small phone memory?

It is related, but not entirely. Small memory worsens process reclamation and rebuilding, making cold starts more frequent; it is not uncommon for the same app to be 1 to 2 times slower on low-end devices. First confirm it is a cold start, then optimize code.

If the first-screen API is slow, is it a backend problem or an app problem?

Look at segmented time. If process creation and initialization are fast and the wait is mainly in first-screen data, it is mostly backend or network; if main thread blocking is obvious, then first do asynchronous work, caching, and placeholders on the app side.

Should launch optimization wait until all features are done?

It is not recommended to put it off until the end. The launch path changes as features are added; reserving lazy-loading and modular entry points early makes later changes much cheaper. Checking only after everything is done often affects the whole system.

If the app is already online, it is recommended to first use system logs to continuously measure 10 cold starts, record the four segment times, and then decide which segment to change first; if it is still in the requirements stage, first define what must be displayed on the first screen, otherwise optimization has no acceptance criteria. Launch optimization is not a priority for every project; during stages with low-end device hardware bottlenecks or weekly requirement changes, doing stability well first is more cost-effective.