May 6th, 2026 at 11:32 am
Three Paths, One Decision — and the Stakes Are Real
Every mobile app project in 2026 begins with a version of the same question: should we build native, cross-platform, or PWA? The answer shapes your team structure, your timeline, your cost, and how maintainable the product is three years from now.
The problem is that most content on this topic is either too abstract (‘it depends on your needs’) or too framework-specific to be useful as a genuine decision tool. This guide gives you a direct answer first, then the reasoning. It is designed for founders, CTOs, and product leads who need to make a defensible technology decision — not for developers who have already chosen a stack and are looking for validation.
The direct answer (before the nuance):
For most UK startups and growth-stage companies in 2026: cross-platform (React Native or Flutter) is the right default for mobile apps. Native is justified by specific technical requirements, not by vague aspirations to quality. PWA is underused for content-heavy, low-frequency use cases where a home screen icon is not the primary distribution goal. The rest of this guide explains when each of those defaults should be overridden.
1. Direct Answer: The Decision Tree
Answer these questions in order. Stop at the first answer that applies to your project.
Question 1
| Does your app require deep platform-specific capabilities: advanced ARKit/ARCore, Core ML on-device inference, background BLE processing, HealthKit or Apple Watch native integration, or real-time high-frame-rate graphics (60fps+ games)? | |
| YES → Build native (iOS with Swift, Android with Kotlin). No cross-platform framework accesses these APIs efficiently enough to justify the trade-off. | NO → Continue to Question 2. |
Question 2
| Is your product primarily content or information, accessed occasionally (less than 3 times per week per user), with no need for push notifications, camera, offline storage, or payments? | |
| YES → A PWA is seriously worth considering. You will save 40–60% of build cost and maintain through a single web codebase. Read Section 4 on 2026 PWA capabilities before deciding. | NO → Continue to Question 3. |
Question 3
| Do you need both iOS and Android, and does your budget not accommodate two native codebases (typically £120,000–£250,000+ for a feature-complete dual-native build)? | |
| YES → Build cross-platform. React Native if your team is JavaScript-proficient or your timeline is tight. Flutter if pixel-perfect UI or multi-platform (web + desktop) is a requirement. See our React Native vs Flutter guide for the detailed comparison. | NO (one platform only, or budget for dual native) → Build native. Single platform with native tooling delivers the best result when you are not constrained by cross-platform requirements. |
The meta-lesson of the decision tree:
Most teams that choose native over cross-platform do so because they believe native is ‘better’, not because their project genuinely requires it. In 2026, React Native and Flutter are production-grade for the vast majority of app categories. The performance and quality gap that justified native-only development for most projects has closed. Choose native when you have a specific technical reason. Choose cross-platform when you do not.
2. Native: When It’s Worth It
Native iOS (Swift) + Native Android (Kotlin)
| Strengths |
| |
| Limitations |
| |
| UK examples | Monzo (iOS and Android built natively for performance-sensitive banking UX) · Most NHS clinical apps requiring HealthKit and FHIR integrations · High-end fitness apps requiring Core ML on-device processing | |
3. Cross-Platform: Where React Native and Flutter Shine
Cross-Platform (React Native or Flutter)
| Strengths |
| |
| Limitations |
| |
| UK examples | Shopify’s merchant mobile app (React Native) · Alibaba Xianyu (Flutter) · Most UK Series A–B startups shipping to both platforms within a single budget envelope | |
The choice between React Native and Flutter within this category is covered in detail in our dedicated comparison guide. The short version: React Native for JavaScript teams and faster MVPs; Flutter for pixel-perfect UI and multiplatform targets.
4. PWA: 2026 Capabilities on iOS and Android
Progressive Web Apps are the most consistently underestimated option in the mobile development decision. The stigma from 2018–2020 — when iOS Safari’s limited PWA support made them a poor substitute for native apps — has not fully cleared despite significant capability improvements.
What PWAs can do in 2026 that they could not in 2020
- Push notifications on iOS: Apple added full web push notification support in iOS 16.4 (2023) and has continued improving it. UK businesses can now send push notifications to iPhone users via PWA without an App Store app.
- Home screen installation: both iOS and Android support add-to-home-screen with a native-feeling icon and splash screen. App Store distribution is not required for basic app presence.
- Offline mode: Service Workers with IndexedDB provide robust offline data access and background sync for content-heavy apps.
- Camera and media: getUserMedia API provides reliable camera access on modern iOS and Android. QR scanning, photo capture, and video recording all work in mobile browsers as of 2026.
- Payments: Apple Pay and Google Pay are accessible via the Payment Request API in mobile browsers, enabling real-money transactions without an App Store app.
What PWAs still cannot do in 2026
- Background location tracking — iOS Safari kills service worker processes in the background; background geolocation requires a native app
- Bluetooth (BLE) — Web Bluetooth is not supported on iOS Safari as of April 2026
- NFC — no reliable cross-browser NFC access from web context
- Advanced biometrics — Web Authentication (WebAuthn) works for login but does not access Face ID or Touch ID for in-app actions as fluidly as native
- App Store discovery — PWAs are not listed in the App Store or Google Play by default, which eliminates a primary user acquisition channel for consumer apps
Progressive Web App (PWA)
| Strengths |
| |
| Limitations |
| |
| UK examples | The Guardian’s mobile web (PWA-like architecture for content delivery) · Various UK government services (GOV.UK progressive enhancement approach) · B2B SaaS tools where users are primarily on desktop but want mobile access without a separate app | |
5. Total Cost of Ownership Over Three Years
The build cost is the most visible number in the decision, but it is not the most important one. Maintenance, updates, and platform compatibility work compound over time — and the three approaches have very different long-term cost profiles.
| Cost component | Native (dual) | Cross-platform | PWA |
|---|---|---|---|
| Year 1: Initial build (typical mid-market app) | £120,000 – £250,000 | £60,000 – £130,000 | £25,000 – £60,000 |
| Annual OS update compatibility | £8,000 – £18,000 | £4,000 – £10,000 | £2,000 – £5,000 |
| Annual feature development (one major feature) | £25,000 – £50,000 | £15,000 – £30,000 | £10,000 – £22,000 |
| Annual maintenance and bug fixes | £12,000 – £25,000 | £8,000 – £16,000 | £5,000 – £10,000 |
| App Store fees (annual) | £104 (both stores) | £104 (both stores) | £0 (no App Store required) |
| 3-year total (mid-range estimate) | £275,000 – £490,000 | £145,000 – £280,000 | £62,000 – £145,000 |
| 3-year TCO relative to native | Baseline (1.0x) | ~0.55x native cost | ~0.25x native cost |
The three-year TCO comparison makes the decision clearer than the build cost alone. Cross-platform is not 40% cheaper than native — it is roughly 45% cheaper over three years, once maintenance and update cycles are factored in. PWA is dramatically cheaper but has the capability constraints covered in Section 4. The right question is not ‘what does it cost to build?’ but ‘what does it cost to own over the product’s commercial life?’
The hidden cost of native:
The most underestimated cost in dual-native development is the coordination overhead between two separate engineering tracks. Every feature requires two implementations, two code reviews, two QA passes, and two deployments. At the senior engineering rates common in UK mobile development (£600–£900/day), this overhead adds up to £30,000–£80,000 per year for a team maintaining active feature development on both platforms — money that cross-platform teams spend on product development instead.
6. Frequently Asked Questions
What is the difference between native, cross-platform, and hybrid app development?
Native app development means building separate applications for iOS (using Swift) and Android (using Kotlin) using each platform’s official programming language and toolchain. Cross-platform development (React Native, Flutter) uses a single shared codebase that compiles or renders to native UI components on both platforms. Hybrid development (a term now used less frequently) historically referred to web views wrapped in a native container (Cordova, Ionic) — a model largely superseded by the more capable React Native and Flutter approach. In 2026, ‘cross-platform’ is the accurate term for React Native and Flutter; ‘hybrid’ typically refers to the older web-view-based approach.
Is a PWA good enough to replace a native app in 2026?
For some use cases, yes. A PWA is a viable replacement for a native app when: the content is primarily informational, access frequency is low (under 3 sessions per week per user), push notifications are desirable but not critical, and App Store distribution is not the primary user acquisition channel. For consumer apps where engagement, App Store discovery, and device feature access (camera, biometrics, Bluetooth, background processing) matter, a native or cross-platform app will consistently outperform a PWA on user acquisition and retention metrics in 2026.
Can cross-platform apps access the same device features as native apps?
Most of them, yes. React Native and Flutter provide access to camera, microphone, GPS, push notifications, biometric authentication, payments (Stripe, Apple Pay, Google Pay), Bluetooth (with caveats), accelerometer and gyroscope, and most commonly used platform APIs through maintained packages. The capabilities that are not reliably accessible cross-platform are: advanced AR features (ARKit spatial anchors, ARCore depth API), background Bluetooth processing, Core ML on-device inference, and real-time graphics APIs (Metal, Vulkan). For these specific capabilities, native is required.
Which approach is best for a UK regulated sector app (healthcare, fintech)?
Both native and cross-platform are used in production UK regulated sector apps. The framework choice is less important than the team’s regulatory experience. For healthcare apps: the MHRA, DTAC, and clinical safety requirements apply equally regardless of whether the app is native or cross-platform. For fintech apps: FCA Consumer Duty obligations apply to the product behaviour, not the technology stack. The key consideration for regulated sectors is choosing a development partner with sector experience and a documented compliance process — not optimising for a specific framework. Cross-platform frameworks are used in NHS-adjacent and FCA-regulated apps without issue.
How long does it take to build a cross-platform app vs native?
For a mid-complexity app (5–8 features, custom backend, both iOS and Android): a cross-platform build (React Native or Flutter) typically takes 18–26 weeks. The equivalent dual-native build (separate iOS and Android codebases) typically takes 28–40 weeks. A single-platform native build takes 14–22 weeks — roughly comparable to cross-platform for one platform. These ranges assume a professional UK development team of 3–5 people. The cross-platform time advantage comes primarily from shared UI code and a single backend integration track.
Not sure which approach is right? Get a free recommendation.
Tell us about your project — your target users, platform requirements, team composition, and timeline — and our engineering team will give you a specific, reasoned recommendation for native, cross-platform, or PWA. We deliver the recommendation within 24 hours, no sales call required.
