Home Screen launch on iOS 18.6.2

Published 2026-11-012026-11-01By Carey Gill · Editorial process

A Home Screen launch on iOS 18.6.2 depended on whether the saved page qualified as a web app. Use these field notes when you need to reproduce the pre-iOS 26 launch path, distinguish a standalone app from a bookmark that opens in Safari, or compare a later device against the dated baseline.

The recorded run used one iPhone 16 Pro on iOS 18.6.2 (22G100) on 2026-10-20. Its setup used an HTTPS test origin and a manifest variant. It also included a page with no manifest and two distinguishable icons; Safari Web Inspector supplied the instrumented values. WebKit separately documents that third-party browsers can offer Add to Home Screen for HTTP or HTTPS URLs displayed in a WKWebView (Web Push for Web Apps on iOS and iPadOS, webkit.org). The full device study and its public data package contain the screenshots and JSON reads.

Support scope

These steps describe the measured iOS 18.6.2 launch path. WebKit’s iOS and iPadOS 16.4 documentation covers Home Screen web apps whose manifest uses standalone or fullscreen, while its iOS 26 documentation records a changed default for sites added to the Home Screen. Treat the recorded device result as an iOS 18.6.2 baseline, not as a browser-wide compatibility statement.

Prepare two launch cases

Serve one page without a manifest or icon. Omit apple-mobile-web-app-capable and theme-color from it as well. Serve a second page with a manifest whose display is standalone. Give that manifest an in-scope start_url, then set its scope and icons. The test used a 192 px purpose: any icon in the manifest and a distinguishable 180 px apple-touch-icon on another case.

Open each URL in Safari before adding it. Record the URL and the manifest fields. Also record the exact build under test. The expected setup result is two saved items whose launch configuration differs in one intentional way. WebKit’s iOS and iPadOS 16.4 documentation says a site with a manifest whose display mode is standalone or fullscreen becomes a Home Screen web app; without that manifest or the legacy capable meta, the site is saved as a bookmark that opens in the default browser (Web Push for Web Apps on iOS and iPadOS, webkit.org).

Add each page from Safari

For each case, tap Share, choose Add to Home Screen, keep a note of the displayed name and URL, and tap Add. Launch the new icon from the Home Screen. Capture the first screen before navigating.

On the recorded iOS 18.6.2 device, the page with no manifest and no icon opened in Safari. The address bar and toolbar were visible. navigator.standalone was false; only display-mode: browser matched. The manifest app opened without Safari’s browser chrome. It returned navigator.standalone true and matched only display-mode: standalone (manifest-less launch result; standalone viewport result).

Do not generalize that outcome to iOS 26 or later. WebKit documents a changed default in iOS 26: every site added to the Home Screen opens as a web app unless the user turns off Open as Web App (WebKit Features in Safari 26.0, webkit.org). These notes preserve the 18.6.2 path for comparison.

Read the launch context

Enable Web Inspector on the phone under Settings > Apps > Safari > Advanced. Connect the phone to a Mac, open Safari’s Develop menu, and select the foreground page. Run this expression in both the Safari tab and the saved item:

function readLaunchContext() {
  if (typeof window.matchMedia !== 'function') {
    return {
      mode: 'manual',
      action: 'Record browser chrome and the launch URL manually',
    };
  }

  return {
    standalone: navigator.standalone === true,
    browser: matchMedia('(display-mode: browser)').matches,
    installed: matchMedia('(display-mode: standalone)').matches,
    viewport: [innerWidth, innerHeight],
    screen: [screen.width, screen.height],
    controller: navigator.serviceWorker?.controller?.scriptURL ?? null,
    marker: localStorage.getItem('launch-marker'),
  };
}

JSON.stringify(readLaunchContext(), null, 2);

The early return gives the operator a manual recording action when the display-mode probe is unavailable. The recorded standalone output contained standalone: true and installed: true. Its viewport measured 402 x 812 CSS px on a 402 x 874 screen. The Safari tab and the manifest-less saved item contained standalone: false and browser: true. Their viewport measured 402 x 678. Those are measurements from one build and device, not thresholds for other screens.

Write a marker in Safari before adding the item if storage separation matters to the test:

localStorage.setItem('launch-marker', 'TAB-2026-10-20');
localStorage.getItem('launch-marker');
// "TAB-2026-10-20"

In the recorded run, the manifest-less item opened in Safari and saw Safari’s marker and service worker. The standalone Home Screen app used separate localStorage and IndexedDB. WebKit documents that Safari 17.2 copies cookies into a newly created Home Screen web app but does not copy other local storage, and that no other website data is shared afterward (WebKit Features in Safari 17.2, webkit.org). The localStorage result therefore does not describe cookie behavior.

Check which icon was selected

Make the icon sources visibly different, then compare the Home Screen tiles after adding the pages. The 18.6.2 run selected the 180 px apple-touch-icon when both that link and manifest icons existed. With manifest icons only, it selected the 192 px purpose: any icon. Pages without either source received a letter tile (Home Screen icon selection).

Keep this as a device observation tied to the archived screenshots. It does not establish the selection behavior of another iOS release. Another icon set or purpose value also lies outside the observation. If your production tile is wrong, inspect the fetched apple-touch-icon and manifest before replacing every icon at once.

Record the status-bar boundary

Compare the CSS viewport with screen.height, and record env(safe-area-inset-top) with a probe element. In the default-style apps from this run, the portrait viewport was 812 CSS px high on an 874 px screen, leaving a 62 px strip outside the page viewport; the top safe-area inset read 0. The Web App Manifest permits standalone to retain system UI such as a status bar (Web Application Manifest, display, w3.org).

The separate black-translucent case with viewport-fit=cover used a 402 x 874 viewport and reported a 62 px top inset. Treat that as a separate configuration. It does not revise the default-style result. The measured details and screenshots are in status-bar black-translucent geometry.

Handle the failure path

If tapping the icon opens Safari when you expected a standalone app on iOS 18.6.2, inspect the delivered manifest in that Safari session. Confirm that the link resolves and the response is valid JSON. Check that start_url lies inside scope and display is standalone or fullscreen. Remove the saved item and correct the response, then add the item again. The expected result is navigator.standalone === true and a matching display-mode: standalone query after relaunch.

If the item still opens in Safari, preserve the manifest response and screenshot. Preserve the OS build and console output too. The baseline did not test pages with the legacy capable meta but no manifest. It also did not test iPadOS or other iPhone models. Other iOS 18 builds were outside the test. A mismatch outside the tested configuration needs its own result instead of being folded into this one.