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.
Replying to
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
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
Show replies
Replying to
I couldn’t get phone carriers to care about pushing android updates. The sole reason I went to iOS was I could get updates when apple released them. Waiting for sprint, T-Mobile, Verizon, etc to “process” the update and push it was taking 6+ months. That’s just stupid.
1
Replying to
Android is an operating system family, not a specific OS, and what you're describing does not apply to non-carrier phones. It doesn't even apply to phones like a Pixel sold as a locked device by a carrier. That's not an iOS vs. Android comparison at all.
1
2
Show replies