On this page · 8 sections
Summary. From 31 August 2026, new apps and app updates must target Android 16, API level 36, to be submitted to Google Play, and existing apps must target at least API level 35 to stay available to new users on newer devices. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later. Google Play charges Indian developers 15% on the first $1M of annual revenue and 30% above it, with the alternative billing system in India reduced by only 4 percentage points. Apple charges $99 a year for the Developer Program and 15% under its Small Business Program below $1M in proceeds. A Progressive Web App avoids every one of those, and it also cannot do four things on iOS that many consumer products need. That trade, not a preference for web technology, is the whole decision.
What a PWA actually saves
| Cost or obligation | Native on Google Play | Native on the App Store | Progressive Web App |
|---|---|---|---|
| Registration or membership | US$25 one-time registration fee | $99 per membership year | None |
| Commission on digital purchases | 15% on first $1M annual revenue in India, 30% above; subscriptions 15% | 15% under the Small Business Program below $1M in proceeds, standard rate above | None |
| Alternative billing relief | Service fee reduced by 4 percentage points in India and South Korea | Not applicable | Not applicable |
| Platform version treadmill | API level 36 for submissions from 31 August 2026; API level 35 minimum to stay available to new users | Xcode 26 and an OS 26 SDK since 28 April 2026 | None; no target level exists |
| Review before shipping a fix | Yes | Yes | No |
The Indian alternative-billing number is the one that surprises people. Google reduces the service fee by 4 percentage points for developers offering an alternative billing system alongside Play's in India, which puts the floor at 11% and the upper band at 26% rather than at zero. Alternative billing is a discount, not an exit.
Note also that India sits outside the newer fee regime. From 30 June 2026 Google split its rates for the EEA, UK and US by whether a user's install is new or existing, with bands of 10%, 20% and 25% plus a 5% billing fee. For all remaining markets, including India, the older structure applies until that rollout goes global: 15% on the first $1M of annual developer revenue, 30% above, and 15% on auto-renewing subscriptions regardless of revenue.
The version treadmill is the underrated cost. It is not the engineering work of a target-SDK bump, which is usually small. It is that the bump is compulsory, annual, and enforced by delisting, which means an app you would otherwise leave alone still needs a release, a regression pass and a review cycle every year. Google will grant an extension to 1 November 2026 for the current deadline on request, which tells you how routinely teams miss it. A PWA has no target API level and no annual recompile.
Where a PWA still cannot follow, on iOS
This is the part vendors skip. Four constraints, all verified against Apple and WebKit's own material.
Web Push works on iPhone, but only for web apps added to the Home Screen. Support arrived in iOS and iPadOS 16.4, and the permission request must come in response to direct user interaction such as tapping a subscribe button. If your users bookmark the site rather than installing it, they get no notifications at all. On the other hand, you do not need Apple Developer Program membership to use Web Push, so the $99 stays saved.
Storage is evicted unless the user installs. Safari's Intelligent Tracking Prevention applies a 7-day cap on all script-writable storage, and it deletes website data for classified domains that have not received first-party user interaction in the last 30 days of browser use. Home Screen web apps are explicitly exempt: WebKit's own documentation states the first-party domain of a Home Screen web application is skipped in the website data removal algorithm. So the install is not a nice-to-have on iOS; it is what makes persistent state work.
There is a corollary worth designing around. WebKit also states that the website data of Home Screen web apps is kept isolated from Safari. A user who was signed in inside Safari and then installs the web app arrives at a signed-out session, because the two data stores are separate. Handle that transition explicitly or your install funnel will look broken.
Background sync does not exist on iOS. WebKit's published standards positions record no formal position on either Web Background Synchronization or Background Fetch, with privacy, power and maintenance listed as concerns. Neither ships. Any product whose value depends on the app doing work while closed, such as reliable offline queue flushing or content prefetch overnight, needs native code on iPhone.
Nothing in this changed recently. The most recent WebKit release post, covering Safari 26.6 on 27 July 2026, describes a WebAssembly streaming refinement and eight bug fixes across CSS, service workers, networking, extensions and WebRTC. It says nothing about web apps, manifests or push. Plan against the current capability set rather than an expected one.
Getting installable on Android
Chrome's published install criteria are specific, and two of them catch teams out.
The app must not already be installed. The user must have clicked or tapped the page at least once, at any time, including on a previous load, and must have spent at least 30 seconds viewing the page. The site must be served over HTTPS. The manifest must include a short name or name, a start URL, icons including both a 192px and a 512px asset, and a display value of fullscreen, standalone, minimal-ui or window-controls-overlay.
The 30-second engagement threshold means the install prompt is not available on a landing page a user bounces from, which changes where you can put the call to action. And if your manifest declares related applications with a preference set to true, Chrome directs the user to the Play Store to install your Android app instead, which is either exactly what you want or a silent leak, depending on your strategy.
One caution on the source: Google's install-criteria page carries a last-updated date of September 2024, and the older service-worker requirement has been dropped from it. Re-check against Chrome release notes before you build a launch plan on the exact wording.
India-specific considerations
Three things push the calculation toward a PWA in the Indian market, and one pushes back.
Distribution reach on Android is the strongest argument. India is an Android-majority market, and Chrome's installability path is well supported, so the capability gap that decides the question on iOS is much narrower for the majority of Indian users.
Store economics matter more when average revenue per user is lower. A 15% to 30% commission on a subscription priced for the Indian market removes a larger proportion of a thinner margin than it does elsewhere, and the alternative billing route only recovers 4 percentage points of it.
Update velocity matters where devices and networks vary widely. Shipping a fix without a review queue is worth more when your defect reports cluster on device and network combinations you cannot fully reproduce.
Pushing back: if your product depends on iOS push to users who will not install to the Home Screen, or on background work while the app is closed, the PWA cannot carry it alone. The usual resolution is not a purity contest. It is a PWA as the primary surface with a thin native wrapper on iOS where the capability gap actually bites, which keeps one codebase for the product logic and confines native work to the parts that need it.
On data, the Digital Personal Data Protection Act, 2023 applies identically either way. A web app and a native app collecting the same personal data carry the same duties, so the delivery choice does not change the compliance scope.
How we decide PWA or native
- List the capabilities the product genuinely requires, then mark which ones iOS Safari does not provide. If the list is empty, the discussion is over.
- Price the store cost against your actual revenue model. Commission only matters if you sell digital goods through the app; for a lead-generation or logistics product it is zero either way.
- Count the compulsory release cycles. An annual target-SDK bump plus review is a real maintenance line for a product that would otherwise be stable.
- Model the install funnel on iOS honestly. Push and persistent storage both depend on the Home Screen install, so the install rate is a hard input to the business case rather than a nice-to-have.
- Decide the hybrid boundary deliberately if you need one. A native shell should exist to solve a named capability gap, not as a hedge.
Our engagement model starts with that capability matrix and the store-cost model, delivered as a fixed-scope discovery, because the answer is frequently different from the one the team walked in with. The build then runs on milestones, with the install funnel instrumented from the first release.
eCorpIT builds web and mobile products from Gurugram with senior-led, multi-disciplinary teams and CMMI Level 5 assessed processes. For related reading, our custom software development company guide covers scoping bespoke builds, SaaS development company covers multi-tenancy and billing, and mobile app development company in India covers native partner selection.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based engineering organisation, founded in 2021, that builds Progressive Web Apps, native apps and the hybrid boundary between them. We open with a capability matrix that names exactly which requirements iOS Safari cannot meet for your product, alongside a store-cost model built on your revenue mechanics rather than on generic commission percentages. We design systems aligned with Digital Personal Data Protection Act, 2023 requirements and deliver with senior-led, multi-disciplinary teams under CMMI Level 5 assessed processes. Talk to our team if you want that comparison done on your numbers.
References
Last updated: 16 August 2026.
