When PIN enabled, backgrounding the app should immediately trigger the lockscreen.

[ara4n]

Steps to reproduce

1. Enable PIN
2. Start to background the app (e.g. by dragging up from the bottom of the screen)
3. Note that the app doesn't switch to lock screen.

Outcome

What did you expect?

Expect the app screen to immediately switch to the lock screen as soon as the swipe begins, to stop folks from shouldersurfing contents in the task switcher, or screenshots of the app with sensitive content getting cached by the task switcher (and being used in the animation when the app is foregrounded, leaking content). The instant-hiding also makes the app feel more trustworthy with privacy.

If the app is fully backgrounded then when the app foregrounds again you'd expect to have to enter the PIN or FaceID. But if the backgrounding is cancelled (i.e. the user stops dragging upwards) there's no need to re-auth the user.

What happened instead?

People shouldersurfing when i task switch in my app (or when i foreground the app, prior to unlocking it) will see leaked sensitive content.

Your phone model

No response

Operating system version

No response

Application version

428

Homeserver

No response

Will you send logs?

No

[pixlwave]

@VolkerJunginger What say ye? I went with locking the app when the app is no longer active because it feels weird to me to obscure the content of the active app. It will create a handful of edge cases where some system UI (e.g. permission prompts) can result in the lock screen appearing when you aren't moving to the app switching, so the implementation might take a bit more effort than first meets the eye.

For reference the current behaviour:

Simulator.Screen.Recording.-.iPhone.14.-.2023-11-06.at.11.36.03.mp4

The requested behaviour:

Simulator.Screen.Recording.-.iPhone.14.-.2023-11-06.at.11.44.20.mp4

[VolkerJunginger]

I think the desired behaviour (not being able to "see" the content) described in the ticket is what we should go for. Your solution of locking the app is good.

I don't get the the edge cases. I suspect that showing a system dialog when the app is active (for example when asking for microphone access) is not a problem?

[pixlwave]

On the edge cases:

• We currently hide the content on didEnterBackground.
• The change means we need to do this on willResignActive.
• These system prompts etc sometimes take the focus so call willResignActive but don't finish the lifecycle with didEnterBackground as the app remains on screen.
• This means that some of those prompts result in the app appearing locked (behind the prompt) whilst the system UI is shown.

[ara4n]

this is a huge improvement - thank you :)