Technology risk assessments comparing mobile development approaches for financial services applications — attack surface, supply-chain exposure, and regulatory analysis for Canada (OSFI) and United States (NIST / FFIEC / OCC).
- React Native vs. Native Mobile Development: Security Risk Assessment
- Flutter vs. Native Mobile Development: Security Risk Assessment
- Kotlin Multiplatform vs. Native Mobile Development: Security Risk Assessment
Bottom line: all three cross-platform approaches add security surface over pure native, but not by the same amount or in the same way. Kotlin Multiplatform sits closest to native, Flutter is a distant second, and React Native carries the largest and most actively exploited gap of the three.
| React Native | Flutter | Kotlin Multiplatform | |
|---|---|---|---|
| Architecture vs. native | JS engine + bridge/JSI layer between app logic and OS | AOT-compiled Dart, no bridge, but a separate Skia-based UI renderer | Compiles directly to native code (JVM bytecode / Kotlin-Native); UI stays fully native in standard config |
| Dependency ecosystem | npm — millions of packages, install-time script execution, repeated large-scale compromises | pub.dev — ~35K packages, no npm-scale incident history | Maven/Gradle — the same ecosystem native Android already depends on |
| Supply-chain incident history | Repeated, escalating: Metro RCE (CVSS 9.8), GlueStack backdoors, Glassworm ×2, Shai-Hulud | None publicized at npm's scale; one patched SDK-level path-traversal issue | One incident (Nov 2025), but via a narrow npm-mirroring bridge (mvnpm), not organic compromise |
| Code readability if extracted | JS bundle ships essentially as plaintext | Compiled AOT binary, harder to read but not immune (reFlutter) | Genuine native binary — same reverse-engineering effort as native |
| Secure storage | Not built in — manual wiring required | Not built in — requires flutter_secure_storage | Keychain/Keystore reachable directly via expect/actual |
| Path to Secure Enclave / App Attest | General-purpose JS bridge — largest intermediary layer | Purpose-built Dart platform channels — narrower | expect/actual resolves at compile time — no runtime bridge |
| Financial-services precedent | Intuit, Airbnb moved away; no security breach cited, but overlapping failure modes | Strong and growing: Nubank, ING, Credit Agricole, SoFi, Betterment — no security-driven retreat found | CIBC actively migrating tier-1 banking apps; Netflix, Philips, VMware |
- Supply chain is the deciding factor, not runtime architecture. All three frameworks are compiled or near-compiled at the UI/logic level today; what actually separates them is whether their dependency ecosystem has a demonstrated history of install-time compromise. npm does, at scale and repeatedly; pub.dev and Maven largely don't.
- "Cross-platform" is not one risk profile. KMP's logic-only-sharing model is architecturally a different category from React Native's and Flutter's full-app-replacement model — treating all three as equivalent "cross-platform risk" understates how close KMP sits to native.
- No framework eliminates the need for native security-critical code. Every report converges on the same recommendation: keep Secure Enclave key generation, App Attest, and biometric-gated unlock in native, platform-specific modules regardless of the framework chosen for the rest of the app.
- AI-accelerated attacks are an npm-ecosystem story first. The 2.6–4.5× growth in supply-chain campaigns (H1 2026 vs. 2025) is overwhelmingly landing on npm; Flutter and KMP teams are exposed mainly through shared developer tooling (AI coding agents, Node-based CLIs), not through their own package registries.
- Regulatory scrutiny scales with dependency-tree size and behavior. OSFI B-10's "fourth-party" concentration-risk language maps most directly onto npm's deep transitive tree, moderately onto pub.dev, and least onto Maven/Gradle, since KMP doesn't introduce a new ecosystem beyond what native Android review already covers.
- Adoption precedent favors Flutter and KMP over React Native for this use case. React Native's best-documented financial-services precedent (Intuit) moved away from it; Flutter and KMP both have active, undamaged bank/fintech deployments, including CIBC's own KMP migration.
For applications handling authentication, regulated transactions, or financial data:
- Native (Swift/Kotlin) — smallest attack surface, default choice for the most sensitive surfaces.
- Kotlin Multiplatform — defensible for cross-platform efficiency with minimal added security review scope; keep security-critical flows native.
- Flutter — defensible for lower-to-moderate-sensitivity surfaces with mandatory obfuscation and explicit secure-storage implementation.
- React Native — highest risk of the three; if used, restrict to low-risk surfaces and treat dependency-pinning, SBOM auditing, and lockfile-integrity controls as mandatory, not optional.