Splash screens are a constant cause of pain for app developers. Clients see them as a way to push their branding when a user first opens an app and Apple see them as a marketing technique that slows down load time. When designing our iOS apps, we follow Apple’s Human Interface Guidelines as closely as we can, but occasionally we have to push these guidelines aside to keep clients happy.

However, it is also our role as market leaders to push for these best practices to be implemented and to provide the best performing app we can. So let’s take a closer look at what a splash screen is on iOS and why you should follow Apple’s advice to use it correctly.

Many companies assume that the first screen of a mobile application is an ideal place to apply their logo and branding. This is an acceptable practice for large applications and games because they require a loading screen, but for the mobile applications that are fairly lightweight, a loading screen is an unnecessary addition that slows down entry into the app.

Splash screens and intro animations became popular when Flash websites were all the rage. Marketers saw an opportunity to provide an entry animation while the site content was loaded, which back then would have been over a 56kb dial up internet connection so a loading screen would have been expected. But as the Flash platform evolved, browsers became more capable and broadband became the norm. ‘Skip Intro’ buttons started to appear because the content was loading more quickly. The general consensus from the web community was that if you need a skip button, then the animation was blocking the users entry to the site and should be removed.

This same mentality has been applied to mobile applications and it makes even less sense than it did before. Firstly, iOS apps do not have a splash screen, they have a launch image, and although the distinction is not immediately clear, it is extremely important to differentiate between the two. Wikipedia describes a splash screen as:

“Splash screens are typically used by particularly large applications to notify the user that the program is in the process of loading. They provide feedback that a lengthy process is underway.”

When presented with a branded launch image, the first impression companies give their users is that the app is slow and heavy, so it is often disguised with a brand logo or animation. Apple’s Human Interface Guidelines state that an application should include a launch image to give the impression that the app has loaded quicker than it actually has and not for marketing purposes.

What companies are in fact doing is deliberately slowing down the user journeys to ensure users see their logo each time they open the app. We have been asked in briefs to add in an artificial delay to ensure the branding gets noticed. What makes this approach worse is that as devices become more powerful, the artificial delay will have to become longer as the apps will naturally load faster.

Companies invest time and money into their apps to ensure they are optimised to run as best as they possibly can. For that reason it’s counter intuitive to deliberately slow down an app for the sake of a branded splash screen. Apple’s Human interface guideline document defines a launch image as:

“…very similar to the first screen your app displays. iOS displays this image instantly when the user starts your app and until the app is fully ready to use. As soon as your app is ready for use, your app displays its first screen, replacing the launch placeholder image.”

Apple’s own applications follow this pattern, the stocks app for example:


The launch image is simply a blank version of the application. This will be displayed as soon as the application is launched, making it appear to have launched faster than it has. When the rest of the app has loaded, the launch image is replaced by the actual app.

The guidelines then goes on to say…
“Avoid using your launch image as an opportunity to provide:
  • An “app entry experience,” such as a splash screen.
  • An About window.
  • Branding elements, unless they are a static part of your app’s first screen.”

Companies worried about users not recognising their brand if it isn’t displayed on the launch image of the app should consider where their users originally arrived from:

  • Searched the App Store for a brand name:  If a user searches a brand in the App Store they clearly know what they are searching for. They will also recognise the company logo within the App Store and once downloaded, the app logo will remain on the mobile device.
  • Searched for a keyword and recognised branding through the app icon in the App Store: If a user recognises a brand, they will pick it out from other apps in the App Store.
  • Followed a link from a website or email newsletter: In either case, the user will know what app they are downloading and why they want to download it. If the user has come from an email newsletter, they will already be loyal to your company having subscribed in the first place.

It might be argued that users who arrive at an app from a social media platform or search engine may not recognise a brand and therefore a branded splash screen might be the best approach. But as developers, we think this is sacrificing the user journey of those who already have the app and are loyal of the brand.

The most important place to get branding right is on an app icon because it’s the one of the first images a user will see when entering the App Store and it sits on their mobile device. The rest of the app’s branding should be evident enough throughout the app without having to load a logo when it is first opened by the user.

So if you are planning an app and you haven’t already done so, check out the Apple Human Interface Guidelines. As the name suggests these are only guidelines, it is unlikely that Apple would ever reject an app for using the launch image as a branding area, however Apple design and build some of the most user friendly software and devices on the market so following their lead probably isn’t a bad idea.

Ben Reed, Head of iOS

Join Our Mailing List

You have Successfully Subscribed!