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
Signal doesn't ever put data back at rest after first unlock on either iOS or Android. Making it easier for developers to implement a feature directly with the platform APIs still depends on them choosing to do it...
github.com/mollyim/mollyi implements this for Signal on Android.
1
5
14
github.com/mollyim/mollyi explains the implementation. It's primarily based around a passphrase with the hardware keystore as an additional layer of security, but apps can also implement this directly with the hardware keystore with a key set to require that the device is unlocked.
1
2
16
Android is better at making complex things possible in these areas than iOS but is missing an easier to use declarative approach to make simple things simple.
In the end, what mattered is that the open source platform has a far more active open source app and library ecosystem.
Replying to
Molly was implemented by a GrapheneOS community member and we've collaborated with them.
GrapheneOS can only exist because AOSP is open source. Molly could exist for iOS, but it doesn't and probably won't in the near future, and you won't convince Signal devs to care about this.
3
4
22
We've been talking to them about the possibility of optional hardware attestation support in Molly where you can opt into mutually verifying hardware/firmware/software and automatically preventing sending messages if it fails verification or the patch level ends up months behind.
1
2
12
This would be able to use a subset of our work on our Auditor app (attestation.app/about) and would be able to take advantage of the fancy new attest key feature which we proposed to Android a few years back and which ended up actually getting shipped for Android 12 / Pixel 6.
2
11