Note: People who bought my book dealing with Android development will probably notice this article looks like a section of the fourth chapter “UI & UX: major components for a great user experience and the Android logic”. Let’s be honest, this blog post is pretty much an enhanced translation of a section of my book. For those who don’t know about this book, written in French, the title is “Développez pour Android”. Released about a year ago, it deals with Android development in general and particularly focuses on making highly optimized Android applications. If you are interested in this book, you can buy/download it here.

I have recently seen many Android applications starting with what I call a splash screen. A splash screen is an image that takes the entire screen space and usually shows branding information about the application (logo of the company, logo of the application, etc.). This screen is generally visible for a small amount of time while the application is starting or loading some resources in the background. I am pretty sure you have already seen some of the popular Android applications below featuring a splash screen on startup:

Once again, from my point of view, the splash screen paradigm is a port of the iOS equivalent. Some of you may start thinking I hate iOS because it influences Android in a really bad way. I often consider lots of mistakes in Android applications are due to stupid ports of iOS apps to Android. However I don’t consider iOS as a crappy mobile platform. I honestly believe iOS is an awesome mobile OS. Issues are not related to OSes themselves but to how people incorrectly understand them and use them. The splash screen is one of the best example of how people are misleading OSes in general. Being widely used on iOS, the UI pattern is also actively discouraged by Apple! Indeed, if you look closely to the iOS documentation you will notice Apple encourages developers to use launch images. Launch images are very different from splash screens as they are images used to pretend an application launched rapidly. On iOS, the system displays the launch image instantly when the user starts your application and until the app is fully ready to use. As soon as your app is ready for use, it displays its first screen, replacing the launch placeholder image. As a result, supplying a launch image is the best way to improve user experience. The graphic below shows you the launch image on the right that is used in the built-in “Stock” iOS apps:

The iOS documentation clearly specifies launch images should not be used as an opportunity to display branding information. Unfortunately, rules are made to be by-passed and iOS folks understood that. I honestly can’t blame them! They have simply used a functionality offered by the framework and slightly modified launch images to use them as splash screens. What is very disappointing to my mind is the same pattern is currently happening on Android. I am strongly convinced splash screens are not appropriate on Android for several reasons I would like to share with you:

• A splash screen prevents the user from using the application. As far as I know, it is not explicitly written in Android guidelines but Android has been primarily designed to help the user achieving and completing tasks rather than offering features. In order to do so, the entire system focuses on what users want to do and letting them do it as quickly as possible. This fastness is achieved by rendering the overall UI in a insanely fast fashion and never blocking the user. Some of the best examples of this are the notification area (I guess iOS users will always remember the so annoying and blocking popups - UIAlertViews - when receiving a text message pre iOS5), the advanced multitasking mechanism, the launcher widgets, the fast transition animations (I don’t have the exact numbers but the default transition between two Activity is twice as fast as the transition between two UIViewControllers put in a UINavigationController), etc. In a nutshell, being blocked is not something an Android user is used to nor wants to be confronted with.

• Most of the time, it is not necessary A splash screen can be used to make resources available before an application starts. Personally I think it is not necessary in 98% of the cases. It may be useful for applications actively relying on heavy resources such as Google Earth, Sky Map, or games but this is not applicable to simple utility applications such as feed readers, social network apps, news readers, etc. You should not require a network connection at startup nor do heavy computations. Always keep in mind, Activity launching is blazingly fast on Android. The Android team at Google spent a lot of time - and I am sure they are still spending a lot of time working on it - ensuring applications and the Activity class launches very rapidly. As a result it is quite easy to have an application and its first Activity up and ready in less than 400ms. Also always keep in mind that an application displaying a splash screen is also completely up and running from a system perspective.

• Displaying a launch image or splash screen in not part of the framework¹. I don’t know the exact percentage of the Android documentation I have read at least once but I assure you the number is pretty high! I have never seen a method, class or xml resource explicitly dealing with launch images or splash screens. This obviously proves the Android team never considered the launch image trick as necessary or easy to implement.

