By default, Apple provides a robust implementation of Full Disk Encryption (FDE) on it’s iOS devices. The way this works is when the device is in a pre-first-boot non-authenticated state the encryption is enforced. Once the phone is post-first boot authenticated the data is decrypted entirely - even if the phone is “locked”. This is an inherent limitation of FDE and not a fault in Apple’s implementation of it. Aware of this, Apple provides an API called “Data Protection Classes”. By default, apps are assigned a
NSFileProtectionCompleteUntilFirstUserAuthentication class which means data is decrypted if phone is post-first boot authenticated. Developers have the option to opt into a higher data protection class such as ‘NSFileProtectionComplete’ or ‘NSFileProtectionCompleteUnlessOpen’ (which is what the default Mail App uses) to enforce encryption once the app is closed. The purpose of this API is to provide protection to data in such scenarios that the device is compromised in a post-first boot state. Smartphones are almost permanently in this state. Thus, FDE only provides limited protection under certain specific conditions. Should a user plug a phone into a malicious public charging station, have a device taken in a post first boot authenticated state and subjected to commercially available software that can perform a logical acquisition or download a compromised third party app which can exploit and bypass Apple sandboxing measures data contained in Apps from developers which use the optional elevated API remains protected.
This is not true application level encryption like Standard Notes or Bitwarden offers but a easy way for developers to achieve similar security posture with little effort. Ideally an application will implement true application level encryption for data at rest in an app when closed like Standard Notes or Bitwarden.
My question is what measures does the iOS version of Joplin implement for data at rest at the application level?