Hacker News new | ask | show | jobs
by potatolicious 4669 days ago
Easier said than done. This is trivial for single-purpose apps like Calculator or Weather, where it's easy to predict what the post-launch UI will look like (hint: there's only one screen...)

For much larger apps the "fake screenshot" is harmful. Take the Facebook app for example - what should the "fake screenshot" be? iOS does not differentiate between a completely fresh launch vs. a simple restore from background, and will show the same image no matter what.

So now you're in a situation where you've presented your users with a fake/blank Facebook stream, but really they were restoring to a photo they were looking at. Oops.

Or hell, do you even know if your user's logged in? Would be a shitty experience to show them the fake/blank stream but suddenly pop them back to the signup/login page no? What if they are logged in? Would be a shitty experience to show them the signup/login page and suddenly yank that out from under them.

This whole business is a shitty solution to a shitty problem: apps take forever and a day to launch.
2 comments
MProgrammer 4669 days ago
There may or may not have been an API method in iOS 6 developer previews that allowed the app to provide the system with a new screenshot for resuming from background. That API method may or may not have been removed by the time iOS 6 shipped, and may or may not be back in iOS 7.

<whistles>

As for slow app startups, Apple hates that too. It's fine to show a loading screen, if there is loading to be done. Showing marketing videos and other bullshit? No. Not fine.

link
raphael_o 4669 days ago
Background fetch actually provides a solution this exact use case. If the user uses your app enough for iOS to let you run in time, the app should be able to "get ready" before the user opens it.
link
potatolicious 4669 days ago
How so? You can know all the state you want, but iOS is still going to display that one static image. If the user is returning from background into a photo gallery, it's still going to show your default image. If the user is opening the app directly into a conversation, it's still going to show your default image.

I don't see how backgrounding solves any of this.

link