• Adding once-viewed resources increase the size of your APKs. In order to make a great splash screen, one may usually need to add several resources to the APK (bitmaps, layouts, 9-patchs, etc.). This may uselessly and drastically increase the size of your APK making it more difficult to download/install. It may also drive several of your users mad if they have a pretty memory-constrained device. I think the best way to demonstrate the horrible consequences of launch images is to give the example of a universal iOS app (a universal app is an app running both on iPad and iPhone). As I previously explained, iOS fakes fast application startup rapidly displaying a launch image. If you look closely at the iOS documentation, you will notice the iPhone requires two default images (only in portrait, one for each density - 320x480 and 640x960) while the iPad requires 4 images (one for each orientation and density - 768x1004, 1536x2008, 1024x748 and 2048x1496). Knowing iOS requires launch images encoded using the PNG compression algorithm, you will likely create an application that is almost 5Mo-sized (depending on how much your launch images are compressed) and only displays a splash screen!

• Implementing a great splash screen is very difficult and tedious Developing on Android requires dealing with a lot of resolutions, densities, orientations, etc. In general, the built-in resource switching mechanism is enough. In the context of splash screen development in which absolute layouts are usually required, it is generally not sufficient. Moreover, you also have to deal with Android’s Activity lifecycle. I have seen many application falsely redisplaying a splash screen in low memory conditions, because the developers forgot to save the splash-screen-has-been-displayed flag in onSaveInstance(Bundle). The worst bug I am used to see is an app auto-magically restarting itself after the user got out of it. This is mostly because splash screen are implemented using a Runnable posted with a certain delay in a given Handler. Not removing it from the Handler’s queue in onPause() will let the application restart itself. Developers should rather focus on making their app launch time as short as possible rather than designing a well-working splash screen. Equally, designers should spend more time on making Android apps Androidy…

• Users don’t care about branding at launch time. When a user is starting an application, he/she is expecting it to fully fulfill what it is intended for. Making your applications responsive and fast is part of that job. Having a splash screen or a long startup time is the best option to do the complete opposite of what the user wants. If you really need to brand your application (and I encourage you to do so to create visually unique looking apps), I strongly suggest you to style the ActionBar, add an ‘About’ screen, use the background as a display area, etc. Doing in-app branding is the best opportunity to spread your message to your users as it will remain visible on all application’s screens. Believe me, as a user, when I open the Facebook app, I already know I am using the Facebook app. There is no need to display a huge Facebook logo in the middle of my screen.

• A splash screen indicates a single-entry point application. Just a few application use this technique but Android applications may have several entry points. The best examples of that are Maps, Google+, Contacts/Phone or, more recently, Facebook. This can be done very easily using the appropriate <intent-filter />s on your entry point activities in the Android manifest. I’m not saying this is something that is easy to apprehend for a user but it’s available from a framework perspective. This feature is not supported by iOS. Because of this, lots of people falsely consider an app has a single entry point and use it to add a splashscreen.

• In a multitasking context, launch images have no meaning. In an ideal multitasked environment (ideal means en environment with access to unlimited resources), a splash screen is diplayed only once: the first and only time an application is started. Indeed, once an application is started, there is no need to display the splash screen again as the application will always remain in memory. Android has been primarily designed as a massively multitasked OS and therefore doesn’t stick to the splash screen paradigm at all.

Conclusion

When Apple launched the first iOS SDK, it may have made a great decision by enabling developers to fake a fast application startup via a launch image. Unfortunately, iOS evolution - iOS now runs on several densities and devices and supports multitaking - and the fact that developers completely hacked the way launch images are used made it a big mistake. Spending time on ensuring applications are opened rapidly would have been a better option. On the other hand, Android has been built to deal with an insanely large amount of devices. Please start taking this into account and continue fighting against the iOS enthousiasts who think the iOS way is the only way. iOS and Android are both awesome mobile OSes. They both have some particularities that need to be taken into account when developing applications. Understanding an iOS app is appropriate on iOS, and an Android app is appropriate on Android, etc. is the path to making awesome multiplatform applications.

---

1. Android has actually always had a built-in mechanism similar to launch images. I won’t talk about it as it could be the topic of an entire article. Moreover, writing about it in an article severely criticizing the splash screen paradigm would be the best way to make this blog post pointless.