Product
PWA vs native app: what we build, and why
PWA vs native app gets argued as a question of technology. In the apps we have shipped, the product settled it each time, through one question: what the app has to do on the phone that a browser cannot. For a hotel guest ordering breakfast, nothing. For a calorie tracker that reads a plate through the camera, the whole product depends on it.
Native app vs web app, and the option between them
A web app opens from a link, in whatever browser the person already has. A progressive web app, or PWA, is a web app built to behave like an installed one: it can sit on the home screen and open full screen. A native app is built for the platform itself, in Swift on iOS, and ships through the App Store and Google Play, with a review before each release. Between them sits a wrapped app, where the same web code is packaged with Capacitor into a store app and native parts are added only where the phone has to do something a browser cannot.
| Web app (PWA) | Wrapped app | Native app | |
|---|---|---|---|
| How people get it | ✓ From a link or a QR code, with no install | A store app: the same web code packaged with Capacitor | App Store and Google Play, with a review before each release |
| Codebase | One web codebase | ✓ One shared codebase | Built for the platform, in Swift on iOS |
| What the phone adds | Only what a browser can do | ✓ Native parts only where needed, like the video player in Body Heal | ✓ Everything, when that part is the product, like the camera in Kalo |
| Watch out for | Anything the phone has to do that a browser cannot | Performance: the interface was tuned to hold 60fps | Two builds, two review processes and two sets of release mechanics |
| Right when | People use it for a few days | People keep it, and one small part needs more than a browser | That part is the product |
| Our example | iButler | Body Heal | Kalo, FixMan |
When the browser is the right answer
A guest staying four nights will not install software to order towels. iButler, a digital concierge for hotels, removes the install entirely. A QR code in the room opens the hotel’s branded ordering portal in the browser, with no account to create, in the language the phone is set to. An app store submission would have put weeks between a hotel deciding to try it and the thing existing. As a web app, a property goes live in about ten minutes by writing the menu once and printing the codes. The reasoning is in the hotel app nobody was ever going to download.
The rule we take from it: when people will use an app for a few days, every feature behind an install is theoretical, so the app has to open without one.
When one web codebase with native parts is right
Body Heal is a coaching platform where clients follow workout programmes from their coach and log each session, so it has to sit on the phone like an app. It was built as a mobile-first PWA on React and Supabase, and the iOS app is the same code wrapped with Capacitor. The one native part is the video player. A web video element inside a wrapped app still behaves like a web video element, which is not good enough for someone in the middle of an exercise, so the player was built on the Vimeo API. Everything else stayed shared.
The usual alternative is to rebuild the interface in Swift and maintain two codebases, which tend to drift apart within a quarter. The risk of wrapping is performance. A list that stutters reads at once as a website pretending to be an app, so the interface was tuned to hold 60fps on a phone. The full account is in converting a React app into an iOS app.
When native is worth two builds
Kalo, a photo-based calorie tracker for the Balkans, is a native iOS app, because a camera-first tracker succeeds or fails on the capture experience. You photograph the plate and get calories and macros back in seconds, editable before they log. The story is in a calorie tracker that has heard of burek.
FixMan, a booking app for home repairs, shipped natively on both Android and iOS, because a home services app on only one of them misses roughly half the people who need it. That is the cost of native: two builds, two review processes and two sets of release mechanics, kept in step for as long as the app exists.
How we decide
We start with whether people will install it at all. If they will open it for a few days, or from a code in a hotel room, it goes in the browser. If they will keep it, the next question is which part of the product needs more from the phone than a browser can give. When that part is small, like the video in Body Heal, it goes native and the rest stays web. When that part is the product, like the camera in Kalo, the whole app goes native.
- A few days, or a code in a hotel room. It goes in the browser.
- People keep it, and one small part needs the phone. That part goes native and the rest stays web, like the video in Body Heal.
- That part is the product. The whole app goes native, like the camera in Kalo.
Product builds with us start from 3,000 euros. The decisions that shape what an app costs are set out in what a mobile app costs to build in Montenegro. Scope, price and payment terms are agreed in writing before work starts. The practice itself is on the product and SaaS page.
