Splash screens are evil. While branding is important, the proper place for it is in the iconography, optional “About” or “Info” screens, and App Store profiles. The most common interaction pattern with iPhone applications is to launch them frequently, close them quickly, and treat them as part of a set of tools that interact to comprise a single user experience. Splash screens break the perception of seamlessness.
The HIG offers a very useful suggestion for managing launch states, which may be quite slow, depending on the needs of your application. The suggestion is to provide a PNG image file in your application bundle that acts as a visual stand-in for the initial screen of your application. For example, if the main screen for your application is a table full of data, provide an image of a table without data to act as a stand-in. When your data is ready to be displayed, the image will be flushed from the screen, and the user experience will feel more responsive.
In this book, we will explore extensions of this, including a pattern for loading application state lazily
–Toby Boudreaux, iPhone User Experience, page 15; emphasis mine.
I’ve always hated splash screens, from the first time I turned on a computer. They get in the way of what I want to do. I want to write, or draw, or play — but if I launch Word, or Photoshop, or any game, I have to sit through a splash screen before I can get to it.
Branding a splashscreen is putting your name on a purely negative experience. Nobody wants to wait for their computer. Splashscreens, by definition, force you to wait. It’s hard for me to imagine why anyone wants to associate their brand with a computer not doing what customers want.
iPhone 4 Update
Fast App Switching, introduced in iOS 4, makes splash screens a much worse idea. They won’t consistently display, because sometimes the app will really be resuming, not starting for the first time, when the user “launches” it. Forcing a splash-screen to appear on a resume as well means breaking the “multitasking” experience.
Our first app followed the HIG guidelines and dutifully used a screenshot of the main menu screen as the splashscreen. The app loaded quickly and in testing it seemed to work fine. But customers didn’t like it. As you say, we want to use an iPhone app as soon as we open it and that means we are tapping away at the screen as soon as we have finished tapping the icon to open it. The result is that nothing happens and we have to tap again. Our customers found this irritating. We changed the splashscreen to a logo which disappears as soon as the first xib file has loaded and our customers are happy.
My point is that, used properly, splashscreens are a good thing. You can’t use the app before it loads whether the splashscreen is there or not, and the splashscreen gives visual feedback that the app is still loading. I’d rather stare at an attractively designed splashscreen for those few moments than an unresponsive menu screen.
Comment by spinyanteater — January 19, 2010 @ 5:02 am
spinyanteater,
I totally agree there! But I see it as a “lesser of two evils” kind of fix — a hopefully temporary solution. Ideally it’s possible to come back later and optimize loading time to the point that it isn’t unresponsive.
But of course this isn’t an ideal world. it’s not possible to solve every problem. Some apps need 3-5 seconds to start up on a phone — in that case, some kind of splashscreen is a necessary evil.
For what it’s worth, I’ve read that a “loading” screen (showing a static UI + a spinner) can work better than a static splash screen.
–James Thomson, How To Make Your iPhone App Launch Faster
But if a pretty-logo splash screen tests better for your users, then clearly it’s the way to go! Maybe it’s breaking the HIG, or “best practices”, but it’s justified with real evidence.
Comment by Vincent Gable — January 19, 2010 @ 12:41 pm