When to Build a Mobile App vs a PWA

Every week, someone asks us: "Should we build a native app or just make our website work on mobile?" It's the right question to ask. The wrong answer costs you months of development time and thousands of dollars.

Progressive Web Apps have gotten really good. Safari finally supports most PWA features. Android has treated PWAs like first-class citizens for years. So when do you still need a native app? Let's break it down.

What PWAs Can Actually Do Now

The capability gap between PWAs and native apps shrinks every year. In 2026, PWAs can:

• Work offline with cached data
• Send push notifications (yes, even on iOS now)
• Access the camera and microphone
• Use GPS location
• Store data locally with IndexedDB
• Install to the home screen with an app icon
• Run in fullscreen without browser chrome
• Handle payments through the Web Payments API

For many apps, that's enough. If your app is essentially "display content, accept user input, maybe work offline sometimes," a PWA covers it.

When You Need a Native App

Hardware Access Beyond the Basics

PWAs can access the camera. They can't control it like a native app can. If you need custom camera interfaces, access to specific lenses, RAW image processing, or frame-by-frame video manipulation, you need native.

Same goes for Bluetooth. PWAs have Web Bluetooth, but it's limited. Fitness trackers, IoT device control, medical devices, anything with complex Bluetooth protocols needs native code.

Anything involving system-level access: background processing that keeps running when the app is closed, deep integration with phone calls or SMS, access to the file system beyond simple file picking, controlling system volume, using sensors like barometer or proximity. All of that requires native.

Performance-Critical Features

Gaming. Full stop. If you're building anything more complex than a simple puzzle game, go native. The performance difference is substantial. Native apps can hit the GPU directly. PWAs go through the browser's rendering engine.

Real-time audio processing. Music production apps, voice changers, audio effects. The latency in a browser is noticeable. Native gives you direct access to the audio APIs.

Heavy computation. Machine learning inference, complex image processing, 3D rendering. You can technically do these in a PWA with WebGL and WASM, but native apps handle them better and more efficiently.

Platform-Specific Features

Apple Watch or WearOS integration requires native. Widgets on the home screen require native. Siri Shortcuts and iOS Intents require native. App Clips and Android Instant Apps require native.

If your app needs to feel like it belongs on the platform, with all the little integrations users expect, native is the path.

App Store Presence

Some businesses need to be in the App Store and Play Store. It's a discovery channel. It's a trust signal. Enterprise customers sometimes require it for MDM deployment. You can wrap a PWA in something like Capacitor or PWABuilder to get store distribution, but you're adding complexity and not getting the full native experience.

When PWAs Win

Content Apps

News, blogs, documentation, catalogs. If your app is primarily about displaying content that updates from a server, a PWA is perfect. You get the installable home screen icon, offline reading, and push notifications for new content. And your content is indexable by search engines, which native apps struggle with.

Internal Tools

Building something for your employees? An inventory scanner, a time tracking app, a field service tool? PWAs are often the better choice. No app store approval process. Updates deploy instantly. Works on any device with a browser. One codebase for mobile and desktop. IT doesn't have to manage app distribution.

MVP and Validation

You're testing an idea. You don't know if users will even want this thing. A PWA lets you ship faster and iterate quickly. If the concept proves out, you can build native later. If it doesn't, you haven't wasted six months on native development.

Limited Budget

Let's be honest. Native development costs more. You either build twice (iOS and Android separately) or use a cross-platform framework, which still has a learning curve and platform-specific issues. A PWA is one codebase that works everywhere. If budget is tight, PWA stretches your dollars further.

The Hybrid Path

Sometimes the answer is both. Start with a PWA to prove the concept and get to market. If users adopt it and need native features, build native apps later. Your PWA becomes your mobile web experience for casual users, and your native apps serve power users who want deeper integration.

Or go the Capacitor/Ionic route. Build with web technologies, wrap in native containers, ship to app stores. You get most of the native APIs with web development speed. The trade-off is performance and platform feel, but for many apps, it's good enough.

The Decision Checklist

Go native if:

• You need hardware access beyond camera/GPS/basic sensors
• Performance is critical (games, audio/video processing, ML)
• Platform integration matters (widgets, watch apps, Siri)
• App store presence is a business requirement
• You're building something users will use hours per day

Go PWA if:

• Your app is content-focused
• It's an internal tool or B2B application
• You need to ship fast and iterate
• Budget is constrained
• You want one codebase for web and mobile
• Search engine indexing matters

Our Take

We default to PWA for most projects and let the requirements pull us toward native. This isn't because we're biased against native development. It's because most apps don't need native. When you look at what an app actually does versus what the stakeholders imagine it needs, the core functionality usually fits within web capabilities.

But when native is the right call, it's clearly the right call. Don't try to force a fitness tracker with Bluetooth LE into a PWA. Don't build a music production app in the browser. Match the technology to the requirements, not the other way around.

The goal is to solve the user's problem. Whether that solution runs in a browser or as a native binary is an implementation detail. Focus on what you're building, and the platform choice usually becomes obvious.