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.
1
5
23
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
Replying to
You would need to ask Molly's lead developer.
Our approach for the standalone GrapheneOS apps is publishing the main releases signed with our keys through our own app repository and defining a .play suffixed app id for releases through the Play Store using Play Signing.
1
3
For example, our Camera app included in GrapheneOS and our app repository is app.grapheneos.camera. We publish it as app.grapheneos.camera.play on the Play Store. New apps on the Play Store need to use Play Signing with a developer key only use to sign the uploaded app bundles.