Mobile Development 11 min read

Why Splash Screens Are Harmful in Android Applications

Splash screens in Android apps, especially in many Chinese releases, waste startup time, disrupt users’ task focus, consume unnecessary resources, and replace better branding options, so modern hardware and design guidelines recommend eliminating them to improve speed, flow, and overall user experience.

Baidu Tech Salon
Baidu Tech Salon
Baidu Tech Salon
Why Splash Screens Are Harmful in Android Applications

It's been almost a year since I returned to China. Being in the country, I inevitably use various domestic apps, and many Android apps suffer from poor quality and numerous issues. Inspired by today's Zhihu update, I write this article to discuss a common problem in Android apps: the Splash Screen. This issue is not limited to Zhihu; many domestic apps share the same problem.

In fact, the Splash Screen has a long history. Its origin can be traced back to early PC games and large desktop software—these applications needed to load many resources at startup and could not let users think the software had crashed, so they displayed a launch screen, often with a progress bar, to indicate loading (some software would just show a launch screen while actually crashing).

On mobile apps, the use of Splash Screens dates back to the launch of the iPhone—though at that time the “launch screen” was not yet called a Splash Screen. The earliest launch screens were either a static image mimicking the app’s UI or simply a screenshot of the app.

iOS apps used such a launch screen to make users think the app was already loaded while the app fetched data and resources in the background, later presenting them to the user. This approach worked well, giving iOS a reputation for fast startup. Early iPhones, limited by hardware, often took two to three seconds to become usable after tapping an icon; a black screen would be intolerable. Today, with hardware advances, iOS HIG no longer recommends using an app screenshot as a launch screen, instead urging developers to avoid splash screens as much as possible.

The standard Android app startup follows a similar logic: first load the app framework (not an image, but the actual code), while fetching content in the background, then present it to the user. See Android Design in Action – Early Experience. The previous version of Zhihu’s Android client did this and the experience was quite good.

From the beginning Apple never intended launch screens to become the modern Splash Screen. Yet over time many developers started to misuse this screen: initially adding a company logo to reinforce branding, then gradually removing the framework image altogether, turning it into a logo or even an advertisement. Thus the launch screen has degenerated into a Splash Screen.

Turning back to Android: in China, especially among large companies, Android has always been a subsidiary of iOS; whatever iOS does, Android follows. When iOS apps turned launch screens into logos and ads, Android apps inevitably followed suit, even adding clickable links on the Splash Screen.

So why do Apple and Google consider Splash Screens undesirable and want to eliminate them?

First, with modern hardware and app optimization, loading resources no longer takes long. Even today, some poorly optimized apps still need a lot of time to start (e.g., Path). Ideally, the time from tapping an app to it being ready should be less than a second, even 500 ms. Adding a Splash Screen only slows startup.

Second, launch screens interrupt the user’s thought process. Users often open an app with a specific task in mind (e.g., a calculator). If a Splash Screen shows other information, the user may forget their original task. I previously criticized the Smartisan ROM calculator for a design that caused a visual illusion at launch, making users forget why they opened it. The same applies to Splash Screens in many other apps.

On Android this problem is more severe—Android is a multitasking system, frequently switching between apps. When a user jumps to an app with a Splash Screen, they may be distracted and forget their original purpose, hindering cross‑app interaction. Moreover, because Android apps often have multiple entry points (main screen, sub‑levels), a Splash Screen can break navigation flow and lead to a terrible experience.

Adding a Splash Screen also consumes extra resources. Many domestic apps use a single image for the Splash Screen. Given Android’s fragmented screen resolutions, the image can take up a lot of space. Worse, some launchers are not optimized for various resolutions, resulting in stretched, ugly images on devices like Nexus 4 or Meizu MX 2/3.

Regardless of how good your logo looks, there is no need for a dedicated Splash Screen—Android’s standard Action Bar already provides a place for the app logo (except when using an iOS‑style UI, where the top bar lacks a logo slot). Moreover, there are many better ways to present branding; why choose the least liked method?

More importantly, any Splash Screen, no matter how beautiful, wastes the user’s time. When Apple first introduced launch screens, the goal was to make users feel the app started quickly. Today, developers misuse this to waste time. Mobile apps should prioritize content and functionality; even an extra millisecond of Splash Screen wastes countless users’ milliseconds. Android design principles emphasize “Simplify My Life” and “Make important things fast” to avoid unnecessary waiting. Users already wait enough in life—subway, traffic lights, queues, web loading, downloads, makeup—why add more waiting in apps? Smartphones exist to reduce waiting.

mobile developmentAndroiddesign principlesSplash ScreenUI/UX
Baidu Tech Salon
Written by

Baidu Tech Salon

Baidu Tech Salon, organized by Baidu's Technology Management Department, is a monthly offline event that shares cutting‑edge tech trends from Baidu and the industry, providing a free platform for mid‑to‑senior engineers to exchange ideas.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.