Customize iOS7 App Switcher with custom card view | Hacker News Reader

Customize iOS7 App Switcher with custom card view

github.com

92 pointsmacalicious25 comments

It looks like the trick here is to hook into a global NSNotification called "UIApplicationWillBeginSuspendAnimationNotification", which is assumed to be "app will enter background", and then throw up a fullscreen UIView on top of everything.

I think this is an undocumented notification, so it's possible other iOS versions will break this feature.

I can't find it at the moment, but I think there is a supported way to achieve the same thing. I remember it being mentioned at WWDC to allow apps to hide sensitive data in the UI before the screenshot for the app switcher is taken.

Yes I remember that as well, all you have to do is set the UI you want to be screenshotted in the applicationWillEnterBackground notification/application delegate callback. This has been around since fast app switching (iOS 2.3 I think, the golden old days :)) but has gotten much more prominent with the new app switcher.

Yes, 1Password does this. If you have it unlocked, and then switch to another app, then switch back, the thumbnail is the lock screen, even though that's not the last thing you had onscreen.

I'll wager Apple will shut this down or reject apps that do this.

If you're going to do this you have to consider the ramifications of how stale the information on the card becomes over time. The example, showing a "Checked in since..." will become stale if someone checks in/out on another device.

A real iOS 7 API to update these cards in the background would be a nice addition.

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.

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'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.

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.

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.

Maybe I'm too pessimistic, but I expected the example to be just the app's logo. Ie: oh, that's my Dropbox app because instead of the Dropbox UI, I see the big Dropbox logo (Nothing against Dropbox or their app). I also wonder if we'll ever see the app switcher card being used as advertisement space.

A little less cynically: If you can redesign a screen in the app to remove clutter and highlight the important information for the user for the app switcher, why don't you do that in the app? Sounds like it might be a better UI design. Now, I can think of many reasonable counter examples, but I'd challenge you to spend more time on the app UI where your users spend most of their time.

>> "If you can redesign a screen in the app to remove clutter and highlight the important information"

It's not that simple. The problem isn't information density/clutter. When in task switching mode the screen is very small so just being able to make the most important information larger so it's easier to read is useful. Also, there may be buttons on screen that may be important features - but they aren't important in task switch mode as they can't be pressed so removing them and making more room for the content makes sense.

It's like designing for a small screen device and a larger screen device. You can make useful features easier to access on the larger screen due to the extra real estate. That doesn't necessarily mean you're cluttering the UI.

The switcher view is a) purely read-only, b) scaled down in size from the normal view. I think it makes sense for info to be presented differently in this case. When you make an icon smaller, you don't just take the existing design and scale it down. You also remove detail you can't afford to try to make the design clearer overall.

Nice idea. Probably something Apple should be making available easily via the API as it could make the task switcher much more useful.

Interesting stuff, surprised the built-in apps don't do something similar to this.

As an aside, is there anything similar to this for android? I've tried a fair bit of googling but can't find anything or the right search term.

There is a method `onCreateThumbnail()`[1] that is supposed to allow you to do this, but it doesn't appear to work (reported bugs in 4.0-4.2). The best you can get at the moment is to blank out the thumbnail[2] (for security reasons) or opt out of being shown in the list [3].

[1]: http://developer.android.com/reference/android/app/Activity....

[2]: http://commonsware.com/blog/2012/01/16/secure-against-screen...

[3]: Use android:excludeFromRecents="true"

I'm guessing Apple will shut this down. The thumbnails are there for the sole reason of you visually identifying the apps as you left them. If applications can change that snapshot at will then it becomes a mere gimmick.

Reply on news.ycombinator.com