When a business owner contacts us about building a mobile app, one of the first questions is usually: "Can you do it in Flutter?" Sometimes they've read about it online. Sometimes a friend recommended it. Sometimes they just want it done fast and cheap.
Our answer is always honest: we build with Swift for iOS and Kotlin for Android — and increasingly with Kotlin Multiplatform for projects that need both platforms. Not because Flutter is bad, but because native development produces better apps for the kind of clients we work with, and it's what we know deeply.
This article explains exactly why — and helps you decide what's actually right for your app.
What "Native" Actually Means
A native app is built specifically for one platform using that platform's own tools and language. For Apple devices, that means Swift (or the older Objective-C). For Android, that means Kotlin (or Java).
When Apple or Google releases a new iOS or Android feature — a new camera capability, a new payment method, a new hardware sensor — native developers get access to it immediately. Cross-platform frameworks like Flutter or React Native have to wait for their maintainers to wrap those features, which can take weeks or months.
Native apps also follow each platform's design language precisely. An iOS app built with Swift and SwiftUI feels exactly like an Apple app should. An Android app built with Kotlin and Jetpack Compose looks and behaves exactly as Android users expect. That familiarity matters — users notice when something feels "off", even if they can't explain why.
A native app is faster, more reliable, and integrates more deeply with the device. For most Australian SMBs — tradies, hospitality, healthcare, retail — that translates directly to better reviews on the App Store and fewer support calls.
Swift for iOS, Kotlin for Android — Our Stack
We have built production apps in Swift and Kotlin across a range of industries. This isn't a preference — it's where our expertise is deep, and deep expertise produces better apps than broad familiarity.
Swift — Apple's language for everything iOS
Apple introduced Swift in 2014 to replace Objective-C. It's fast, safe, and modern. Combined with SwiftUI — Apple's declarative UI framework — it makes building polished iOS apps faster than ever without sacrificing quality. Every app you love on your iPhone was built with Swift.
Kotlin — Google's preferred language for Android
Google officially adopted Kotlin as the primary Android language in 2017, and since then it has completely replaced Java as the modern standard. Combined with Jetpack Compose, Android's declarative UI toolkit, Kotlin lets us build modern Android apps that are clean, maintainable and performant.
Kotlin Multiplatform — the bridge between them
Kotlin Multiplatform (KMP) is the most exciting development in mobile. It lets us write shared business logic — the database layer, networking, authentication, data processing — in Kotlin once, then use it in both the Android and iOS apps. The UI stays native on each platform (SwiftUI on iOS, Jetpack Compose on Android), so users never notice any difference.
The result: roughly 40% less duplicated code, faster development, and still 100% native performance and feel on both platforms. JetBrains reports teams typically save significant development time while keeping the native quality clients pay for.
Building an app for your Australian business?
We offer a free 30-minute consultation to discuss your project, budget and the right tech approach for your specific needs.
Book Free Consultation →The Honest Truth About Flutter
Flutter isn't bad. It's a solid tool built by Google, and for certain projects it genuinely makes sense. But we think it's oversold to Australian SMBs, and here's why.
Flutter draws its own UI — it doesn't use native components from iOS or Android at all. That means it can look slightly different from what users expect on each platform. On most apps, most users won't notice. But in competitive markets — healthcare, finance, anything where trust matters — that polish gap can cost you.
Flutter also introduces a dependency on Google maintaining the framework. If Google ever decides to deprioritise Flutter (as they have with other projects), your codebase becomes a liability. Swift and Kotlin, by contrast, are maintained by Apple and Google respectively as their primary mobile languages — they're not going anywhere.
Several large Australian companies that built in Flutter have quietly migrated back to native development as their apps grew more complex. The initial cost saving turned into a longer-term maintenance cost. We've seen this pattern more than once.
Native vs Cross-Platform: Plain Comparison
| Factor | Swift + Kotlin (Native) | Kotlin Multiplatform | Flutter |
|---|---|---|---|
| Performance | 100% native | 100% native UI | Near-native (~97%) |
| Platform look & feel | Exact | Exact | Close but custom |
| New OS features | Immediate | Immediate | Delayed by weeks |
| Shared code | None | Business logic shared | Full codebase shared |
| Development cost | Higher (two codebases) | Moderate | Lower upfront |
| Long-term maintenance | Excellent | Excellent | Can grow complex |
| Best for | Complex, performance-critical apps | Most business apps needing both platforms | MVPs, simple apps, tight budgets |
When Cross-Platform Actually Makes Sense
We're not anti-Flutter or anti-React Native. We're anti-using-the-wrong-tool. Here are the situations where a cross-platform approach genuinely makes sense:
- You need an MVP in 6 weeks with a tight budget — cross-platform gets you to market faster and cheaper. Validate the idea first, rebuild later if it takes off.
- Your app is essentially a wrapper around a web interface — forms, dashboards, content display. If there's no heavy native functionality, the platform gap matters less.
- Your team is full of JavaScript developers — React Native lets them be productive immediately. Forcing a JS team to learn Swift and Kotlin is a bigger risk than the platform gap.
- Internal tools used by your own staff — if nobody's submitting App Store reviews for your internal warehouse management app, perfect polish matters less.
If you're building a consumer-facing app that you want to be in the Australian App Store or Google Play and compete with established players, go native. If you're testing an idea or building an internal tool, cross-platform is fine. The decision should come from your use case, not from what's trendy.
Why Kotlin Multiplatform Is the Smart Middle Ground in 2026
The technology we're most excited about right now is Kotlin Multiplatform. It solves the biggest complaint about native development — writing everything twice — without giving up native quality.
Here's how it works in practice: your authentication logic, your database queries, your API calls, your business rules — all of that gets written once in Kotlin and shared between Android and iOS. The part that users see — buttons, layouts, animations, navigation — stays native on each platform. iOS users get a SwiftUI interface that feels like Apple designed it. Android users get Jetpack Compose that feels like Google designed it.
JetBrains published a clear roadmap for KMP throughout 2026, with Compose Multiplatform for iOS reaching stability and Swift interoperability improving significantly. This is no longer experimental tech — large companies including VMware and Netflix use KMP in production. The question for most Australian businesses isn't "is it ready?" — it's "how soon can we adopt it?"
Which Approach Is Right for Your Australian Business?
After reading this, here's a simple way to think about your decision:
- Consumer app targeting Australian users, App Store + Google Play launch, needs to feel premium — Swift + Kotlin native, or Kotlin Multiplatform for both platforms.
- Business app for both iOS and Android with moderate complexity — Kotlin Multiplatform is the best option in 2026. Native feel, shared logic, sensible cost.
- Quick MVP to validate a business idea in under 3 months — Flutter or React Native. Get to market, learn, rebuild once you know it works.
- iOS app only, for Apple users (common in healthcare and professional services) — Swift only. Simple, fast, best in class.
- Android app only, for a specific Android-heavy use case — Kotlin only. NDIS providers, logistics, field service — Android often dominates in these sectors in Australia.
Not sure which category you're in? That's exactly what our free consultation is for. We'll ask the right questions, understand your users, budget and timeline, and give you a straight recommendation — not a sales pitch for whichever framework we happen to prefer.
We're based between Melbourne and Donnybrook, Victoria, and we work with businesses across Australia. If you're planning a mobile app, get in touch with us at Lumnio — the conversation costs nothing.