If you’re a founder weighing Flutter vs native for healthcare app development, you’ve probably heard two confident answers. One agency says Flutter, one codebase, half the cost. Another says health apps must be native, full stop. Both skip the detail that decides it: in a health or fitness app, the hardest parts are native no matter which framework draws your screens.
We build health and fitness apps in Flutter with Swift and Kotlin underneath, and we work in fully native and React Native code too. So we don’t have a framework to sell you. Here’s how we’d think it through for your product.
What’s native in every health app, whatever you pick
Look at what a typical health or fitness app touches:
- Apple HealthKit and Android Health Connect. Two different APIs with different permission models. On iOS, your app can’t even tell whether a user denied read access.
- Background sensors. GPS during a run, step data, workout sessions. Android needs a foreground service, iOS needs background modes, and both have rules the framework can’t hide.
- System surfaces. Home-screen widgets, lock-screen widgets, Live Activities and the Dynamic Island. On iOS these are written in SwiftUI. There’s no Flutter or React Native version of them.
- Store review. Apple’s guideline 5.1.3 limits how health data can be used and where it can be stored. Google Play wants a declaration of every Health Connect data type you touch.
In Crumb Count, our nutrition app, the Flutter code is a large codebase (over 82,000 lines across 13 feature modules), and it still talks to Swift and Kotlin through platform channels for Live Activities, the Dynamic Island, lock-screen widgets, HealthKit and Health Connect. Kompete, our running app, uses platform channels for background location and map rendering. That’s normal. A cross-platform health app is a shared app with a native layer, so the real question is who on your team can write that native layer well.
Flutter vs native for healthcare app builds: when each one wins
Choose native (Swift and Kotlin) when
- You’re launching on one platform only. An iPhone-first product with no Android plan for a year gets nothing from a cross-platform layer. Write it in Swift.
- The product lives in system surfaces. If most of the value is in widgets, a watchOS app or deep Siri and Shortcuts integration, you’ll write that in Swift anyway. The shared part is too thin to be worth it.
- You’re doing heavy on-device signal processing. Continuous sensor streams processed in real time sit closer to the metal. You can do this from Flutter through native code, but at some point the native code is the app.
- You already have strong native teams. Don’t retrain two good teams to save money on a third.
Choose Flutter (or React Native) when
- You need iOS and Android at launch. Most consumer health products do, and in markets like India, Android is the majority of your users.
- Most of the app is screens, forms, charts and logic. Logging, plans, progress charts, onboarding, settings, payments. That’s most of a health app’s surface, and writing it once is a real saving.
- You want one team moving fast. A small team that owns both platforms ships features to both at once, without a second team half a sprint behind.
- Offline behaviour has to match on both platforms. Sync and conflict rules written once behave the same everywhere. Crumb Count’s offline-first sync, with its nine per-datatype conflict policies, is shared Dart code.
Flutter or React Native? Both work. Flutter gives you more consistent rendering across devices and a strong story for custom charts and animation. React Native fits better if your team is already deep in React on the web. Either way, the native-layer question above still applies.
What doesn’t change with the framework
Founders sometimes ask whether native is “more secure” or “more compliant”. The framework barely matters here. What matters:
- Where the data goes. What leaves the device, which third-party SDKs see it, and where it’s stored. An analytics SDK that receives health values is a problem in any language.
- Consent you can prove. If you rely on consent under GDPR, you need a record of who agreed to what and when. A checkbox value that sync can overwrite won’t do.
- Your backend and your vendors. Regulations like HIPAA in the US apply to how your organisation and its vendors handle health information. No framework or agency makes your app compliant by picking a stack. Get proper legal advice for your market, and be wary of anyone who promises compliance as a feature.
- Server-side AI. If you add AI features, keep model keys and choices on your server with per-user limits. Crumb Count’s AI meal logging runs through a server-side proxy for exactly this reason.
Questions to ask whoever builds it
- Show me a shipped app where you wrote the HealthKit or Health Connect integration yourselves.
- Who on the team writes the Swift and Kotlin parts, and have they shipped widgets or background services before?
- How will offline use and sync conflicts work?
- What health data will leave the device, and to whom?
- What happens at App Store review, and how have you handled rejections before?
A good answer to these matters more than the framework name on the proposal.
orithLabs is a two-founder studio, and the two of us who scope the work also write it. If you’d like a plain opinion on your health or fitness app’s stack before you commit, take a look at our mobile development service, or see how we built Crumb Count.