For some unfathomable reason Google decided to add Splash Screens to their design guidelines. While they now call it a “Launch screen” it’s the same thing. A screen that is shown to the user while the app is loading.

Unsurprisingly, this started a lot of (unhappy) discussion in the Android community. I recently added my opinion as well. In all the discussions there’s a common theme. Overwhelming majority of people seems to be against the use of splash screens. Then again truth is not democratic so paying attention to the arguments for usage of splash screen makes sense as well. In almost all of the discussions the same arguments arise. Until now I’ve not seen a single argument that I’d completely agree with.

As the discussion in G+ has been spread into multiple separate threads already instead of trying to reply to them separately I’m writing my answers to the common arguments here.

Argument: Splash screen is better than staring at an empty screen.

This is one of the most common arguments what I’ve seen posted in the comments. If your app’s landing screen takes a long time to load your app is broken. While arguably Android has become slower over years Activity startup times are still very fast. Inflating the main layout and showing a UI without any dynamic data should be very fast. If that’s not the case in your app you should fix it by making it fast to load instead of adding a splash screen that will then guarantee that your app is always launching slow. We have to remember that mobile apps are used in short bursts. Sometimes a use session might last only for few seconds as user checks something or searches for an answer. If your app uses 3–5 sec to even show a UI to your user you’re already wasting user’s time.

Argument: Splash screen is better than not having any information if the app is launching other than the launcher button getting pressed.

While technically this argument is true the root cause of the issue is not solved by adding a splash screen. Some apps do indeed take ages to even show up and lock the UI while they’re trying to do everything to show user something. These apps need to be fixed! The app is running something in the UI thread that it shouldn’t. The app developer needs to take care of the threading to fix the app. “Fixing” it with a splash screen is like adding gaffer tape over a leak hoping it’ll go away.

Argument: My app’s data takes a long time to load. A splash screen is better than a loading indicator. This especially with slow internet speeds.

This argument is also very common but I feel that there’s a fundamental flaw in it. This argument assumes that the users always want to start with the data that is being shown on the app’s landing screen. The reason I argue against splash screens in this case is twofold:

If you show your app’s UI to the user first and then load the data into it you allow user to orient to the UI and they’re immediately ready to go when the data comes in. Users don’t always want to interact with the data on the app’s landing screen. Let the user get on with their task without forcing them to load the first screen’s data. This is very important especially on a slow internet connection. Let user interact with your app while the data is loading. In many cases they might not care about the data you’re loading by default.

Argument: Splash screen is needed to help brand presence.

If the design can’t display the brand without an extra screen the design sucks. You can’t rely on a screen that is shown to the user once in the start of an app to convey an important message.

Argument: Splash Screen can be implemented correctly.

To me this boils down to three main things:

This is a slippery slope.

Yep, a slippery slope argument is a logical fallacy. Unfortunately, I believe this being actually a slippery slope in our industry. I’ve been part of many software teams and seen many from far. The problem is that a lot of uninformed decisions get made in the teams. It is unfortunate situation but happens more often than we’d like to believe that people without knowledge or understanding to make a decision make decisions about things they shouldn’t even be part of discussing. Brand design in an app is one of these. A product owner often want the brand more visible without understanding the impact to the users. While they selfishly simply want their logo to be visible everywhere they don’t understand the harm they cause to the app’s UX this way directly harming the brand image.

Previously we, as the devs and designers who want to create the best possible app, have had another logical fallacy in our toolbelt to fight this. The Authority Fallacy. We have been able to argue that Google says that splash screens should not be used. That usually convinced these decision makers who would ignore arguments from their own experts. What will happen now? In the same discussion they can pull out any Google app and point to it and say that “Google is doing this, so will we”.

The big problems will come once the decision is made and all the sudden there’s one extra screen for people to add junk on. Nearly an empty screen to play with. At this point it doesn’t matter if we, the devs, start explaining how it is just a theme background image and not an actual screen. The battle is already over. I know this will happen. I’ve been in these meetings. I’ve worked with these people. Google has stripped us from our weapons in this battle.

Dear Google Dev Advocates, you live in a different world than we do… Say hello to ads on splash screens…

Trying to do a splash screen right is like polishing a turd.

The pattern is flawed. Fundamentally flawed. When you premise is wrong it doesn’t matter how well you do something it’ll still end up being wrong.

Google’s version of splash screen is just a themed background shown while the app inflates it’s UI. While it sounds like a nice idea it really isn’t. A small graphical component certainly loads so fast that it doesn’t slow down the UI inflation but why would you do that. If your app’s UI inflation takes seconds you’re already doing something wrong. If it doesn’t take seconds only thing you’re doing is flashing some graphic to the user that they don’t really catch. Quickly flashing graphic is worse than no graphic at all.

Then there’s the problem of this kind of splash screen not being able to convey any progress. It’s just a static screen. If something takes longer how do I communicate that to the user? You know that the first thing any designer wants to add to this is a loading indicator and a nice transition out of the splash, right? This leads into a situation where we now have to use an Activity instead of the screen background. Should we then use a splash screen while we’re loading our splash screen?

Showing splash only on “cold launch” exposes users to OS internals.

Android OS was designed to hide OS functionality from users and developers work hard on making the users feel like the app is always there and they can continue from where they left off whenever they come back. We do this because users shouldn’t have to understand what happens when the phone runs out of memory and the apps are cleaned from the memory.

Now we introduce different functionality on “cold launch”. It makes perfect sense to us, the devs, but it doesn’t for regular users. To a regular user this functionality will only be confusing. The app sometimes shows this strange logo screen and sometimes it doesn’t. What’s the difference? Do I need to do something different?

This is such a bad idea. Consistent and predictable behaviour is important! Let’s not force users to start figuring out what’s going on under the hood.

So. NO. Do not add splash screens to your app. Simply make sure your app launches to the main UI fast and let users get on with what they want to do.