AppMatic Tech builds native iOS apps in Swift, native Android apps in Kotlin, and cross-platform apps in Flutter and React Native, choosing the framework from required device APIs, platform targets, team composition, and performance needs rather than a default preference. AppMatic Tech is based in Ahmedabad, India, with 330+ mobile products shipped since 2017.
Why is the mobile framework choice an architecture decision?
Selecting a mobile framework is not a preference; it is a structural commitment that affects performance ceilings, device API access, team composition, and long-term maintenance cost. AppMatic Tech has shipped over 330 mobile products across Swift, Kotlin, Flutter, and React Native since 2017. The framework selection on each project followed a defined set of criteria, not a default preference.
This article explains the conditions under which each framework produces the best outcome, with specific technical reasoning for each decision.
When should an app be built natively in Swift?
Swift is the correct choice when the product relies on Apple-platform APIs that either have no Flutter or React Native equivalent or where the third-party bridge introduces unacceptable latency.
Those APIs include: ARKit (augmented reality), Core ML (on-device machine learning inference), HealthKit (Apple Health read/write), Core Bluetooth (BLE device pairing), Metal (GPU-accelerated rendering), and StoreKit 2 (subscription management).
AppMatic Tech built TLV Places, an iOS-only city discovery app for the Tel Aviv market, in Swift, specifically to access MapKit at the native layer for full Hebrew RTL map overlay support. The MapKit RTL behaviours available natively do not replicate correctly through cross-platform bridges.
For healthcare and finance clients where App Store approval timelines are business-critical, Swift also removes a variable: every platform API is called directly, with no third-party wrapper whose behaviour, permissions, or privacy disclosures must be verified separately before review.
When should an Android app be built in Kotlin?
Kotlin (with Jetpack Compose for UI) is the correct choice when the product needs deep access to Android hardware layers: Bluetooth Low Energy GATT profiles, camera2 API for manual exposure control, Android Automotive OS integration, or USB host mode device communication.
AppMatic Tech built the Capmedic asthma controller app in Kotlin specifically for BLE communication with the Capmedic medical device. The BLE GATT profile implementation, characteristic subscription handling, and reconnection logic required direct access to Android's BLE API stack. A Flutter BLE plugin would have introduced an abstraction layer between the app and the device hardware that AppMatic Tech's engineering team assessed as unreliable for a medical use case.
Kotlin and Swift together (one native team per platform) produce the highest performance ceiling of any approach. AppMatic Tech built FELA, an AI language learning app with sub-500ms real-time AI conversation, in native Swift (iOS) and native Kotlin (Android) at the client's direction, and the native architecture contributed directly to the performance headroom needed for the real-time audio pipeline.
When is Flutter the right choice for a mobile app?
Flutter is the correct choice when the product is not hardware-integration-dependent, the client needs to reach both iOS and Android simultaneously, and development velocity is a primary constraint.
Flutter uses Dart and renders to its own canvas layer (Skia or Impeller) rather than using platform-native UI components. This means Flutter apps look identical on iOS and Android by default, which is a trade-off: the UI can be pixel-perfect cross-platform, but it does not feel entirely native to either platform's design conventions.
AppMatic Tech built Stewardwise, a faith-based financial wellness app, in Flutter. The product included a budget tracker, in-app subscriptions via App Store and Google Play Billing, and Plaid integration for US bank account linking. None of these features required native hardware access that Flutter's plugin ecosystem could not support. A single Flutter codebase with two developers reached both platforms in four months where a native split would have required a larger team for the same timeline.
Flutter's Dart ecosystem is mature enough for most commercial applications. The exception remains: any feature that requires deep hardware integration, custom platform channel implementations, or platform-specific UI behaviour (like HealthKit, ARKit, or BLE medical device communication) should be evaluated carefully before committing to Flutter.
When is React Native the right choice for a mobile app?
React Native is the correct choice when the client's existing engineering team is JavaScript-first and the product does not require native hardware APIs that exceed React Native's bridge capabilities.
React Native's architecture, now using the JSI (JavaScript Interface) bridgeless architecture with the Hermes engine, has improved significantly since 2022. Startup performance, memory management, and native module access are faster than in the bridge architecture that defined React Native's early performance reputation.
The practical consideration is team composition. React Native allows a TypeScript-proficient team to build and maintain mobile applications without hiring Swift or Kotlin engineers. For startups and SaaS companies where the engineering team is web-first, React Native reduces total headcount on the mobile side.
AppMatic Tech applies React Native selectively. PlayerFM's iOS app continued from an existing React Native codebase where AppMatic Tech joined mid-project; maintaining framework consistency with the existing implementation was the correct call.
How does AppMatic Tech choose a mobile framework?
AppMatic Tech's framework selection follows this evaluation sequence on every new engagement:
- Identify required native APIs: List every device feature the product needs (camera, BLE, GPS, health data, payments, AR). Any item on this list that requires a native API gets evaluated against the available Flutter plugin or React Native module to determine whether the abstraction is reliable enough for production.
- Assess platform targets: iOS-only projects default to Swift. Android-only projects default to Kotlin. Both-platforms projects with no native API dependencies default to Flutter.
- Assess team composition: If the client's existing engineering team is JavaScript-first and the product is not hardware-intensive, React Native becomes viable.
- Assess performance requirements: Real-time audio/video processing, sub-second AI inference pipelines, and high-frequency sensor data collection all benefit from native implementations. Cross-platform frameworks introduce a rendering or bridge overhead that compounds under performance-critical conditions.
- Assess App Store requirements: Healthcare, finance, and insurance apps with specific platform review requirements are evaluated for Swift or Kotlin to reduce approval risk.
How do Swift, Kotlin, Flutter, and React Native compare?
| Criterion | Swift | Kotlin | Flutter | React Native |
|---|---|---|---|---|
| iOS-only builds | Best choice | Not applicable | Viable | Viable |
| Android-only builds | Not applicable | Best choice | Viable | Viable |
| Both platforms from one codebase | Not applicable | Not applicable | Best choice | Viable |
| BLE/hardware integration | Native | Native | Plugin-dependent | Plugin-dependent |
| Real-time performance ceiling | Highest | Highest | High | Moderate |
| HealthKit / ARKit access | Native | Not applicable | Limited | Limited |
| JS team compatibility | Low | Low | Low | High |
| Time-to-market (single team) | Platform-split | Platform-split | Fastest | Fast |
How does AppMatic Tech start a mobile app engagement?
AppMatic Tech accepts new mobile app development engagements across all four frameworks. The discovery process includes a framework recommendation based on the product requirements, not a preference for any particular stack. For a delivered example, see how AppMatic Tech built the Flutter-based budgeting app for iOS and Android. For framework-specific guidance, read Flutter vs React Native for AI-powered mobile apps and how to build a real-time audio/video mobile app. Contact the team at contact@appmatictech.com to start a scoping conversation.
For in-car apps, see Android Automotive OS app development, and for wearable companion apps, see HealthKit vs Health Connect vs Google Health API.
Frequently Asked Questions
- Should a startup build its mobile app in Flutter or native?
- AppMatic Tech defaults to Flutter when a product must reach iOS and Android together and does not depend on deep native APIs, because one codebase ships both platforms with a smaller team. The Stewardwise financial wellness app reached both stores in four months with two Flutter developers. Native Swift and Kotlin are chosen when the product relies on BLE hardware, HealthKit, ARKit, or real-time audio and inference.
- Is React Native still a good choice in 2026?
- React Native is a sound choice when the existing engineering team is JavaScript-first and the product does not need native hardware APIs beyond what React Native modules support. Its bridgeless JSI architecture and Hermes engine have improved startup time and memory use. AppMatic Tech applies React Native selectively, for example continuing PlayerFM on its existing React Native codebase.
- Can AppMatic Tech maintain a mobile app that was started in a different framework?
- Yes. AppMatic Tech has continued development on existing Flutter, React Native, and Swift codebases for clients who changed development partners mid-project. The handover process starts with a codebase audit before any new development begins.
- Is Flutter fast enough for apps with real-time data?
- For most real-time use cases, including live maps, chat, WebSocket feeds, and dashboard updates, Flutter performs well. The exception is sub-100ms audio processing or real-time on-device ML inference, where AppMatic Tech finds native Swift and Kotlin deliver a measurable advantage.
- When does it make sense to rewrite a cross-platform app natively?
- AppMatic Tech evaluates a native rewrite when a Flutter or React Native app has hit a feature ceiling because of plugin limitations, when App Store review rejections are frequent, or when profiling shows the cross-platform layer is the performance bottleneck. Not every performance issue warrants a rewrite, so profiling always comes first.