Someone in your organisation has decided you need an app. Maybe it was the CEO, returning from a conference where every third slide referenced mobile-first strategy. Maybe it was a client who asked why they couldn’t access your service from their phone without opening a browser and navigating through a site that clearly wasn’t designed for a 6-inch screen. Maybe it was your operations director, who pointed out that your field team is still completing forms on paper and photographing them to email to the office.
The decision to build something is not the hard decision. The hard decision is what to build. And in 2026, the answer to “should we build a native mobile app, a web app, or a progressive web app?” carries more commercial weight than it did three years ago, because the cost differences between the options are now larger, the AI integration possibilities now diverge significantly by platform type, and the strategic implications of choosing incorrectly are more expensive to reverse than they have ever been.
The wrong choice does not announce itself immediately. A native mobile app built for a use case that a PWA would have served equally well will function correctly, receive decent reviews, and cost £80,000 more to build and maintain annually than the alternative that nobody considered seriously. A web app built for a use case that required offline functionality will work perfectly until a user is on the London Underground, at which point it will display a blank screen and that user will find a competitor who thought about the problem more carefully.
According to a 2025 report by Ofcom, 96% of UK adults now own a smartphone, and 78% use their phone as their primary device for accessing services they use regularly. The platform decision you make shapes the experience of that 78%. Getting it wrong is expensive. Getting it right is one of the most durable competitive advantages a digital product can have.
This decision matrix gives you a framework for getting it right based not on what is technically fashionable in 2026 but on what your specific use case, user behaviour, and business model actually require.
Why the Platform Decision Is More Consequential Than Most Businesses Realise
The platform decision is treated, in most product conversations, as a technical preference to be delegated to the development team or the agency. It is not. It is a strategic decision with direct commercial consequences that compound over the lifetime of the product.
The consequences operate at four levels. Cost: native mobile apps cost significantly more to build and maintain than web apps or PWAs, because they require separate codebases or at minimum separate optimisation for iOS and Android, separate App Store approval processes, and separate deployment infrastructure. A native app that should have been a PWA will cost 40 to 80% more to maintain annually than the right choice would have.
Distribution: native mobile apps require users to find them in an App Store, download them, grant permissions, and update them. Web apps and PWAs require only a URL. For products where acquisition cost matters which is most products the friction in the distribution path directly affects conversion from interest to active user. Every step between a potential user discovering your product and that user being able to use it costs you a percentage of them.
AI integration: the AI capabilities available to your product differ meaningfully by platform type in 2026. Native apps can access on-device AI models Apple Intelligence on iOS, Gemini Nano on Android that operate without network connectivity and produce genuinely private inference. Web apps and PWAs access AI through API calls to cloud models, which require connectivity and expose data to third-party infrastructure. For products where AI is central to the user experience, this distinction is not marginal. It may be the platform decision.
Maintenance velocity: native apps require App Store submissions for every update, with review processes that add days or weeks to deployment timelines. Web apps and PWAs update instantly, the moment the server receives the new code. For products where iteration speed is a competitive advantage which is most products in competitive markets the deployment model directly affects how fast you can respond to user feedback.
These four factors interact with each other in ways that make the platform decision significantly more complex than a simple capability comparison. The framework below addresses all four.
Native Mobile Apps: When They Are the Right Answer and When They Are Not
A native mobile app built specifically for iOS using Swift or SwiftUI, for Android using Kotlin, or for both using a cross-platform framework like Flutter or React Native is the right platform when your use case has specific requirements that only native access can satisfy.
Those requirements are narrower than most people assume. Native apps provide unique value in four scenarios. The first is deep hardware integration: features that require continuous access to the device’s camera, microphone, accelerometer, GPS, biometric sensors, or Bluetooth in ways that a browser cannot mediate. A fitness tracker that monitors heart rate through a wearable integration, a field survey tool that captures annotated photographs with GPS coordinates embedded in the metadata, an access control system that manages Bluetooth-connected door hardware these use cases require native access.
The second is offline-first functionality: products whose core value depends on working without an internet connection, not just degrading gracefully when one is unavailable. A field service management tool used by engineers working in areas with no signal. A warehouse management system operating in a basement with no WiFi coverage. The distinction between offline capability and offline-first is significant: PWAs can handle intermittent connectivity gracefully, but products where the entire user workflow must function without any connectivity require native implementation.
The third is on-device AI processing: products where AI inference must happen locally on the device rather than via a cloud API. The privacy, latency, and connectivity-independence advantages of on-device AI are meaningful in specific use cases. Medical data analysis tools where data cannot leave the device for regulatory reasons. Real-time audio processing where cloud API latency would degrade the user experience. Consumer products where privacy is a primary differentiator. These use cases justify native development specifically to access on-device AI capabilities.
The fourth is a user base that has demonstrated a strong preference for native apps in your specific category. Consumer social products, mobile gaming, and financial services apps all operate in markets where users expect native app quality and the absence of a native app is itself a trust signal. If your competitors all have native apps and your users are comparing experiences, the PWA may be technically sufficient but commercially insufficient.
What native apps are not: the default choice for any product that will be used on a mobile device. Not every mobile use case requires native implementation. The cost premium of native development typically 40 to 80% above equivalent web or PWA builds, plus the ongoing maintenance cost of separate iOS and Android codebases is only justified when the use case genuinely requires native hardware access, offline-first functionality, on-device AI, or category-specific consumer expectations.
A London-based property management company spent £145,000 building a native iOS and Android app for their landlord clients to manage maintenance requests and tenant communications. The app was well-built and well-reviewed. It was also used almost exclusively on desktop browsers by landlords who were typically at a computer when managing their properties. Eighteen months after launch, they rebuilt it as a web app at a cost of £55,000. The user experience was equivalent. The annual maintenance cost dropped from £28,000 to £9,000. The platform decision had cost them £109,000 in excess build cost and £57,000 in excess maintenance before the correction was made.
Web Apps: The Undervalued Default for B2B and Desktop-Primary Use Cases
A web app a full-featured application delivered through a browser, built on modern frameworks like React, Vue, or Next.js is the most undervalued option in the platform decision conversation. It is consistently overlooked in favour of native apps that feel more impressive and PWAs that feel more forward-looking. For a significant category of use cases, it is the right answer.
Web apps are the right platform when your primary user device is not a smartphone. B2B tools used by office workers on laptops and desktops. Dashboards accessed by managers making decisions on large screens where data density matters. Internal operational tools used by staff at fixed workstations. The Ofcom statistic that 78% of UK adults use their phone as their primary device for regular services is accurate for consumer products. For B2B products used in a professional context, the device split is typically inverted.
Web apps are also the right platform when your user needs the full capability of a desktop browser: complex data visualisation, multi-window workflows, keyboard shortcuts that accelerate professional tasks, large-format content editing. These are capabilities that smartphones mediate poorly regardless of whether the product is native or browser-based.
The advantages of web apps over native are consistent and significant at the right use case. Deployment is instant: no App Store, no review process, no user-initiated update. Development cost is typically 40 to 60% lower than equivalent native builds. The codebase serves all devices through responsive design rather than requiring separate platform optimization. And AI integration via cloud APIs is straightforward: the leading AI software agencies in London building sophisticated AI-augmented B2B tools overwhelmingly choose web app architectures because they provide the most direct path to powerful cloud-based AI capability without the constraints of mobile browser sandboxing.
Where web apps fall short: any use case that requires offline functionality, device hardware access beyond what browsers expose, or a user experience that competes in a consumer category where native app quality is the expectation.
Progressive Web Apps: The Option That Is Being Underbuilt in London
A progressive web app is a web app built to a specific set of technical standards service worker caching, web app manifest, HTTPS delivery that allow it to behave more like a native app than a conventional web app. PWAs can be installed to the home screen without going through an App Store. They can work offline using cached content and data. They can receive push notifications on Android and, since iOS 16.4, on iPhone. They load fast because service workers cache the application shell and critical assets.
The honest assessment of PWAs in 2026: they are significantly underbuilt in the London market relative to the use cases they could serve well. Most product teams default either to native apps when they want a mobile-first experience or to web apps when they want broad accessibility. PWAs occupy a middle position that many teams either don’t consider or dismiss without rigorous evaluation.
The use cases where PWAs produce the best outcomes are those where mobile access is important but App Store distribution is not, where some offline capability is required but full offline-first functionality is not, where update frequency is high enough that App Store submission delays would materially affect the user experience, and where the build budget does not support native development on both iOS and Android.
A field service tool used by 40 engineers who need to access job details, complete forms, and submit documentation while on-site often with intermittent connectivity is a PWA use case. The engineers are not discovering the tool in an App Store: it is deployed internally. They need offline access to the jobs assigned to them that day, but not full offline-first functionality for the entire application. They need updates to deploy immediately when the operations team changes the form structure, not after a two-week App Store review cycle. Native development for this use case adds cost and complexity for no additional capability. A well-built PWA delivers everything the use case requires.
The one area where the PWA option requires careful evaluation in 2026 is AI integration. The top LLM integration agencies for UK businesses building AI features into PWAs are working within browser-based constraints: service workers have limited access to the more powerful AI APIs, on-device model execution is not yet reliably available across all browsers, and the AI capability ceiling in a PWA is currently below what native or web app architectures can reach. For products where AI is a core feature rather than an enhancement, the PWA’s AI constraints may shift the platform decision toward native or web app despite the PWA’s advantages in other dimensions.
The 2026 Decision Matrix: Applying the Framework to Your Specific Situation
The platform decision is not a single question. It is a series of questions, each of which narrows the viable options until the right answer for your specific situation becomes clear. Apply these seven questions in sequence.
Question one: What is the primary device your users will use to access this product? If the answer is desktop or laptop for the majority of sessions, start with a web app. If the answer is smartphone for the majority of sessions, proceed to question two.
Question two: Does your use case require offline-first functionality that is, the ability to work without any internet connectivity for extended periods? If yes: evaluate native app for full offline-first capability, or PWA for graceful handling of intermittent connectivity. If no: proceed to question three.
Question three: Does your use case require deep hardware access continuous camera, microphone, accelerometer, Bluetooth, biometric sensor access beyond what a browser can provide? If yes: native app is required. If no: proceed to question four.
Question four: Is on-device AI processing a requirement either for privacy, latency, or connectivity-independence reasons? If yes: native app is required to access on-device AI APIs. If no: proceed to question five.
Question five: Will users discover this product through an App Store, or will distribution happen through direct link, QR code, or internal deployment? If App Store discovery is essential to your acquisition model: native app is required. If direct distribution is adequate: PWA or web app are viable. Proceed to question six.
Question six: How frequently do you expect to update the product? If updates are likely more than once per month and update speed is commercially important: eliminate native app from consideration due to App Store review delays. PWA or web app are better candidates. If updates are infrequent: native app remains viable.
Question seven: What is your build budget, and what is the total available for annual maintenance? If the budget is under £60,000 for the initial build: native app for both iOS and Android is unlikely to be viable. PWA or web app. If the budget supports native development: revisit questions one through six to confirm native is justified by the use case rather than by preference.
The matrix produces a clear answer for the majority of use cases when applied honestly. The businesses that choose the wrong platform are almost always those that skipped one of these questions typically question one, because the assumption that mobile means native is so deeply embedded in product culture that it bypasses the diagnostic entirely.
Understanding how to choose a software agency in London that will apply this diagnostic honestly rather than recommending the platform that maximises their development revenue is as important as understanding the matrix itself. Ask any agency you are evaluating: what platform would you recommend for this use case, and what specifically about our requirements justifies that recommendation over the alternatives? Agencies that answer the second part of that question with precision are thinking about your problem. Agencies that deflect to capability comparisons are thinking about their pitch.
The AI Integration Dimension: How Platform Choice Shapes AI Capability in 2026
The AI integration possibilities available to your product differ materially by platform type, and the difference is becoming commercially significant as AI features move from differentiators to expectations in most product categories.
Native mobile apps on iOS can access Apple Intelligence APIs: on-device language models that process text, images, and audio locally without sending data to external servers. For healthcare, legal, and financial products where data sovereignty is a regulatory or competitive requirement, on-device inference is not a preference it is a compliance position. Native Android apps can access Gemini Nano similarly. The privacy and latency advantages of on-device processing are genuine and will widen as device AI hardware improves.
Web apps access AI through cloud APIs Open AI, Anthropic, Google Gemini, and their derivatives which are currently more capable than on-device models but require network connectivity and involve third-party data processing. For most B2B products where the AI feature is augmenting a workflow rather than operating on sensitive individual data, cloud API integration via a web app is the right structure: broader capability, faster iteration as models improve, and lower implementation complexity.
PWAs operate at the intersection: they can call cloud APIs for AI features, as web apps do, but the browser environment adds constraints that limit some of the more powerful AI integration patterns. Service workers can cache AI model outputs for offline use, which extends some AI functionality to offline scenarios. But real-time AI inference in a PWA is constrained by browser memory limits and the absence of direct access to the GPU resources that make on-device AI fast on native platforms.
For products where AI is the core value proposition rather than an enhancement where the product exists to do something intelligent rather than to do something that AI makes faster the platform decision and the AI architecture decision are inseparable. The sequence should be: define what the AI needs to do, determine what infrastructure that requires, and then choose the platform that provides that infrastructure most cost-effectively. Not the reverse.
Frequently Asked Questions
What is the difference between a native mobile app, a web app, and a PWA?
A native mobile app is built specifically for iOS or Android using platform-specific languages and frameworks, with full access to device hardware and operating system APIs. A web app is a full-featured application delivered through a browser, accessible on any device with a URL, with no App Store requirement. A progressive web app is a web app built to technical standards that allow it to be installed to a home screen, work offline with cached content, and receive push notifications offering a middle ground between browser-based accessibility and native-like behavior.
When should a London business choose a native mobile app over a PWA or web app?
Choose native when your use case genuinely requires one or more of: continuous deep hardware access (camera, Bluetooth, biometric sensors), offline-first functionality for extended periods without connectivity, on-device AI processing for privacy or latency reasons, or App Store distribution as the primary acquisition channel. In all other mobile use cases, evaluate PWA first. Native development costs 40 to 80% more to build and maintain than equivalent alternatives, and the premium is only commercially justified when the use case requires native capability.
What is a PWA and when is it the right choice in 2026?
A progressive web app is a web app built to standards that enable home screen installation, offline caching, and push notifications without App Store distribution. PWAs are the right choice when mobile access is important but App Store distribution is not, when some offline capability is needed but full offline-first is not required, when update frequency is high enough that App Store review delays would create problems, and when the build budget does not support native development for both iOS and Android. PWAs are significantly underused in the London market relative to the use cases they serve well.
How does the platform choice affect AI integration in 2026?
Native apps can access on-device AI models Apple Intelligence on iOS, Gemini Nano on Android that process data locally without network connectivity or third-party data exposure. Web apps access cloud AI APIs that are currently more capable but require connectivity and involve third-party data processing. PWAs can call cloud APIs but operate within browser constraints that limit some advanced AI integration patterns. For products where AI is central and data privacy is a requirement, native is currently the strongest AI integration platform. For most B2B products with AI features, web app plus cloud API is the most capable and cost-effective combination.
How much more does a native mobile app cost than a PWA or web app?
Native mobile apps typically cost 40 to 80% more to build than equivalent PWA or web app solutions, primarily because they require separate optimisation for iOS and Android (even with cross-platform frameworks like Flutter or React Native), separate App Store submission and review management, and separate infrastructure for push notification delivery. Annual maintenance costs for a native app run 50 to 100% higher than equivalent web or PWA maintenance. These premiums are justified when the use case requires native capability. They represent avoidable cost when it does not.
What is the fastest platform to build and iterate on for a London startup in 2026?
Web apps offer the fastest build-to-launch timeline and the highest iteration velocity: no App Store review process, instant deployment for all users simultaneously, and a single codebase that serves all devices. PWAs add slightly more complexity for the offline and installation features but retain the deployment speed advantage over native. Native apps have the longest build timelines and the slowest iteration cycles due to App Store review requirements. For startups where speed to market and iteration velocity are competitive advantages, web app or PWA almost always produces the better commercial outcome than native.
The Right Platform Is the One That Fits the Problem, Not the One That Sounds Most Impressive
The platform decision in 2026 is not a technology preference. It is a product strategy decision with direct implications for cost, distribution, AI capability, and iteration velocity. Getting it right means applying the decision matrix honestly rather than defaulting to native because it sounds serious or PWA because it sounds modern.
The businesses making the right platform decision are those that define what their product needs to do, identify the specific technical requirements those needs create, and choose the platform that meets those requirements at the lowest total cost of ownership. The businesses making the wrong decision are those that choose a platform and then define their product requirements to justify it.
Native apps are extraordinary products. They are also frequently the wrong choice. Web apps are the most cost-effective platform for a wider range of use cases than most product teams appreciate. PWAs are underused relative to their capability. The right answer for your business is in the diagnostic, not in the category that feels most impressive to announce in a board meeting.
If you want that diagnostic applied to your specific product with an honest recommendation on which platform fits your use case, your budget, and your users book a Product Architecture Session with Foundry5. No pitch. No preferred platform. Just the right answer for what you are building.
Choose the platform that serves the product. The product is what serves the business.
