Cross-platform or native: decide on the constraint, not the fashion
Flutter and React Native are excellent for the large majority of enterprise applications, and the shared-codebase economics are real. They stop being the right answer at specific boundaries: deep biometric and secure-enclave integration, hardware-backed key attestation, background processing with strict platform-specific behaviour, and some device-integration requirements in clinical settings.
We choose per project against those constraints. Occasionally the answer is a cross-platform app with a native module for exactly the part that needs it, which keeps the economics without pretending the constraint does not exist.
Offline is a product decision before it is a technical one
Field operations apps and wallets in areas with unreliable connectivity fail in the same way: someone assumes network availability, then bolts on caching, then discovers that the real problem is conflict resolution. Two users edited the same record offline — which one wins, and who is told?
That is a product decision with regulatory implications in financial and clinical contexts, and it needs answering before the sync layer is written. We surface it early rather than letting it be settled implicitly by whichever write arrives second.
Mobile security in regulated contexts
For wallets and clinical apps the relevant controls are concrete: certificate pinning, secure-enclave or Keystore-backed credential storage, jailbreak and root detection calibrated so it does not lock out legitimate users, no protected data in logs or crash reports, and a session model that survives real usage patterns rather than the ideal one in the specification.
App store review is also a schedule dependency, not an afterthought — particularly for health and finance categories, where additional documentation is routinely requested.
Choosing native or cross-platform on the actual constraint
This decision is usually argued on developer preference and settled on cost. Neither is the right axis. The question that matters is how much of the product depends on platform capability that cross-platform frameworks reach late or imperfectly — deep background execution, specialised hardware, biometric and secure-enclave behaviour, or heavy real-time graphics.
Where an application is mostly presenting data, capturing input and calling services, cross-platform is straightforwardly the better economics: one codebase, one set of business logic, consistent behaviour. Where the product lives close to platform capability, the cross-platform saving evaporates into bridging code that is harder to maintain than two native implementations would have been.
We would rather have this conversation before the estimate than after the first platform-specific requirement lands.
Offline is a data-model decision, not a caching feature
Teams frequently plan to add offline support later, which is rarely possible, because offline capability is determined by whether the data model tolerates divergence and reconciliation rather than by whether responses are cached.
The hard question is what happens when two devices change the same record while both are disconnected. Last-write-wins is simple and silently destroys data. Anything better requires deciding, per entity, what a conflict means and who resolves it. That is a domain decision, and it has to be taken before the schema is fixed.
For field and clinical applications, where connectivity is genuinely unreliable, this is the single most consequential design decision in the product.
Security on a device you do not control
A mobile application runs on hardware the user owns, which may be rooted, shared, or compromised. Anything the client can decide, an attacker can decide. Authorisation is therefore enforced server-side without exception, and the client is treated as a rendering surface rather than as a trust boundary.
Credentials and tokens belong in platform secure storage rather than in application preferences, session lifetimes are short with silent refresh, and sensitive data is not written to logs, screenshots or crash reports — all three of which routinely leak more than teams expect.
For financial and health applications we also assume the device may be shared, which changes session and notification design: a push preview that reveals a balance or a clinical detail on a lock screen is a disclosure.
What is included
- Native iOS (Swift) and Android (Kotlin) development
- Cross-platform development in Flutter and React Native
- Offline-first architecture and conflict resolution design
- Biometric authentication and secure credential storage
- Certificate pinning and mobile threat mitigation
- Payment and wallet integration including RAAST
- Clinical-grade video for telemedicine
- Push notification and messaging infrastructure
- App store submission and review support
Technologies and standards
Related case studies
- RAAST-Enabled Digital Wallet Built for Unreliable Networks — A consumer wallet with RAAST instant payments, where settlement finality and offline conflict resolution were design decisions rather than late discoveries.
- Telemedicine Platform Built for Low-Bandwidth Consultations — Telemedicine where the video stack was designed for the network the patients actually have, not the one in the specification.