# PWAs on iOS by version (iOS 11.3 to iOS 26)
> A release-by-release record of what iOS gave Home Screen web apps, from service workers in 11.3 to added sites opening as web apps by default in iOS 26.
What a web app can do on an iPhone depends on both the iOS release and the manifest it ships.
Releases added capabilities such as service workers, push, badging, and revised storage quotas,
while manifest members affect its display mode, icon, and identity. This entry is the dated list,
so a support floor can be chosen deliberately instead of guessed at.
## How it works
Each release below changed something a site can observe at runtime, with one exception: the iOS
17.4 entry records a removal in the European Union that was announced and then withdrawn before
the release shipped. The practical consequence is that a support floor is a statement about
capabilities, and the capability tests in the examples are the way to hold to it without reading
the user agent string.
### Before service workers: iPhone OS 1.1.3 and 2.1
Home Screen icons predate everything else here. WebKit's Safari 26.0 feature post records that
iPhone OS 1.1.3 (January 2008) let users add website icons to the Home Screen, where tapping one
opened the site in Safari, and that iPhone OS 2.1 (August 2008) let a developer ask for an
app-like standalone mode with the `apple-mobile-web-app-capable` meta tag. Those two facts set the
pattern every later release adjusted: the user performs the add, and the page's markup only
influences the result.
### iOS 11.3: service workers and the Cache API
Service workers reached iOS in the 11.3 beta, announced in
[Workers at Your Service](https://webkit.org/blog/8090/workers-at-your-service/) (February 2018).
The post is specific about where they run: Safari, applications using `SFSafariViewController`,
and web applications saved to the Home Screen. It is also specific about the limits. WebKit
partitions service workers and their clients by the top-level document origin in addition to the
origin required by the specification, so an `example.com` frame inside a `webkit.org` page gets
its own partition. The Cache API quota in that release was a fixed 50 MiB per partition, and once
reached, a storage operation needing space fails until the page evicts entries itself. WebKit also
removes service worker registrations that go unused for a few weeks, and caches that are not
opened for a few weeks, so an offline-first app has to tolerate losing either at any time.
### iOS 11.4: the Web Application Manifest
The W3C began standardizing Web Application Manifests in 2013, browser support started in November
2014, and Safari adopted the format in March 2018 with iOS 11.4, as the Safari 26.0 post records.
From that release the manifest joined the `apple-mobile-web-app-capable` meta tag as a way to
decide whether an added icon produced a web app or a bookmark: the post's wording is that for the
last 17 years a site needed either the meta tag or a manifest `display` value to open as a web app.
That rule held until iOS 26 moved the decision to the user.
### iOS 15.4: manifest timing and manifest icons
Two changes in Safari 15.4 affect how the manifest is read. The browser now fetches the manifest
during page load rather than at the moment the user chooses Add to Home Screen, which lets the
file describe a page viewed in Safari as well. And icons declared in the manifest became usable:
Safari and iOS use them when no `apple-touch-icon` is defined in the HTML head and the manifest's
icon entry either omits `purpose` or sets `"purpose": "any"`. An `apple-touch-icon` link still
takes precedence, deliberately, so a site can keep an iOS-specific icon distinct from the one
other mobile platforms get.
### iOS 16.4: push, badging, and manifest identity
Safari 16.4 is the release that made an installed web app comparable to an app. It added Web Push
for web apps added to the Home Screen, built on the Push API, the Notifications API, and service
workers, with notifications appearing on the Lock Screen, in Notification Center, and on a paired
Apple Watch, and configurable through Focus. It added the Badging API for Home Screen web apps,
with permission granted automatically once the user allows notifications. It added support for the
manifest `id` member so that several installs of one web app stay distinguishable. And it let
third-party browsers offer Add to Home Screen from the Share menu.
### iOS 17: the storage quota rewrite
The quota numbers changed in Safari 17.0 and in WebKit apps on iOS 17, documented in
[Updates to Storage Policy](https://webkit.org/blog/14403/updates-to-storage-policy/). A browser
app, meaning one that can be set as the default browser, gets an origin quota of up to 60 % of
total disk space and an overall quota of up to 80 %; other apps get up to 15 % and 20 %. A
cross-origin frame sits in its own partition at 10 % of the main frame's origin quota. The release
also stopped prompting users about a site wanting more space, and brought full support for the
Storage API, with `navigator.storage.persist()` granted on heuristics that include whether the
site is open as a Home Screen web app. A web app running standalone gets the same origin and
overall quota it would have inside the browser app, so installing does not buy extra room.
### iOS 17.4 in the EU: a removal announced and withdrawn
In February 2024 Apple said Home Screen web apps would be removed for users in the European Union
as part of its Digital Markets Act compliance. Its developer support page gave the decision in
these words: "to comply with the DMA's requirements, we had to remove the Home Screen web apps
feature in the EU", adding that EU users would reach websites "through a bookmark with minimal
impact to their functionality". The stated reason was that handling the security and privacy
concerns of web apps using alternative browser engines would require building "an entirely new
integration architecture", one that iOS did not have. Open Web Advocacy, which first
noticed the change in the first iOS 17.4 beta, recorded Apple's confirmation on 2024-02-16
([It's Official, Apple Kills Web Apps in the EU](https://open-web-advocacy.org/blog/its-official-apple-kills-web-apps-in-the-eu/),
open-web-advocacy.org).
The removal did not reach a release. An update placed above the original text on the same page
states that Apple "will continue to offer the existing Home Screen web apps capability in the EU",
that this support "means Home Screen web apps continue to be built directly on WebKit and its
security architecture", and that developers and users affected by the removal in the beta "can
expect the return of the existing functionality for Home Screen web apps with the availability of
iOS 17.4 in early March"
([Changes for apps in the European Union, archived 2024-03-04](https://web.archive.org/web/20240304183538/https://developer.apple.com/support/dma-and-apps-in-the-eu/),
web.archive.org). Open Web Advocacy dated the reversal 2024-03-01
([Apple backs off killing web apps](https://open-web-advocacy.org/blog/apple-backs-off-killing-web-apps/),
open-web-advocacy.org), and iOS 17.4 was released on 2024-03-05
([About the security content of iOS 17.4 and iPadOS 17.4](https://support.apple.com/en-us/120893),
support.apple.com). For a support floor the episode adds no new row: the EU kept the existing
capability, and by Apple's statement it stayed built on WebKit.
### iOS 18.4 and iOS 26: declarative push, then installability without rules
Safari 18.4 made Declarative Web Push available on iOS and iPadOS 18.4 for web apps added to the
Home Screen, which is the first notification path on the platform that does not need a service
worker at all. Safari 26.0 then changed what adding to the Home Screen means: by default every
website added opens as a web app, a user who wants a browser bookmark turns off Open as Web App
while adding, and the post states plainly that there are now zero requirements for installability
in Safari. A manifest keeps its value, since icons declared in it are still used, and Safari 26.0
additionally accepts SVG files and data URLs for icons.
## Examples
Both snippets are written against capabilities rather than versions, which is what keeps them
correct on the next release as well.
### Checking for room before a large precache
The storage ceiling moved in iOS 17, and a site that hard-codes an assumption about it will be
wrong on at least one supported release. Ask instead, and keep a path for the engines that cannot
answer.
```js
async function roomFor(bytes) {
if (!('storage' in navigator) || typeof navigator.storage.estimate !== 'function') {
return true; // No Storage API here: attempt the write and handle the quota error.
}
const { quota = 0, usage = 0 } = await navigator.storage.estimate();
return quota - usage > bytes;
}
```
Returning `true` from the fallback is the honest choice: the write may still succeed, and the
caller has to handle `QuotaExceededError` in either branch. Treating an unanswerable question as a
refusal would disable offline support on engines that would have coped.
### Declaring an icon every supported release can use
Icon resolution differs across the range this entry covers, so declare both forms and let each
release pick. The `apple-touch-icon` link wins where both are present, which makes it the
predictable floor.
```html
```
The manifest still earns its place: its icons are used from iOS 15.4 when no `apple-touch-icon`
exists, its `id` keeps multiple installs apart from iOS 16.4, and from iOS 26 its icon entries may
be SVG. On iOS 15.4 and later, the manifest icon is used when no `apple-touch-icon` is present if
its `purpose` is omitted or includes `any`.
## Observed behaviour
Debugging a Home Screen web app's service worker used to be a race against the event you wanted to
inspect. Safari 26.0 removed the race, and the menu path is worth writing down.
:::observed
Safari 26.0 (English UI): opening Inspect Apps and Devices from the Develop menu lists each app
and Home Screen web app, and the three-dots menu beside an entry carries the item
"Automatically Inspect New Service Workers", alongside "Automatically Pause New Service Workers".
Documented in
[WebKit Features in Safari 26.0](https://webkit.org/blog/17333/webkit-features-in-safari-26-0/)
(webkit.org), which gives the reason it was needed: a `push` event can be handled before the
Develop menu even lists the worker.
:::
The pause option is the one that matters for push work, because it stops execution early enough to
set a breakpoint inside the handler rather than after it has returned.
## See also
- [PWAs on iOS and Safari](/reference/platforms/ios-safari/)
- [Web Push on iOS and iPadOS (16.4+)](/reference/notifications/ios-safari-push/)
- [StorageManager.persist() and persisted()](/reference/storage/persistence/)
- [Home Screen web app storage isolation on iOS](/reference/storage/home-screen-storage-isolation/)
- [Workers at Your Service](https://webkit.org/blog/8090/workers-at-your-service/) (webkit.org)
- [Updates to Storage Policy](https://webkit.org/blog/14403/updates-to-storage-policy/) (webkit.org)
- [Apple backs off killing web apps](https://open-web-advocacy.org/blog/apple-backs-off-killing-web-apps/) (open-web-advocacy.org)
- [WebKit Features in Safari 16.4](https://webkit.org/blog/13966/webkit-features-in-safari-16-4/) (webkit.org)