iOS and Android both support apps opting into keeping their data at rest while locked after first unlock. iOS makes this easier via dedicated data classes.
However, you would be very wrong if you assumed that meant this was better in the iOS ecosystem than the Android ecosystem.
Conversation
Replying to
I believe you are talking about Keyguard-bound keys in android. They don't seem to be equivalent to data class keys in iOS. Keyguard-bound keys are enforced by the OS and it remains in memory to encrypt incoming data while decrypt only when the screen is unlocked.
2
This is because TEE has no way to know when the screen is locked. This doesn't prevent post-AFU attacks because if the OS is compromised, so will be the key.
2
For per-app data at rest protection, Google recommends to opt system API in-app authentication (biometric or lock screen credential) together with "Require user authentication for key use" as explained here:
2
Replying to
It's better to use the more modern feature for making a hardware keystore key only available when unlocked rather than requiring user authentication. Molly uses StrongBox HSM when available and sets up the key this way by requiring unlocking. Integrates it with their passphase.

