Android Activity and iOS app lifecycle are not interchangeable
Prerequisites: 04-platform-ownership, 08-expo-dsl
Platform lifecycle forks
Request state machine
Mental model verified
Expo’s hooks distinguish iOS app foreground/background from Android Activity foreground/background/destruction. Android coroutines can be tied to lifecycle scopes; UIKit work uses main-thread APIs, and Swift MainActor can express UI isolation.
[S12] [S16] [S17] [S18]Worked flow synthesis
A biometric prompt begins, then the app backgrounds. On Android, handle Activity lifecycle and a cancelled or deferred result; on iOS, handle app state and SDK callback. Both paths should settle or explicitly cancel the JS request once, with a stable result shape.
[S12] [S16] [S17]Engineering decision synthesis
Model pending, completed and cancelled states; clean up native listeners and avoid retaining stale view or Activity references. Test denial, background, process death and app relaunch as relevant.
[S12] [S16] [S18]Failure mode and improvement synthesis
A pending Promise that never resolves after dismissal is a UX and resource bug. Track request IDs and terminal states; verify each path settles exactly once.
[S12] [S16]Check yourself: Can a module assume an Activity that launched a request still exists when it returns?
No. The Activity may pause, be destroyed or be recreated; the module must handle missing owners and cancellation.