My primary mobile experience is Flutter. I would approach a healthcare application by testing its difficult requirements before recommending a framework. This article is an engineering evaluation, rather than a case study of a healthcare product I have delivered.
A booking interface, a video consultation, and an application connected to specialist hardware have very different risks. A useful comparison starts by separating those workflows and identifying who will maintain them.
Begin with the team and the integration
Flutter can be a reasonable choice for a team comfortable with Dart and its UI model. React Native can be a reasonable choice for a team with relevant React Native experience. Existing React web experience is useful context, but it does not by itself cover mobile permissions, native integrations, signing, or store delivery.
Before deciding, check the specific SDKs the product depends on. Does the vendor support your target iOS and Android versions? Are its Flutter or React Native bindings maintained? Who owns the integration if an operating-system update breaks it?
Flutter supports communication with platform-specific code through platform channels. That is an integration mechanism, not a guarantee that a particular medical device or vendor SDK will work. Test the real combination early.
Prototype the difficult workflow
A convincing proof of concept should exercise the riskiest part of the product. For a video consultation, that may include permission refusal, interruption, poor connectivity, and reconnecting. For a hardware connection, test the intended device instead of relying on a simulated screen.
Agree the conditions under which the prototype passes. Measure on representative phones in release builds. Do not infer battery use, responsiveness, or reliability from framework reputation or a development-mode demo.
Evaluate accessibility and bilingual use
Use the same acceptance criteria for both candidates: readable text at enlarged sizes, screen-reader labels, clear focus, usable controls, and understandable errors. Include people who will use the product in the evaluation where possible.
For an Arabic and English app, test navigation direction, text expansion, dates, phone numbers, and mixed-language content. Neither a language switch nor a mirrored screenshot proves that the whole journey works. Appointment creation, cancellation, confirmation, and recovery from an error all need attention.
Keep data handling a separate decision
The framework does not establish the product’s data-handling obligations. Map what information is collected, where it travels, where it is stored, and which people or services can access it. Confirm the applicable requirements with the organisation’s privacy, security, and regulatory specialists before choosing infrastructure.
On the engineering side, avoid putting service secrets in a mobile bundle or including sensitive records in diagnostic logs. React Native’s security guidance discusses these risks and the difference between general application storage and storage suited to sensitive information. The same questions belong in the review of any mobile architecture.
Compare ongoing responsibility
A useful decision record includes the tested integrations, unresolved risks, maintenance owner, and release process. It should also explain what would cause the team to revisit the choice.
I would choose the stack the team can support under the actual product constraints, then invest in the API contract, error handling, device testing, and release discipline. Those are areas I work on in DocPort’s logistics workflows and The Deal mobile application, even though their domains differ from healthcare.
