Where We Started: Native All the Way
ME-Tech has built mobile apps since the early smartphone era. Our first iOS projects ran on Objective-C; our first Android apps on Java. For a long time, native was the only serious option for enterprise-grade mobile work — the platform SDKs were the only reliable path to the performance, camera access, background processing, and push notification handling our clients required.
Through most of the 2010s, we maintained separate iOS and Android teams. Two codebases, two sprint tracks, two sets of App Store and Play Store submissions. The overhead was real but accepted — that was simply how serious mobile development worked. Our clients in aviation, loyalty programmes, and telecoms expected native-quality apps, and we delivered them.
The Cross-Platform Search Begins
The first cracks appeared as client budgets tightened and feature parity expectations increased. Clients wanted identical experiences on both platforms simultaneously — not "iOS first, Android six weeks later." The cost of maintaining synchronised native codebases started to outweigh the benefits for many of the app categories we were building: forms-heavy enterprise tools, loyalty dashboards, booking flows.
We evaluated every serious cross-platform option as it emerged. PhoneGap and Cordova were early experiments — the WebView wrapper approach produced apps that felt like websites, not software, and we quietly retired them after the first few client pilots. The gap in scroll physics and touch responsiveness alone was disqualifying for our standards.
The Xamarin Years
Xamarin arrived as the most credible cross-platform contender for enterprise mobile work. C# across iOS and Android, direct bindings to native APIs, genuine compilation to native ARM code rather than a WebView wrapper. For a consultancy already working with .NET clients, the pitch was compelling.
We shipped two internal tools and one client project on Xamarin.Forms between 2016 and 2019. The experience was instructive in ways we did not initially anticipate.
What Xamarin Got Right
- Shared C# business logic genuinely reduced duplication — model layers, API clients, and validation were written once
- Native API access via bindings was reliable for the hardware features we needed
- The .NET ecosystem (NuGet, tooling, debugging) was mature and familiar to our backend engineers
Where It Fell Short
- Xamarin.Forms UI abstraction leaked constantly — platform-specific renderers were needed for almost every non-trivial UI component
- App bundle sizes were large; the Mono runtime added overhead that was difficult to explain to clients reviewing their App Store listings
- Build times on our CI pipeline were painful — a clean iOS build routinely exceeded 20 minutes
- Microsoft's acquisition trajectory created strategic uncertainty that materialised when Xamarin was folded into .NET MAUI — a migration with real engineering cost
- The community was smaller than we needed; third-party component quality was inconsistent
The Xamarin chapter taught us that shared business logic is a tractable problem — the hard part is shared UI. An abstraction layer over two different rendering systems produces apps that feel native to neither platform. We needed something with a different approach to the rendering problem.
Why Flutter Changed Our Thinking
We piloted Flutter in late 2019, initially sceptical. Dart was an unfamiliar language; Google's previous mobile framework experiments had not inspired confidence. We assigned a two-person team to rebuild one of our internal SenangApps screens as a Flutter prototype, budgeting two weeks.
The prototype was finished in four days and looked better than the original.
The architectural difference that matters: Flutter does not use platform UI widgets at all. It ships its own rendering engine (initially Skia, now Impeller on iOS and progressively on Android) that draws every pixel directly to the canvas. This means a Flutter app looks and behaves identically on iOS and Android — not because it's wrapping native components, but because it's rendering its own. There is no "Xamarin.Forms renderer gap" to paper over.
- Widget composition model maps well to how our designers think about UI — components nest predictably
- Hot reload in development is genuinely instant; the iteration loop between code change and visual feedback collapsed to seconds
- Dart is straightforward to learn; our team was productive within two weeks
- The Impeller renderer delivers consistent 60/120fps on modern devices without the jank patterns we saw in React Native's bridge architecture
- A single codebase targets iOS, Android, and — increasingly — web and desktop from the same source
Rebuilding SenangApps in Flutter
The decision to rebuild the SenangApps suite in Flutter was made in 2020 and completed over 18 months. ServisJer, SewaJer, SewaJer Pemilik, MakanJer, RogerBro, and TripPax are all now Flutter-native. The migration was not painless — Dart's null safety migration caught a class of runtime bugs we had been tolerating in the Dart 1.x codebase, and the widget layer required a full redesign rather than a port.
The outcomes justified the investment. Across the six apps, we reduced the total mobile codebase from approximately 180,000 lines across separate iOS and Android projects to around 95,000 lines of Dart with shared state management using Riverpod. Feature development that previously required parallel implementation now requires one. Our iOS and Android App Store release cycle is a single build pipeline.
The real productivity gain isn't in writing less code. It's in debugging one codebase, reviewing one PR, and carrying one mental model of how the app works.
Flutter for Client Engagements
We began offering Flutter as the default recommendation for new client mobile projects in 2022. The reception has been positive — most enterprise clients care about cost, timeline, and quality, not which framework is under the hood. Flutter delivers on all three.
The client-facing pitch is straightforward: one team, one codebase, identical UI on both platforms, delivered faster than equivalent native builds. We've now completed four client engagements in Flutter spanning loyalty app rebuilds, a logistics tracking interface, and an internal enterprise tools project. Post-launch defect rates have been lower than our historical native baselines, which we attribute partly to the type safety Dart provides and partly to the consistency of behaviour across platforms eliminating an entire class of "works on iOS, broken on Android" bugs.
Where We Are Now — and Re-evaluating React Native
Flutter 3.x has matured into a stable, well-supported platform. The community has grown considerably since our 2019 pilot — pub.dev now hosts over 40,000 packages, and the critical integrations (payments, maps, push notifications, camera, biometrics) are all well-maintained. For ME-Tech, the Flutter bet has paid off across both the SenangApps suite and client engagements.
That said, we are actively re-evaluating React Native for specific use cases where it offers genuine advantages over Flutter. This is not a reversal — Flutter remains our default for new greenfield mobile projects — but the landscape has shifted enough that a blanket recommendation no longer serves every client well.
The use cases where React Native is back on our evaluation list:
- Over-the-air (OTA) updates via Expo — the ability to push JavaScript bundle updates without an App Store review cycle is a meaningful operational advantage for apps that require frequent hotfixes or rapid A/B testing. Flutter's compiled nature means full app store releases for every change.
- Clients with existing React Native codebases — rewriting working software carries real cost and risk. Where a client has an established RN codebase with a functioning team, we can add value without requiring a framework migration.
- Teams with deep JavaScript/TypeScript expertise — React Native's JavaScript layer means a web engineering team can become mobile-capable faster than learning Dart and the Flutter widget model from scratch.
- Projects requiring tight npm ecosystem integration — certain categories of tooling (analytics SDKs, content management, A/B testing platforms) have more mature React Native bindings than Flutter equivalents.
We expect to complete our first React Native evaluation engagement in Q3 2026 and will publish a comparative findings post once we have production data. The goal is an honest, evidence-based framework choice for each project — not loyalty to any single tool.