Problem
tests/storage/secureStorage.test.ts fakes react-native-keychain entirely with an in-memory Map, so no test exercises the real iOS Keychain or Android Keystore.
A regression in the keychain interaction or a wrong access-control flag would not be caught by this suite.
Expected
Integration tests that run against a real simulator/emulator using the actual platform Keychain/Keystore, run as a release gate rather than standard CI.
This library has no ios/android native project (Expo-managed, no bare app shell), so this can't run from this repo directly - wdk-examples/react-native-showcase has a real app shell and is the natural place to host it.
If that's not feasible short-term, at least document in docs/security.md which properties (access-control flags, on-device encryption-at-rest) are only validated by manual testing.
Problem
tests/storage/secureStorage.test.ts fakes react-native-keychain entirely with an in-memory Map, so no test exercises the real iOS Keychain or Android Keystore.
A regression in the keychain interaction or a wrong access-control flag would not be caught by this suite.
Expected
Integration tests that run against a real simulator/emulator using the actual platform Keychain/Keystore, run as a release gate rather than standard CI.
This library has no ios/android native project (Expo-managed, no bare app shell), so this can't run from this repo directly - wdk-examples/react-native-showcase has a real app shell and is the natural place to host it.
If that's not feasible short-term, at least document in docs/security.md which properties (access-control flags, on-device encryption-at-rest) are only validated by manual testing.