The cards are already showing stale information, including Apple's own apps: http://d.pr/v/NuY5. As for background updates, there are some ways around through iOS7 background modes, but the situation could certainly be improved. I agree there should be an Apple provided "AppSwitcher Kit" framework.

Right now though, I have this intuitive belief that when I close an app, it "pauses" and the card I'm seeing is a frozen state of what the screen looked like when I hit the home button.

I don't know if that's how other people perceive it, but it does feel extra-wrong when you hack it to try to convey timely information in the switcher.

The only legitimate use case to me seems not displaying possibly sensitive information.

That's a very big and sufficient use case, significant enough to warrant making this "concealment card" the norm unless there is a reason not to. Not the kind of thing you want a customer realizing after the fact.

I think you lose a lot of context. The screen shots help you remember what you're doing. In most cases, I would rather see the last state my app was in.

You're missing the point. Several, actually. Sometimes screenshots are not acceptable - such as when they show Social Security Numbers, bank account numbers and contents, or NSFW stuff (imagine switching when AirPlay-projecting for a group during a meeting). Sometimes screenshots hang on for a long time in the switcher - the session may have expired, but the thumbnail is still there days later, showing wrong context. Sometimes the snapshot is just plain unreadable because it's scaled down, making it unusable even if you want to see it. The whole point of the parent's source code IS to provide app state info WITHOUT just snapshotting the screen or showing a bland logo.

I'm just not able to see the point. You're the user and the device is in your possession. If that's not the case, that's what a PIN or TouchID addresses.

A OS X desktop analogy would be having sensitive information in a Safari window, then hitting the Mission Control key, and expecting the zoomed out image to be replaced with something obfuscating the sensitive information, only to be restored when you click on the window. I don't see what's gained.

The point is sensitive data is stored unencrypted and displayed outside the app during normal usage. That is flatly intolerable to many users.

Screenshots are fine as long as they reliably show the last thing the user saw before switching from the app. It's up to the user to shut down the app or ensure it's not in a sensitive state if they need to. If your browser is resting on a page with your social security number on it, then that's the problem right there --- not that there also happens to be a screenshot of this on the switcher.

Some niche apps might benefit from employing a scheme like this to bolster security (I'm thinking for example a password manager which requires its own passcode whenever you switch to it), but the potential minor security drawback for these niche situations is definitely not sufficient to require this across all apps.

Screenshots with sensitive info are not fine, that screenshot is stored on disk unencrypted. They also often outlive the running instance of the app. This bypasses any protection regularly used by the app for that information, and therefore the best practice is to blank out anything the typical user deems sensitive.

I saw this in the WWDC videos from this year, Apple provides this functionality.

Seconded. This is already possible.

Yes, releasing an API for a feature that essentially has never been in an approved app is pretty risky.