Every mobile project starts with the same question: native or cross-platform?
Ask a native iOS developer and they'll say native. Ask a React Native agency and they'll say cross-platform. Both are wrong — or rather, both are right for some projects and wrong for others. The problem is that most advice on this topic is self-serving or outdated.
Here's a framework that isn't. We build with both approaches at LSD Dev Studio, so we have no incentive to steer you toward one over the other. The right answer depends on exactly five things: your budget, your timeline, your team, your feature requirements, and how many platforms you need to ship on. Let's work through each.
The Quick Comparison
| Factor | Native (Swift + Kotlin) | Cross-Platform (React Native / Flutter) |
|---|---|---|
| Cost (both platforms) | $30,000–$200,000+ | $15,000–$120,000+ |
| Timeline (both platforms) | 1.5–2x longer | Baseline |
| Performance | Maximum | 95–99% of native |
| Code sharing | 0% between iOS and Android | 85–95% shared |
| Team size needed | 2 teams (iOS + Android) | 1 team |
| Platform API access | Immediate, full | Slightly delayed, near-full |
| Maintenance cost | Higher (two codebases) | Lower (one codebase) |
| Best for | Performance-critical, hardware-intensive, single-platform | Budget-conscious, both platforms, speed to market |
If you're building for both iOS and Android on a budget under $80,000, cross-platform is almost certainly the right call. If you're building a single-platform app that pushes hardware limits, native wins. Everything between those extremes is where the real decision-making happens.
What "Native" Actually Means in 2026
Native development in 2026 looks nothing like native development in 2019. Both platforms have adopted declarative UI frameworks that dramatically improve developer productivity:
iOS: Swift + SwiftUI. Apple's declarative framework has matured significantly. SwiftUI handles most UI patterns well, with UIKit available for anything SwiftUI can't do. Combine handles reactive data flow. Xcode's previews provide instant visual feedback. The developer experience is excellent — when you're only targeting Apple's ecosystem.
Android: Kotlin + Jetpack Compose. Google's equivalent of SwiftUI. Compose has become the default for new Android projects. It's reactive, composable, and well-integrated with Android's lifecycle and navigation systems. Android Studio's tooling is solid.
The key insight: modern native development is declarative on both platforms. If you squint, SwiftUI and Jetpack Compose look remarkably similar. But they're still two completely separate codebases, two separate build systems, two separate release processes, and two separate sets of bugs. That's the cost you're paying for native — not worse tooling, but double everything.
What "Cross-Platform" Actually Means in 2026
If your last experience with cross-platform was Cordova or early React Native, forget everything you remember. The landscape has shifted completely.
React Native (New Architecture). The bridge is gone. React Native's Fabric renderer and TurboModules provide synchronous, direct access to native platform APIs. Performance is near-native. The JavaScript/TypeScript ecosystem gives you access to millions of packages. Expo handles builds, deployments, and over-the-air updates. It's a mature, production-ready framework used by Meta, Microsoft, Shopify, and Discord.
Flutter (Impeller). Flutter renders every pixel itself using the Impeller engine — no native components, no bridge. The result is pixel-identical UI across platforms with smooth 60fps animations. Dart compiles to native ARM code. Flutter officially supports iOS, Android, web, Windows, macOS, and Linux from a single codebase.
Both frameworks can build apps that users genuinely cannot distinguish from native apps. The "cross-platform apps feel janky" argument died somewhere around 2023. For a detailed comparison of the two frameworks, read our React Native vs Flutter breakdown.
When Native Is the Right Choice
Choose native if any of these are true:
You need day-one access to new platform features
When Apple announces a new API at WWDC — say, a new camera capability, a new health sensor, or a new AR framework — native apps can adopt it immediately. Cross-platform frameworks need time to build bindings, usually weeks to months. If being first to market with platform-specific features is a competitive advantage, native gives you that edge.
Your app is performance-critical
Games with complex 3D rendering. Real-time video processing. AR/VR experiences. Audio production tools. Scientific instruments. These apps need every millisecond of performance and direct GPU access. Cross-platform frameworks add a thin abstraction layer that's invisible for 95% of apps but meaningful when you're pushing hardware limits.
You're building for one platform only
If you're building an iOS-only app (common in B2B SaaS and enterprise), native eliminates the overhead of a cross-platform framework entirely. You get the best possible iOS experience with the simplest possible toolchain. Same logic applies for Android-only apps in markets where Android dominates.
You have existing native teams
If your company already employs iOS and Android engineers, forcing them to learn React Native or Flutter has a real cost — months of ramping, lower productivity during transition, and potential attrition from developers who don't want to switch. Sometimes the best technical decision is the one that works with the team you have.
Deep hardware integrations are central to your app
Bluetooth LE communication with custom hardware. NFC for payment terminals. Custom camera pipelines. Sensor fusion. If your app's core value proposition depends on tight hardware integration, native gives you the most control and the fewest abstraction headaches.
When Cross-Platform Is the Right Choice
Choose cross-platform if any of these are true:
You need both iOS and Android
This is the single strongest argument for cross-platform. Building natively for both platforms means two codebases, two teams, two sets of bugs, and two release cycles. Cross-platform gives you both from one codebase at roughly 1.1–1.3x the cost of a single-platform native build — compared to 1.6–2.0x for native-both. The math isn't close.
Speed to market matters
One codebase means one development cycle. A cross-platform app that takes 12 weeks to build would take 16–20 weeks natively for both platforms. If you're racing to validate an idea, launch before a competitor, or hit a funding milestone, cross-platform gets you there faster.
You're building an MVP
The entire point of an MVP is to validate assumptions before investing heavily. Cross-platform lets you test on both platforms simultaneously at minimal extra cost. If the MVP fails, you've spent less. If it succeeds, you can always rebuild natively later — though most companies never need to. Read more about MVP costs →
Your team knows JavaScript or Dart
If your developers already know JavaScript/TypeScript, React Native is a natural fit — especially if you also have a React web application. Code sharing between web and mobile can reach 60–70%. If your team knows Dart, Flutter is the obvious choice. Don't underestimate the cost of learning a new language and ecosystem.
You want to share code with a web app
React Native with Next.js allows significant code sharing between your web and mobile apps — API clients, business logic, validation rules, TypeScript types. This reduces bugs (one implementation instead of two) and speeds up development. Flutter also supports web, though its web output is heavier than native web frameworks.
The Cost Difference — Real Numbers
Here's what these approaches actually cost for a medium-complexity app (authentication, 15–20 screens, payments, push notifications, admin dashboard):
| Approach | Development Cost | Annual Maintenance | 3-Year Total |
|---|---|---|---|
| Native iOS only | $20,000–$50,000 | $4,000–$10,000 | $28,000–$70,000 |
| Native Android only | $20,000–$50,000 | $4,000–$10,000 | $28,000–$70,000 |
| Native both (iOS + Android) | $35,000–$90,000 | $7,000–$18,000 | $49,000–$126,000 |
| Cross-platform (both) | $22,000–$55,000 | $4,000–$10,000 | $30,000–$75,000 |
The 3-year total is where the difference becomes stark. Native-both costs roughly 60–70% more than cross-platform over three years, because you're maintaining two codebases, handling two sets of OS updates, and managing two release pipelines.
For the full breakdown on mobile app pricing, see our detailed cost guide.
The Maintenance Equation
Building the app is the easy part. Maintaining it is where native-both gets expensive.
Every September, Apple ships a new iOS version. Every October, Google ships a new Android version. Both reliably deprecate APIs, change permission models, and introduce new UI conventions. Your app needs to be updated or it starts feeling broken within 12 months.
| Maintenance Task | Native (two codebases) | Cross-Platform (one codebase) |
|---|---|---|
| OS compatibility updates | Done twice | Done once |
| Security patches | Applied twice | Applied once |
| Feature additions | Built twice | Built once |
| Bug fixes | Fixed twice (often different bugs) | Fixed once |
| Framework updates | Two upgrade paths | One upgrade path |
| QA testing | Two test suites, two device sets | One test suite, two device sets |
The QA row is worth noting — even with cross-platform, you still test on both platforms. The difference is that cross-platform bugs are usually consistent across platforms (one fix, done), while native bugs are often platform-specific (different root cause on each side).
Budget 15–25% of the initial build cost per year for maintenance regardless of approach. The difference is that native-both applies that percentage to a higher base cost and requires more engineering hours for the same outcome.
Performance: Myth vs Reality
The "cross-platform is slow" narrative persists in some circles, mostly from engineers who haven't used React Native or Flutter since 2020. Here's what the data actually shows in 2026:
| Metric | Native (Swift/Kotlin) | React Native (New Arch) | Flutter (Impeller) |
|---|---|---|---|
| Cold start | 250–350ms | 400–500ms | 300–400ms |
| Scroll performance (60fps) | 99.5%+ | 97%+ | 99%+ |
| Complex animations | Baseline | 90–95% of native | 95–98% of native |
| Memory footprint | Lowest | +10–20% | +10–15% |
| App binary size | 5–10 MB | 12–18 MB | 15–25 MB |
| CPU usage (typical) | Baseline | +5–15% | +5–10% |
What this means in practice: For the vast majority of apps — business tools, e-commerce, social platforms, content apps, SaaS clients — users cannot tell the difference. The performance gap only matters for a narrow category of apps that push hardware limits.
The cold start difference (150–250ms) is measurable with a stopwatch but invisible to users. The scroll performance difference means React Native might drop 1–2 frames during an aggressive scroll of a complex list — something no user will notice. The animation gap matters only for complex, gesture-driven interactions like Snapchat-style camera effects or physics-based animations.
If your app is a banking dashboard, a fitness tracker, a delivery app, or a project management tool, performance is not a reason to go native. Full stop.
Decision Framework
Answer these five questions to determine your approach:
1. How many platforms do you need?
- One platform → Native (simpler toolchain, best possible experience)
- Both platforms → Lean toward cross-platform (continue to question 2)
2. What's your budget for both platforms?
- Under $40,000 → Cross-platform (native-both is impractical at this budget)
- $40,000–$80,000 → Cross-platform (better value, more features for the money)
- Over $80,000 → Either works (continue to question 3)
3. Does your app push hardware limits?
- Yes (games, AR, real-time video, custom hardware) → Native
- No (business app, content, e-commerce, social) → Cross-platform
4. What does your team know?
- JavaScript/TypeScript → React Native
- Dart → Flutter
- Swift/Kotlin → Native (unless budget strongly favours cross-platform)
- No mobile experience → Cross-platform (faster onboarding, one framework to learn)
5. How fast do you need to ship?
- ASAP → Cross-platform (one development cycle instead of two)
- Flexible → Choose based on questions 1–4
If you answered "cross-platform" three or more times, go cross-platform. If "native" came up three or more times, go native. If it's split, the tiebreaker is usually budget — cross-platform stretches it further.
What About PWAs and Hybrid Apps?
Progressive Web Apps (PWAs) are web applications that can be installed on mobile devices. They're built with standard web technologies (HTML, CSS, JavaScript) and can work offline, send push notifications (on Android; iOS support is limited), and be added to the home screen. PWAs are a good fit for content-heavy experiences, internal tools, or situations where you can't justify a native or cross-platform build. They're not a replacement for a real mobile app — no App Store distribution, limited hardware access, and second-class citizen status on iOS.
Hybrid frameworks (Ionic, Capacitor) wrap a web app in a native container. They've improved, but they still feel like a web app in a native shell. For simple apps with limited interactivity, they're fine. For anything with complex UI, gestures, or animations, the experience gap compared to React Native or Flutter is noticeable.
Our take: PWAs are great for specific use cases (internal dashboards, content readers, simple utilities). Hybrid frameworks are acceptable for MVPs with very tight budgets. For production mobile apps that need to feel good and scale, use React Native, Flutter, or native.
LSD Dev Studio's Approach
At LSD Dev Studio, our default for mobile projects is cross-platform with React Native. Here's why:
It matches our stack. We build web applications with Next.js and mobile apps with React Native. Shared JavaScript/TypeScript across both means our developers move between web and mobile without friction. Our clients benefit from code sharing — API clients, business logic, and type definitions work on both platforms.
It matches most budgets. The majority of our clients are startups and small-to-mid-size businesses with budgets between $5,000 and $80,000. At those price points, native-both is impractical. Cross-platform delivers both platforms for roughly the cost of one native build.
It matches most requirements. For 90% of apps we scope, there's no technical reason to go native. The app needs auth, a backend, push notifications, payments, and a clean UI. Cross-platform handles all of that without compromise.
But we go native when it's right. If a client needs deep hardware integration, cutting-edge platform APIs, or maximum performance, we build native. We don't recommend cross-platform because it's easier for us — we recommend it because it's usually better for the client.
Not sure which approach fits your project? Get in touch — we'll scope your requirements and give you an honest recommendation, even if that means recommending an approach we don't specialise in.
For a deeper look at how we think about technology decisions, read our guide to choosing a tech stack in 2026.
LSD Dev Studio — Launch Support Develop. We build mobile apps, web apps, animated videos, and digital products with the right technology for the job. See our mobile development services or get in touch.