Adding an AI feature to a mobile app comes with an architecture decision that's too often made casually: native, cross-platform, or a web wrapper embedded in the app. It isn't just a technical preference. It directly affects how the feature feels, how fast it ships, and how much it costs to maintain, and the right answer depends on specifics worth being deliberate about.
The three options
Native (Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android)
Built directly against each platform's own UI framework and APIs. This gives the tightest integration with platform-specific capabilities (camera, on-device ML runtimes, background processing) and the most consistent feel with the rest of a native app, at the cost of maintaining two separate codebases.
Cross-platform (React Native, Flutter)
One codebase targeting both platforms. Faster to build and maintain for straightforward UI, with a real but usually smaller performance and platform-integration gap than it used to have. The gap widens for features that need deep, low-level platform access, like real-time camera processing for on-device inference.
Web wrapper (a webview embedding a web app inside the native shell)
This is the fastest to ship, because it reuses web code directly, but it introduces a real seam. Performance, animation feel, and platform integration (camera, push notifications, background tasks) are all more limited, and the feature tends to feel like a separate product stapled onto the app rather than a native part of it.
What actually determines the right choice
Does the feature need real-time, low-level platform access?
Real-time camera-based inference, like pose estimation or object detection running continuously during active use, has genuine latency requirements that push hard toward native. A webview, and to a lesser extent cross-platform frameworks, add an abstraction layer between the app and the camera or ML runtime that this kind of feature often can't tolerate.
Does it need on-device inference?
On-device ML runtimes (Core ML on iOS; LiteRT, formerly TensorFlow Lite, on Android) are most directly and reliably accessed from native code. Cross-platform frameworks have improving but still less mature bridges to these runtimes, and a webview can't use them directly at all.
How much does interaction feel matter for this specific feature?
A background utility feature (a settings screen, a simple data view) can tolerate a less native feel without users noticing much. A core, frequently-used interactive feature, especially one where the AI response needs to feel instant and fluid, benefits meaningfully from native-level polish.
What's your existing codebase and team?
If you already have a mature native codebase and native mobile engineering capability, extending it natively is usually both faster and more consistent than introducing a new framework or a wrapper pattern just for the AI feature. If you're starting from scratch with a small team, cross-platform can be the pragmatic choice for the broader app, even if a specific AI feature eventually needs a native module.
The mistake to avoid
Choosing the fastest-to-ship option (usually a webview) for a feature that actually needs native-level performance or platform integration is a common way teams end up rebuilding a feature later, once the limitations become a real product problem. Be explicit about the feature's technical requirements before defaulting to the option that feels fastest.
How we approach this
We evaluate the specific feature's latency, platform-integration, and interaction-quality requirements before recommending an architecture, rather than defaulting to whichever approach is fastest to prototype.