"We need an app" is not a requirement. It is an answer to a question nobody asked out loud.
Behind that sentence there is almost always a real goal: customers should come back, a workflow should move to the phone, field staff should be able to work off-site. All three are achievable with an app. Two of them are usually achievable without one — faster, and for a fraction of the effort.
This article covers what you are actually choosing between, which test settles it, and where Swiss companies have to do a different calculation than their neighbours in the EU.
The three things you are actually choosing between
"App" covers three different builds. On a phone they look nearly identical. In cost, timeline and capability they are not close.
Native app. Built separately for iOS and Android, installed from the App Store or Play Store. Full access to the hardware — camera, Bluetooth, NFC, background location, biometrics. The most effort, and the most capability.
Web app. Runs in the browser. No store, no download. One codebase for every device, and every change reaches all users the moment you deploy it. Hardware access only as far as the browser allows.
PWA (progressive web app). A web app that can be added to the home screen and then behaves like an installed one: its own icon, no browser chrome, limited offline operation, and push notifications on both platforms. Technically it is still a website.
Why the order of that list is not accidental
The dividing line is not between "proper" and "makeshift". It runs exactly where your use case needs hardware the browser will not give you.
Read bottom-up, the list is an upgrade path: each step builds on the one before, and nothing gets thrown away when you move on. Read top-down, it is a climb-down — and that one needs a rebuild.
The test that settles it in two minutes
Three questions. Answer all three with no, and you do not need a native app — which saves you two codebases, two store accounts and two approval processes.
1. Does the core benefit need hardware the browser cannot reach? Bluetooth pairing with a measuring device, NFC for reading cards, background location tracking, face or fingerprint recognition as a sign-in. If yes: native.
2. Does it have to work fully without a connection? Not "it would be nice". Fully — on a construction site with no signal, in a basement, in a tunnel. A PWA can cache data and sync it later. A genuinely offline application holding a large local dataset is more dependable when it is native.
3. Do your users open it several times a week? This is the question most app ideas die on, and it has nothing to do with technology.
An icon on the home screen is only an advantage if somebody taps it regularly. For something used three times a year, the detour through a store is a barrier, not a channel. For infrequent contact a well-built website does more — which is what the piece on high-converting websites is about.
Three noes means web app or PWA. And in that case the faster option is not the compromise. It is the right answer.
The costs of a native app that nobody budgets for
The build price is the part everyone discusses. The lines underneath it are what push projects out of budget in year two.
- Two codebases. iOS and Android are two products. Every feature is built twice, tested twice, fixed twice.
- Store fees. The Apple Developer Program costs USD 99 per year; access to the Google Play Console is a one-off USD 25. Both figures have held steady for years — check them before you sign off a budget anyway, because platform pricing is not a law of nature.
- Commission on digital sales. If you sell digital content or subscriptions inside the app, the stores keep a share: 30 per cent as standard, 15 per cent for smaller publishers under either platform's small-business programme. It does not apply to physical goods or services — a distinction that decides entire business models.
- Review on every update. A fix to a web app is live once deployed. A fix to a native app goes through store review. Apple states that the majority of submissions are reviewed within 24 hours — fast, but not instant, and a rejection sends you round again.
- Forced maintenance. New iOS and Android versions ship annually. An app left untouched for two years disappears from the store before it ever crashes.
The line item that goes missing most often
Of those five, forced maintenance is the one that rarely appears in a quote, because it only starts after sign-off. It is also the most reliable: platform releases arrive yearly whether or not your budget anticipated them. Order a native app and you order an operating commitment, not a finished object.
The same logic applied to business software in general is in the guide on custom software versus off-the-shelf. The cost question for web builds is covered in what a website costs in Switzerland.
Where Apple turns your app down
The most common reason a small company's app gets rejected is not a bug. It is the idea itself.
Apple's App Review Guidelines set out "Minimum Functionality" under section 4.2. The wording leaves little room: an app should include features, content and an interface that lift it beyond a repackaged website.
So wrapping your website in an app shell because "we should be in the store" earns a rejection not despite that reasoning but because of it. And even when such an app slips through, it gives the user nothing the browser would not have — only with an install in front of it.
The question before any store project is therefore: what can this app do that our website cannot? If the answer does not fit in one sentence, the answer is usually "nothing".
The exception: an app as an internal tool
Applications used only by your own staff sit differently. Distribution routes exist outside the public store, and section 4.2 is not aimed at them. If you are building a purely internal tool, do not frame it as a store project at all — that spares you a review process never designed for the purpose.
What Switzerland calculates differently from the EU
This is where it gets concrete for Swiss companies, and most guides skip it.
The EU's Digital Markets Act (Regulation (EU) 2022/1925) forced Apple to permit alternative app marketplaces and sideloading. That opening applies to the EU and the EEA. Switzerland belongs to neither. So if your plan assumes you will eventually distribute around the store, you are planning around a rule that does not reach you.
In practice: for the Swiss market the official store remains the route to iOS users, with everything attached — review, guidelines, commission. A web app is subject to none of it, because it needs nobody's marketplace.
What that means for planning
It does not mean "no app". It means: treat store dependency as a permanent condition, not a temporary one that the next round of EU regulation will clear up for you. What gets decided in Brussels does not change your distribution route in Zurich.
Then there is data protection. The revised Federal Act on Data Protection (FADP, SR 235.1) has been in force since 1 September 2023 and applies whether your application runs in a browser or in a store.
An app does not move those obligations, it multiplies the places you have to meet them: store privacy declarations, permission prompts, data held locally on the device. Which gaps typically stay open in smaller companies is covered in the piece on cyber security for SMEs.
PWAs: what they manage now — and what they still do not
Precision pays here, because the claims vary a lot depending on who is making them.
What measurably changed: with iOS 16.4 (March 2023) Apple supports web push notifications for web apps added to the home screen. That removed the objection raised most often against PWAs on iPhones. Anyone still reading "PWAs can't do push on iOS" is reading a pre-2023 position.
What still holds: push only works once the app has been added to the home screen — a step many users will not take unprompted and which you have to explain actively.
On top of that, storage for web applications is more tightly capped on iOS than on Android, and background processing is limited. Deep in the hardware — NFC, Bluetooth, full biometric sign-in — the native app stays ahead.
The disagreement worth leaving intact
The web camp argues the platform is catching up and the gap no longer matters for most applications. The native camp counters that interaction quality and system integration cannot be reproduced.
Both are right about their own territory, and for a Swiss SME the argument resolves differently than it does for a platform operator: the limits on a PWA under iOS are a platform decision, not a technical necessity. They can change — they did in 2023. Your investment in two native codebases cannot.
What would settle it for your specific case is a measurement against your own users. That never exists before the build. Which is precisely why starting with the cheaper option is not thrift, it is risk management.
Cross-platform: the compromise and its price
Between native and web sits a third build: shared code that runs as a real app on both platforms. Frameworks such as React Native and Flutter serve this route.
What you gain: one codebase instead of two, a genuine store presence, broad hardware access.
What you pay: a dependency on a framework whose roadmap you do not control. At every major iOS or Android release you wait for the framework to catch up. And for anything the framework does not cover, you write platform-specific code after all — the second codebase returns through the back door.
When the compromise holds
It holds when you need hardware but not a feature a platform makes exclusive on launch day. That describes most SME applications: a reporting tool needs the camera, not the newest system API from the last keynote.
For many SME cases with real hardware requirements this is still the most sensible route. How we set it up is described at ALPENIQ Labs and specifically under mobile app development.
The sequence that saves money
Almost every app project can be arranged as a sequence with an exit at each stage.
- Web app first. One codebase, no store review, instant changes. Within weeks you know whether the thing gets used at all. See web apps.
- Extend it to a PWA once usage is there. Home-screen icon, offline cache, push. Modest effort on a foundation that already stands.
- Add native when one of the three test questions comes back yes — and by then you have usage data instead of assumptions.
That sequence is also why we like to set projects up as an MVP: not to deliver less, but to make the expensive decision with data rather than in advance.
Where the sequence does not apply
If hardware is the core benefit — an app that has no purpose at all without a Bluetooth pairing — the web stage is not a first step, it is a detour. Build native from the start. The test above exists for exactly this: it separates the cases where the sequence saves money from the ones where it costs some.
What else shapes the decision
Two points that regularly get lost in architecture debates and then determine the workload.
Connecting to the systems you already run. An app that does not pull its data from your ERP, CRM or inventory system creates another data silo instead of closing one.
This part is independent of the build and usually the larger effort. How it can be solved is covered in ERP and CRM integration and under integrations.
Where processes rather than interfaces are the actual goal, look first at AI agents for businesses — some "app idea" turns out to be an automation case.
Who can find it. A native app is not discoverable in Google search; a web app is. If visibility is part of the goal, the build decides part of it — and load time decides whether anyone stays. The piece on load time optimisation covers that side.
Reaching a defensible decision in a week
An approach that needs no development budget:
- Day 1–2: write down the benefit. One sentence describing what a user does with it. Not "digitalise", but "record a job report on site and submit it when leaving the dead zone".
- Day 3: answer the three test questions. Honestly, with someone who will actually use the thing — not in a management meeting alone.
- Day 4: estimate frequency. How many times a month does one person open it? Under four, the store route is hard to justify.
- Day 5: list the data sources. Where does every field come from? That list says more about the workload than any architecture question.
What comes out is a decision grounded in the use case rather than in the wish to have an icon in a store. That is the whole difference — and it costs nothing but a week of thinking.