fix(ios): relax AsyncStorage data protection to allow access while locked

[exodus-jee]

Summary

Fixes AsyncStorageError [Failed to write manifest file] / Failed to write value / Could not open the existing manifest on iOS, which locks users out of their wallet (exodus-mobile #39598). These have been reported across 6+ releases, predominantly iOS, with accelerating volume.

Root cause

The storage directory and its files are created without an explicit data protection class, so they inherit NSFileProtectionComplete (no file access while the device is locked). The app declares UIBackgroundModes: remote-notification, so iOS can wake it in the background while the device is still locked. When that happens, _writeManifest: / _writeEntry: / _ensureSetup cannot read or write the manifest and value files, and the failure propagates to JS as a permanent AsyncStorageError, blocking wallet open. The existing code already documents this exact scenario in _ensureSetup ("data protection is enabled ... while the device is locked ... started by the system even if the device is locked due to e.g. a geofence event").

Fix

Set the data protection class to NSFileProtectionCompleteUntilFirstUserAuthentication, which keeps the files accessible after the first unlock following boot, including while the device is later locked:

• _createStorageDirectory now creates the directory with that protection class, so new installs and newly written files inherit it.
• _ensureSetup applies it to the existing storage directory and its current contents once per setup, so existing installs are migrated to the relaxed class the first time the app runs while unlocked.

This is the standard fix for this RNCAsyncStorage data-protection issue and matches newer upstream defaults.

Security note

This relaxes AsyncStorage at-rest protection from "locked" to "after first unlock". That is acceptable here: secrets are not stored in AsyncStorage, and the directory is already excluded from backup. The trade is intentional, in exchange for not locking users out of their wallet.

Test plan

• Native build required (could not be compiled in this environment). Needs device QA: with data protection active, background-wake the app while the device is locked (e.g. push) and confirm manifest/value reads and writes succeed instead of throwing Failed to write manifest file / Could not open the existing manifest.
• Verify existing installs (directory created under the old class) recover after one unlocked launch.

Release

Bumps the package to 1.17.11-exodus.5. Tag/publish on merge, then bump @exodus/react-native-async-storage in exodus-mobile to pick it up.

[exo-mv]

so they inherit NSFileProtectionComplete

where do you see this? (not convinced it's true 🤔 )

[exo-mv]

docs say https://developer.apple.com/documentation/uikit/encrypting-your-app-s-files?utm_source=chatgpt.com

Complete until first user authentication. (Default) The file is inaccessible until the first time the user unlocks the device. After the first unlocking of the device, the file remains accessible until the device shuts down or reboots.

[exodus-jee]

@exo-mv

Yep, you're right, thanks for pushing on this. I checked and my root cause was wrong, so I'm closing this one.

What I confirmed:

• exodus.entitlements doesn't set com.apple.developer.default-data-protection (all 4 variants share that one file), so the Data Protection capability isn't enabled.
• That means our files already default to CompleteUntilFirstUserAuthentication, exactly like you said. So this PR sets the class to the value it already has, which is a no-op.

The failing window is also narrower than I wrote: under that class, files are blocked only before the first unlock after a reboot, not whenever the screen is locked. The one real failing case is a system background launch (we have remote-notification) before the user has unlocked since boot, which is the same scenario the existing _ensureSetup comment already mentions.

To actually cover that window you need NSFileProtectionNone (the only class readable before first unlock), which is a real at-rest tradeoff and wants a proper security sign-off, or you gate writes on isProtectedDataAvailable and flush later. Opened #5 for the None approach with the tradeoff written up, instead of dressing this one up. Thanks again.