We've gone through the same problem. In our case, we wanted our game to resume exactly where the user left off (i.e. no splash screen).
Our solution was to use a pure black Default.png, and design our game to have very low upfront load times. On iPhone 3GS, our game takes 1-2 seconds to fade in from pure black.
This also fixed the problem we had where some users that preferred to flip the game upside down (landscape mode).
By displaying the last snapshot of the app as a splash screen, the Apple apps imply that you can immediately interact with the application - but you can't, because it's just a static image.
On slower hardware (e.g., the original iPhone/iPod Touch), this violation of user expectations can last for a measurable time - easily enough for the user to make multiple attempts to interact.
Touch...nothing happens. Touch...nothing happens.
A splash screen is better than a misleading "last view" snapshot.
The 'last snapshot as a splash screen' actually traces back to Jeff Raskin's work on the Canon Cat.
It counts on the user trying to remember where he left off while the program loads, so by the time you think "aha, I was gonna send an e-mail to Ron" the UI is responsive. It's a nice trick that saves you time in the end.
Of course, if the app takes too long to launch the UI would seem unresponsive, which is why Apple chose to not make it available to third party developers.
He doesn’t and can’t use a last-view snapshot. He uses an empty UI with no content and no buttons, consequently it cannot be misleading. I would prefer that massively to a cheesy splash screen and a last-view snapshot, the only problem is that it doesn’t always fit.
Notes and Calendar are the only apps that still use custom launch images. I always found it to be more annoying than useful because you can't tell when the damn app has actually started running, so it's no surprise that they didn't make that feature available to third-party apps.
But if you look at Apple's other software, say, iBooks or Remote.app, the launch image often doesn't match the initial UI presented when the app starts running. I don't think it's much of an issue.
In the case of Instapaper, I might consider doing a very fast animation from light to dark, when necessary, but I wouldn't spend much time on it.
Interesting; I didn't know that. The block-based methods are, of course, better, but then you can't support iOS 3.x, which is still a pretty big percent of users.
I've tried to do this with my own app before. I ran into difficulties doing it, if I remember right, because the orientation data is not fully initialized at the point in the launch sequence that you need it. It always reports the default orientation.
This is another case of Apple not allowing third-party apps the same features of it’s own apps (the previous privilege being multitasking, now mostly allowed).
This disparity makes it hard for a developer like Marco, who is only trying follow his rule of “If in doubt, do it Apple’s way” (as repeated in the HIG and similar documents Apple provides to developers).
That said, with the new multitasking support in iOS 4 for newer devices, perhaps this issue is less important than it once was, especially for apps that you use often (and thus keep running).
It's not that big of a deal, let's not turn this into an "Apple is evil" discussion. Apple deals with this in their own apps (iBooks, for an example off the top of my head.) Every iPhone developer deals with it as well.
There does seem to be a difference in Apple's App store apps and the default system apps, which could be considered more analogous to a OS feature. The distinction is muddled since these OS features are accessed from the springboard, along with actual apps.
Nice. A gray evocative of either look was my first thought as well.
It could also be half-and-half -- for example a diagonal cut. (Then the transition to the actual could wipe the wrong color off to one side.)
Or, a shaded gradient, top to bottom, between the light and dark -- so either way the flicker-to-actual is half as harsh. (This could also work well with a fade/wipe to actual.)
On the fastest hardware, you could keep Default.png displayed just a split second longer to avoid the "blink too quickly" problem.
Yes, it's bad because it further delays the launch of the app but if the hardware is so fast that the short blink is a concern the slight added delay probably isn't a big deal.
This is also an issue for one of my apps, which can launch in a horizontal landscape, there's no way to create two Default.png files, once for each orientation (correct me if I'm wrong, would love to optimise for it).
You can (and would) on iPad, because apps can launch in any orientation. On the iPhone, apps always launch in portrait orientation (unless it's a landscape-only app) so your iPhone launch image only needs to support a single orientation.
Marco doesn't have any comments enabled, which is a shame. He seems quite difficult to make contact with.
I'd say start with the dark default image. If you're starting Instapaper in a poorly lit environment in dark mode it'll be more disrupting to your night sight to have a bright starting image than if you start in normal mode and have a dark starting image.
Are splash screens cheesy? That's a personal convention, but screwing with someone's night sight for a particular use case focused on it being dark is probably far worse.
I use dark mode during the day on Instapaper Pro, I just prefer it and find it easier on the eyes.
Correct me if I'm wrong, but isn't this problem solved by using a symlink? Creating a symlink with the name Default.png and then dynamically generating the file it points to is basically on par with Apple's built in apps.
I would just forgo the launch image for Instapaper then. Just get the UI up as quickly as possible. Also, supporting "multitasking" on iOS 4 helps with getting the UI up quickly when brought into the foreground.
You can skip the Default.png file. The experience without it can be terrible, though. Your app will just show a black, blank screen until it finishes booting.
It's a bad enough experience that it's not even worth considering.
I love the look of the splash screen... why don't you just go with that? What does dropbox do? their app comes up with a lovely looking splashscreen as well and it sticks for a little while..
iPhone User Interface Guideline recommends design a launch image that is identical to the first screen of app, and avoid a splash/about screen and branding elements.
Our solution was to use a pure black Default.png, and design our game to have very low upfront load times. On iPhone 3GS, our game takes 1-2 seconds to fade in from pure black.
This also fixed the problem we had where some users that preferred to flip the game upside down (landscape mode).