The question usually arrives in the same sentence as the budget: do we need our own app, or is the shop in the browser enough? The available figures paint a soberer picture than instinct does. On smartphones in Germany, online purchases split evenly between apps and mobile websites (HDE), and 69 percent of all online revenue comes from mobile devices (HDE). Both routes carry revenue, but they carry it at very different costs. A native app brings entry fees, revenue shares, a review procedure and an annual obligation to adapt. A Progressive Web App, or PWA, runs from your own server and asks for attention elsewhere instead: load time, installability and the limits the browser imposes on each operating system. This article puts both routes side by side, sorts the cost types and names the five questions the decision actually hangs on. That includes the groundwork of technical implementation on the web and the metrics for measuring the outcome later.
How much revenue smartphones actually generate
German online retail in the narrow sense grew by 3.9 percent in 2025 to 92.3 billion euro net (HDE). That figure carries every app discussion until you put it in proportion: the online share of total retail stands at 13.5 percent, up from 13.4 percent the year before (HDE). A shop app therefore captures a share of a share. Anyone justifying a six-figure investment with a percentage increase should first know the base it acts on: their own mobile revenue, not the market average. Where the mobile share is small, the lever stays small; where it is large, the first look belongs to drop-offs during checkout, because that is where revenue is lost before a second channel even enters the picture.
The real surprise sits inside mobile revenue. Half of online purchases on smartphones run through apps, the other half through mobile websites (HDE); the year before, the ratio was 48 to 52 in favour of websites (HDE). Two things follow. First: anyone without an app today is not losing half of their mobile business, they are serving the part of the market that buys in the browser anyway. Second: anyone building an app rarely wins new customers, they shift existing ones. Experience shows the economic effect in the repeat purchase rate of regular customers, not in new customer acquisition. A defensible calculation separates the revenue that would have appeared without the app from the revenue that appears in addition, and that only works with clean attribution across mobile buying behaviour.
In Germany, 95 percent of people aged 16 to 74 reported having used the internet in the three months before the survey (Federal Statistical Office). Across the EU, 78 percent of internet users had ordered goods or services within twelve months (Eurostat). A website has that reach available with no intermediate step: no account, no installation, no storage space on the device. An app has to earn the same reach first, one installation at a time.
What a PWA is and what the browser can do without a store
A PWA is not a product but the combination of two building blocks: a service worker that intercepts network requests and keeps content locally, and a web app manifest that describes name, icon, start URL and display mode. Only together do they make a website startable from the home screen. Across the web, the blocks are distributed unevenly: 18.9 percent of the sites recorded use a service worker, but only around 9 percent use a manifest (Web Almanac). The reason is mundane, because service workers often arrive as a side effect of management tooling without anyone having planned a PWA. For the decision this means the technical groundwork already exists in many shops, it has simply not been used as a product decision yet.
Add both blocks together and the field thins out. 24.5 percent of websites use at least one of the two features, but only 3.3 percent on desktop and 3.5 percent on mobile have implemented both at once (Web Almanac). Despite years of availability, the installable web app has remained the exception. At the top it looks different. Among the 1,000 most visited sites, 30.3 percent on desktop and 28.9 percent on mobile work with a service worker (Web Almanac). Where competition for mobile attention is fiercest, the technique is part of the craft. For a mid-sized shop that means the distance to the top can be closed with manageable effort, because the building blocks are standardised and need no approval. How they fit into a decoupled front-end architecture depends on the existing system.
| Feature | Native app in the store | Installable web app | What follows from it |
|---|---|---|---|
| Access | installation from the store | opened by URL, placed on the home screen | The browser reaches prospects with no intermediate step |
| Entry | 99 USD per year (Apple), 25 USD one-off (Google) | domain, certificate, hosting | Store costs arise before the first line of code |
| Fee on digital sales | in the EU 15 to 26 percent from 1 October 2026 (Apple) | no platform fee | Applies to digital goods, not to shipping physical goods |
| Release | review with a risk of rejection (Apple) | own server, own cadence | The release plan depends on external timelines, or it does not |
| Updating | update required on the device | effective on the next visit | Old versions stay in the field longer with a store |
| Discoverability | store search and store ranking | search engines and owned channels | Two separate visibility markets with their own rules |
The cost types of a native app
The first cost type arrives before anything has been developed. Membership of the Apple Developer Program costs 99 USD per year, the enterprise variant 299 USD per year (Apple). At Google, registering a developer account carries a one-off fee of 25 USD (Google). These are manageable amounts, but they recur or are permanently tied to an account someone has to maintain: certificates, keys, access rights, two-factor procedures. If that maintenance lapses, publishing stops, and when an agency changes, account ownership is the most frequent breaking point. Anyone planning an app therefore settles account ownership before commissioning, with the same care a workable requirements specification for a shop project demands.
The second cost type only hits digital revenue and is therefore frequently overstated. Anyone shipping goods pays no platform commission on a purchase made in the app; according to the operator, 97 percent of developers distribute their apps without a service fee (Google). As soon as digital goods, subscriptions or credits are sold in the app, however, the share applies. In the small business programme it stands at 15 percent up to one million US dollars in annual proceeds (Apple). In the EU, from 1 October 2026, sales processed through the in-house payment flow carry a rate of 26 percent, and 15 percent for participants in the small business programme and for subscriptions after their first year (Apple). Google Play settles separately: for purchases in the European Economic Area a distinct scale has applied there since 30 June 2026, with 10 percent on subscriptions and on the first million US dollars of annual earnings, 20 percent on other purchases from new installs and 25 percent from existing installs, each plus a 5 percent billing fee; the tier of 30 percent above one million covers only the remaining markets (Google). For a shop that ships goods this is a side condition; for a shop with digital add-on services it is a hard question of margin.
A further cost type in the EU terms affects only some developers: anyone who has signed the separate addendum for alternative EU terms pays 0.50 euro for each annual first install above one million within the preceding twelve months (Apple). The first million stays free. With the revised terms this fee expires: from 1 October 2026 a core technology commission of 5 percent on digital revenue in apps distributed outside the App Store takes its place (Apple). For most merchants both items stay small, and that is precisely why they belong in the calculation. They show that the cost structure of an app is set by a party that does not sit at the negotiating table, and that it can change within a few months. On the web this cost type does not arise, because no entity stands between shop and customer that could levy it.
| Cost type | Native app | Installable web app | Note |
|---|---|---|---|
| Entry | 99 USD annually (Apple), 25 USD one-off (Google) | included in hosting | Falls due before development |
| Development | one codebase per platform or a cross-platform framework | one codebase, the same one as the shop | The largest item in both cases |
| Revenue share | in the EU 15 to 26 percent on digital goods (Apple) | none | Irrelevant for shipping goods only |
| Core technology commission | 5 percent on digital revenue outside the App Store, from 1 October 2026 (Apple) | none | Applies to distribution outside the App Store |
| Release | review before every version (Apple) | no external review | Affects the cadence of changes |
| Maintenance | annually mandated target API (Google) | browser maintenance by the vendors | The effort arises even without new features |
The cost types of an installable web app
A PWA shifts the costs from the platform into your own house. The manifest itself is a small file; the effort sits in what comes after it. The service worker has to decide which responses may come from the cache and which must be fetched fresh. With prices, stock levels and shopping carts, the wrong answer is more expensive than a slow one. Icons are needed in several resolutions, the start URL needs a marker so installations can later be told apart from ordinary visits, and the switch between offline and online state needs visible feedback. None of this takes months, but all of it touches an existing front end in many places.
{
"name": "Beispielshop",
"short_name": "Beispielshop",
"start_url": "/?quelle=homescreen",
"scope": "/",
"display": "standalone",
"background_color": "#f0f7f6",
"theme_color": "#004d43",
"icons": [
{ "src": "/icons/app-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icons/app-512.png", "sizes": "512x512", "type": "image/png" },
{ "src": "/icons/app-maskable.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
]
}The real price of a PWA, though, is speed. An installable web app that starts slowly loses exactly the advantage it was built for. The distribution of Core Web Vitals shows how much room the market has: 48 percent of mobile websites and 56 percent of desktop websites reached good values in 2025, up from 44 and 55 percent the year before (Web Almanac). Roughly half of mobile websites therefore miss the thresholds, and anyone raising the app question usually has a speed problem on the web first, and a second channel routes around it rather than solving it. The order is therefore usually: fix Core Web Vitals and response time to input first, then talk about installability.
Running an installable web app demands a dependable delivery chain: certificates, caches, versioning of the application files and a way to withdraw a shipped version. A service worker sticks stubbornly to what it once learned; a faulty version can therefore stay in the field longer than a faulty deployment on the server. Anyone taking this route plans the rollback from the start, just as they would for any other change process in hosting and operations.
Push, offline and home screen compared
The most common argument for an app is the notification, and it has weakened. Since iOS and iPadOS 16.4, Safari also supports web push for web apps on the home screen (WebKit); the feature does require the user to have placed the site there beforehand. On Android, web push has been available directly in the browser for longer. The question is no longer whether a website can send notifications, but under what condition. The prior placement on the home screen is the actual difference from an app, and a hurdle that wants to be placed deliberately within the purchase journey. How notifications can be used in a shop without burning through permission is covered in the article on web push and customer retention.
The acceptance rate qualifies the argument further. Among sites with a service worker, only 7 percent use push events at all, and the same share responds to a notification click (Web Almanac). And where the question is asked, the answer is rarely positive: in an analysis of permission prompts from June 2022, mobile devices accepted 19 percent of requests, denied 35 percent, ignored 34 percent and dismissed 13 percent (Web Almanac). A denial is usually final. Anyone treating the channel as a load-bearing column of an app calculation is counting on a minority of a minority. That is no argument against notifications, but it is an argument against the sentence that an app pays off because of push.
Home screen
Both routes end up as an icon on the device. The difference lies in the path there: the store leads through a familiar flow, the web app needs a prompt at the right moment and, on the iPhone, an extra step through the share menu.
Offline operation
A service worker can hold categories, product pages and the cart. For a shop the honest benefit is limited, because ordering without a connection ends at payment. More valuable is the quick return after a network change.
Payment
In the browser, the shop's own payment methods are available with no platform involved. In the app, digital goods run through the store's payment flow with the associated commission, in the EU 15 to 26 percent from 1 October 2026 (Apple).
Device features
Camera, location and notifications are available in the browser; deeper access to sensors and persistent background processing remain the app's domain. For a goods shop, that gap is rarely decisive.
One detail decides offline capability more often than the data sheets suggest: Safari deletes a site's script-writable storage after seven days of Safari use without interaction with that site (WebKit). A site visited only occasionally therefore loses its local store regularly. For web apps placed on the home screen, the vendor counts its own days of use and, according to the post, exempts them from this rule. That turns installation from a comfort feature into a technical precondition: offline capability holds reliably only in the installed version. Anyone using offline as an argument must first raise the installation rate, and that is not a question of technology but of how you ask.
Review, maintenance and the cadence of the stores
An app is not published, it is admitted. The operator's transparency report names 2,093,244 rejected submissions for the year 2025 (Apple), against 9,100,620 submissions reviewed. Rejected does not mean final, because 387,087 submissions were approved after a rejection (Apple). For planning, that means less a risk of failure than a risk to the schedule. A campaign whose launch depends on an approval carries a dependency that cannot be resolved in-house. On the web, your own delivery process decides the timing, which matters most for changes with a fixed deadline.
Visibility in the store is no free ride either. The same report lists 2,172,472 apps in the App Store (Apple). A new shop app therefore enters a market where nobody is searching for it at first. Installations must come from owned channels: the newsletter, the order confirmation, the parcel insert, the physical shop. Those very channels are equally open to a web app, with the difference that the first click lands in the shop rather than in a directory. Anyone connecting both worlds is thinking about the handover between branch and shop anyway; the mechanics are described in the article on connecting the point-of-sale system.
- The obligation to adapt is annual: new apps and updates must target at least Android 16 (API level 36) to be submitted to Google Play; Wear OS and Automotive require API level 35, TV and XR API level 34 (Google).
- Size costs installations: if an app exceeds 200 MB, the store shows a size warning when installing over a mobile connection (Google).
- Two operating systems mean two review cycles and therefore two dates on which a change reaches the field, or fails to.
- Maintenance continues without new features: signatures, certificates, privacy declarations and age ratings all need upkeep, otherwise an app drops out of the listing.
Law: accessibility applies to both routes
One argument regularly falls off the table during the trade-off: the accessibility obligation does not distinguish between channels. The German Accessibility Strengthening Act covers services in electronic commerce offered through websites and through applications on mobile devices (BFSG). Anyone building an app therefore doubles not only the development effort but also the accessibility testing effort, with its own rulebook per platform, its own assistive technologies and its own test devices – the most frequently underestimated item in app calculations. What needs doing on the web is set out on the page about accessibility under the BFSG; for media content, the article on subtitles and transcripts adds the rest.
Die Ordnungswidrigkeit kann in den Fällen des Absatzes 1 Nummer 1, 7, 8, 9 und 10 mit einer Geldbuße bis zu hunderttausend Euro und in den übrigen Fällen mit einer Geldbuße bis zu zehntausend Euro geahndet werden.
Barrierefreiheitsstärkungsgesetz (German Accessibility Strengthening Act), Section 37(2): fines of up to one hundred thousand euro
There is one exemption, and it is sharply drawn: a micro-enterprise is a business employing fewer than ten people and either generating at most 2 million euro in annual turnover or whose annual balance sheet total does not exceed 2 million euro (BFSG). Anyone below that is exempt from the obligation for services; anyone above it, or growing past it, falls under it, for every channel they operate. It is therefore worth checking the threshold before the app decision: a channel not covered today may be covered in the next financial year. Proof does not appear retroactively but through documented testing during development.
The second legal factor concerns the terms themselves. The conditions of the large platforms are under European supervision: the Digital Markets Act provides for fines of up to 10 percent of total worldwide turnover in the preceding financial year where a gatekeeper fails to comply (Digital Markets Act). A gatekeeper is, among other criteria, a provider whose core platform service reaches at least 45 million monthly active end users and at least 10,000 yearly active business users in the Union (Digital Markets Act). For a merchant this is not an obligation but a planning factor: commission rates and payment flows in the stores are the subject of ongoing proceedings and have changed several times in recent years. A calculation resting on today's percentage should therefore assume a corridor rather than a point value.
The decision in five questions
The decision boils down to a handful of questions, all answerable with data from your own house. None of them is technical. Once they are answered, you no longer need a debate of principle, only an order of work. The answers belong in writing: they justify the budget allocation later and allow a decision to be reviewed after a year on the facts instead of renegotiated.
- How high is the share of returning buyers? An app pays off through repeat purchases. With mostly one-off purchases the basis is missing, because installation stands as a hurdle before the first purchase.
- Do we sell digital goods? As soon as subscriptions, credits or unlocks are sold in the app, the revenue share of 15 percent in the small business programme applies (Apple). With shipping goods only, it stays out of the picture (Google).
- Does the mobile shop meet the speed thresholds today? As long as the answer is no, an app relocates the problem instead of solving it. At 48 percent good mobile values across the web, that is the common case (Web Almanac).
- Do we need device features beyond the browser? Persistent background processing, deep sensor access or operation without a connection are genuine reasons. Notifications alone have hardly qualified since iOS and iPadOS 16.4 (WebKit).
- Who maintains the second channel in three years? The annual obligation to adopt new target APIs (Google) and the double accessibility testing (BFSG) continue long after the project budget has run out.
| Starting position | Obvious route | Reasoning |
|---|---|---|
| Shipping goods, few repeat purchases, mobile shop with speed problems | web first | The lever is load time, not the channel (Web Almanac) |
| Shipping goods, high share of regulars, fast mobile shop | installable web app | Home screen and push without a platform fee (WebKit) |
| Digital goods or subscriptions as the main revenue | calculation with a commission corridor | 15 to 26 percent shifts the margin noticeably (Apple) |
| B2B with logged-in existing customers | web app in a closed area | Discoverability in a store plays no role here |
| Branch business with loyalty cards and receipt processes | assess both, web first in order | The handover between till and shop is the real lever |
| Device-level features as the product core | native app | The browser does not reach these interfaces |
A twelve-week approach
Anyone unwilling to decide at the drawing board can work it out in twelve weeks without commissioning an app first. The approach costs measurement time rather than development budget and delivers figures that apply to your own shop. Every stage retains value even if the decision ultimately goes against an app.
- Weeks 1 to 2: measure the starting position. Mobile revenue share, repeat purchase rate, share of logged-in customers and the load time metrics per page template. Without these four values, every calculation remains an opinion.
- Weeks 3 to 5: fix speed on the web. Images, third-party scripts, server response time. This work pays into both routes and is the precondition for installability to have any benefit at all.
- Weeks 6 to 8: add the manifest and service worker. Icons, start URL, display mode, a deliberately chosen caching strategy and a marker on the start URL so installations can be evaluated later.
- Weeks 9 to 10: offer installation actively. A prompt after the first purchase, not on the first visit. The rate from this phase is the most reliable prediction of app adoption.
- Weeks 11 to 12: build the calculation. Set installation rate, repeat purchase rate of the installed group and the cost types from this article against each other. Only now is the app question decidable on the facts.
Between a mobile website and a native app sits the installable web app, and it is missing from most proposals precisely because it sells poorly as a project. Yet it is the only step that reliably shows whether customers want an icon on the home screen at all. Only 3.5 percent of mobile sites have implemented service worker and manifest together (Web Almanac); taking this step yields data that would otherwise only arrive after the app has been built.
What belongs on the measuring bench first
Three figures settle the question, and none of them appears in a proposal. First, the share of mobile revenue in total revenue, because it caps the lever. Second, the share of returning buyers, because it determines whether an installation is ever put to use. Third, load time on smartphones, because it underpins both routes and because roughly half of mobile websites miss the Core Web Vitals thresholds (Web Almanac). Anyone who knows these three values can set the cost types against them: entry, share, review, maintenance. Only then does the question of principle turn into a presentable calculation.
The second point is duration. A website can be dismantled; an app usually stays in operation for several years, with annual adaptation to new target versions (Google) and a testing obligation for accessibility that applies to both channels (BFSG). Operation is the larger part of the calculation, not development. Anyone quantifying it in advance makes a decision that holds; anyone skipping it has a channel in two years that nobody maintains. How requirements, effort and operation come together into a decision belongs in structured consulting and concept work before development budget is committed. For the technical implementation on the web, the same standard then applies as for any other custom development: measurable, maintainable, documented.
HDE Online-Monitor 2026 with data from IFH Köln: mobile revenue shares, the app-to-website ratio, market sizes for online retail. Eurostat, E-commerce statistics for individuals, data extracted February 2026. Federal Statistical Office of Germany, internet use and online purchases for private purposes, as of 20 April 2026. Web Almanac 2025, PWA chapter and Performance chapter, plus Web Almanac 2022 for notification acceptance rates. Apple: App Store Small Business Program, payment options in the App Store in the EU, Core Technology Fee, program enrollment and the App Store Transparency Report 2025. Google: service fees and registration in the Play Console, target API level requirements and guidance on app size. WebKit: web push for web apps on iOS and iPadOS, and the deletion of local storage after seven days. German Accessibility Strengthening Act, Section 2 numbers 17 and 26 and Section 37(2). Regulation (EU) 2022/1925, Articles 3 and 30. All sources with deep links and verbatim quotes are held in the metadata of this article.
No, it is a different distribution route with different limits. It sits on the home screen, starts without a browser bar, holds content locally and, since iOS and iPadOS 16.4, sends notifications (WebKit) – with no store, no review and no revenue share. Limits show up with deep device access and persistent background processing. For a goods shop, the typical requirements sit within what the browser offers.
That depends less on the range than on the purchase rhythm. Since smartphone revenue splits roughly evenly between apps and mobile websites (HDE), an app usually replaces existing routes rather than opening new ones. It becomes economical where many customers order several times a year; with one-off purchases, the installation hurdle is usually larger than the benefit.
The pure platform costs are low: 99 USD per year for the Apple Developer Program (Apple) and a one-off 25 USD for a Play Console account (Google). The operating cost sits in maintenance: a current target API on every update (Google), certificates and privacy declarations, plus a fresh review per version (Apple). An operating budget therefore counts person-days per year, not fees.
Yes, since iOS and iPadOS 16.4 Safari supports web push for web apps on the home screen (WebKit). The condition is that the site has been placed there beforehand. The acceptance rates show how load-bearing the channel is: on mobile devices 19 percent of requests were accepted and 35 percent denied (Web Almanac), and only 7 percent of sites with a service worker use push at all (Web Almanac).
Yes. The law covers services in electronic commerce offered through websites and through applications on mobile devices (BFSG). Breaches can be fined up to one hundred thousand euro (BFSG). Micro-enterprises with fewer than ten employees and at most 2 million euro in annual turnover or balance sheet total are exempt (BFSG). A second channel therefore usually means a second round of testing as well.
With what benefits both routes. First load time on the mobile web, because roughly half of mobile websites miss the Core Web Vitals thresholds (Web Almanac). Then the manifest and service worker: little effort, and data on the willingness to install. Only once that rate exists is the app question decidable with figures instead of guesses. Which retention periods apply to the data stored along the way is set out in the article on the deletion concept and retention periods.