Almost every health app project starts with the same question: Flutter or React Native? It is the wrong question to ask first, and it is usually asked before anyone has written down what the app actually has to do with the phone.

Frameworks are not really the variable. Any serious cross-platform stack can render a screen, call an API, and store a record. What separates an easy build from a painful one is the capability list: which platform health store the app reads, whether it pairs with a Bluetooth device, whether it collects anything while the screen is off, and what regulated data passes through it. Write that list first and the stack decision mostly makes itself.

Here are the three tiers we see, and what changes at each one.

Tier one: content, tracking, and reminders

Symptom libraries, care plans, medication and hydration reminders, calculators, questionnaires, food and activity logs entered by hand. The device is a screen and a notification channel, nothing more.

This tier is genuinely solved. One shared codebase, one team, a straightforward release for both platforms, and a first version in weeks rather than quarters. The decisions that matter here are not technical. They are whether the content model can change without a store release, how the app behaves offline, and how the interface holds up for an eighty-year-old reading it at arm’s length, which is a design problem long before it is an engineering one.

If your app lives entirely in tier one, choose the framework your team already knows and spend the saved time on the content and the onboarding flow.

Tier two: the platform health stores

The moment the app reads steps, heart rate, sleep, weight, glucose, or workouts that another app or a watch recorded, you are talking to Apple HealthKit on iOS and Android Health Connect on Android.

These are not one integration with two names. They have different data types, different permission models, different rules about what you may do with the data afterwards, and different review expectations when you submit. Cross-platform frameworks reach them through plugins or bridges of varying maturity, and that maturity is the thing to check before you commit, not after.

The practical guidance: treat health store access as two integrations with a shared interface above them, budget for writing native code on at least one side, and test permission flows on real devices early. Permission denial is not an edge case in health apps. It is a normal state that a meaningful share of your users will sit in, and the app has to be useful anyway.

Tier three: devices, Bluetooth, and background work

Continuous glucose monitors, blood pressure cuffs, pulse oximeters, chest straps, connected inhalers, hearing devices, anything with a Bluetooth Low Energy profile. Add anything that must keep collecting while the app is backgrounded or the phone is locked.

This is where cross-platform stops being free. BLE behaves differently on the two platforms, background execution rules differ and change between OS versions, and reconnection after the user walks out of range is its own engineering problem. The shared-code promise still holds for your business logic and most of your UI, but the connectivity layer will contain real native code on both sides, written and tested against actual hardware.

None of that argues for two separate native apps. It argues for knowing about it in the estimate. Teams that get hurt here are the ones that priced a tier three app as a tier one app. If the device integration is the risky part, prove it first: a narrow proof of concept against the real hardware answers in weeks what a specification will argue about for months.

The current shortlist, and what is no longer on it

Three options are worth serious consideration. Flutter, which leads cross-platform usage at around 46% of surveyed developers and gives you tight control of rendering across both platforms. React Native, which draws on the largest hiring pool and suits teams that already write TypeScript. Kotlin Multiplatform, which shares business logic while leaving the interface fully native on each side, and which fits when native fidelity and native hardware access matter more than shared UI.

Two options that still show up in older planning documents should not. Microsoft ended support for all Xamarin SDKs, Xamarin.Forms included, on 1 May 2024, with .NET MAUI as the successor path. Apache Cordova style web wrappers remain workable for simple content apps but are a poor fit for anything touching sensors or health stores. If a proposal you are reading recommends either for a new health build, the proposal predates the current landscape.

Worth noting that only about a third of mobile developers use cross-platform tooling at all. Fully native remains a legitimate answer when the app is small in surface area and deep in device integration.

Regulated data changes the build, not just the paperwork

Health data drags in requirements that are easy to treat as a compliance appendix and expensive to retrofit.

Personal health information should never reach an analytics event, a crash report, or an application log. Data at rest on the device belongs in the platform keystore rather than in preferences or a plain local database. Sessions need sensible timeouts and re-authentication, because a phone is a shared and easily lost device. Access to records should be logged well enough to answer who saw what and when. Every third-party SDK you add is a party to the data, so each one needs a reason to be there and terms you have actually read.

Whatever regime applies to you, HIPAA, PHIPA, GDPR, or a provincial equivalent, these controls sit in the application architecture, not in a policy document. That is as true of the backend and the EHR integration as it is of the app.

Two stores, two review processes

Both app stores apply extra scrutiny to health claims, medical device association, and data handling disclosure. Expect to explain what your app does with health store data, and expect a rejection to cost a release cycle rather than an afternoon.

Build the store listings, privacy labels, and supporting documentation alongside the app rather than in the final week. On a two-platform release, the second review is the one that usually slips the date.

Decide the capabilities, then the stack

Write down every device capability the app depends on, mark each as tier one, two, or three, and choose the framework against that list. A tier one app should optimise for speed and cost. A tier three app should optimise for the hardest integration it contains, and be estimated accordingly.

247 Labs builds mobile applications for healthcare organisations across both platforms, including the health store and device work that the framework does not hand you. Get in touch if you want the capability list pressure-tested before the stack is chosen.