Three ways to build the same app, each with a different price in speed, size and cost. Here's the difference without the empty jargon.
Open two apps on your phone and they may look identical, while one is built in a fundamentally different way from the other. The difference doesn't show in the icon; it shows in responsiveness, download size, battery use, and what the app can still do when the connection drops.
There are three basic ways to build a mobile app, and each has its own logic.
Native
Written in the platform's own language: Kotlin or Java for Android, Swift for iOS. It talks directly to the device's components with no intermediate layer.
Strengths: the highest responsiveness, the best integration with camera, notifications and sensors, and the closest adherence to how the system looks and behaves. If the app processes images or audio or leans on heavy graphics, the difference is tangible rather than theoretical.
Cost: two separate codebases for Android and iOS — roughly double the work and double the maintenance.
Hybrid (WebView)
Built with web technologies — HTML, CSS and JavaScript — then wrapped in an app that displays it in a window called a WebView, with a bridge connecting the interface to system functions like payments and notifications.
Strengths: one codebase across both platforms, very fast iteration, and a lot of freedom in interface design. A good fit for simple games, utilities and apps whose content changes often.
Cost: less fluid response in complex animations, and a dependency on the device's rendering engine — which means real differences between devices, especially older ones or those using a non-standard engine.
Progressive web app (PWA)
Not an app installed from a store, but a website designed to behave like one: it can be added to the home screen, works partially offline, and can send notifications on some systems.
Strengths: no store review, no commission, instant updates for everyone at the same moment, and no installation required.
Cost: far fewer permissions, weaker presence in a user's mind because it isn't in a store, and uneven support across systems — notifications especially.
Comparison
| Criterion | Native | Hybrid | PWA |
|---|---|---|---|
| Performance | Highest | Medium to good | Depends on the browser |
| Development cost | Highest | Medium | Lowest |
| Hardware access | Full | Through a bridge | Limited |
| Offline operation | Full | Full | Partial |
| Distribution | Store | Store | Link |
| Update speed | After review | After review | Instant |
How to choose in practice
- Go native if the app depends on camera, audio or heavy processing, or if the experience itself is the product.
- Go hybrid if the interface changes often, if you're a small team shipping one build to two platforms, or if the app is closer to "content plus simple interaction".
- Go PWA if your audience arrives via a link, you don't need deep permissions, and you want to escape the review cycle and the commission.
What this means for you as a user
You don't need to know how an app was built, but three signs usually give it away:
- Download size: native apps tend to be heavier; hybrids are lighter when their content comes from the network.
- Offline behaviour: a blank page or a network error inside the app suggests its content loads from the web.
- The feel of motion: scrolling that sticks slightly or doesn't track your finger exactly is a familiar sign of an intermediate layer.
None of this makes one type better than another in the abstract. A carefully made hybrid app beats a neglected native one, and the reverse is equally true.
Written for the Store of Apps blog. Corrections and feedback: contact@storeofapps.com.