iOS 18.6.2 主屏启动实测笔记
发布于
iOS 18.6.2 会根据保存的页面是否符合 Web App 条件，选择不同的主屏启动方式。需要复现 iOS 26 之前的启动路径、分辨独立 App 与 Safari 书签，或给新版设备建立对照时，可以照此记录。
原始实验在 2026-10-20 使用一台 iPhone 16 Pro，系统为 iOS 18.6.2（22G100）。实验配置采用 HTTPS 测试源、一个 manifest 页面、一个无 manifest 页面和两套容易分辨的图标，并用 Safari Web Inspector 读取仪器数据。WebKit 另有说明：第三方浏览器可为 WKWebView 显示的 HTTP 或 HTTPS URL 提供“添加到主屏幕”功能（Web Push for Web Apps on iOS and iPadOS，webkit.org）。截图与 JSON 记录见完整真机研究和公开数据包。
支持范围
链接到“支持范围”一节这些步骤对应实测的 iOS 18.6.2 启动路径。WebKit 的 iOS 与 iPadOS 16.4 文档覆盖 manifest 使用 standalone 或 fullscreen 的主屏 Web App；iOS 26 文档则记录了“添加到主屏幕”后的新默认行为。因此，这份真机结果只作为 iOS 18.6.2 基线，不代表所有浏览器的兼容性。
准备两种启动条件
链接到“准备两种启动条件”一节第一张页面不声明 manifest、图标、apple-mobile-web-app-capable 或 theme-color。第二张页面链接 manifest，令 display 为 standalone，并设置位于 scope 内的 start_url 与图标。原实验还用外观不同的 192 px purpose: any manifest 图标和 180 px apple-touch-icon 分辨来源。
添加前先在 Safari 打开两个 URL，记下 URL、manifest 字段和系统 build。准备完成后，两个主屏项目应只有一项经过设计的启动配置差异。WebKit 的 iOS 与 iPadOS 16.4 文档说明：manifest 把显示模式设为 standalone 或 fullscreen 时，站点成为主屏 Web App；既没有这类 manifest，也没有旧式 capable meta 时，站点会保存为书签，由默认浏览器打开（Web Push for Web Apps on iOS and iPadOS，webkit.org）。
从 Safari 添加页面
链接到“从 Safari 添加页面”一节依次打开每张页面，点分享、添加到主屏幕，记录面板中的名称与 URL，再点添加。从主屏幕点新图标，导航前先截图。
原实验的无 manifest、无图标页面在 iOS 18.6.2 中进入 Safari，地址栏与工具栏可见，navigator.standalone 为 false，只有 display-mode: browser 匹配。manifest App 没有 Safari 浏览器栏，navigator.standalone 为 true，只有 display-mode: standalone 匹配（无 manifest 启动记录；独立视口记录）。
这个结论不能外推到 iOS 26 及以后。WebKit 记载 iOS 26 已更改默认值：添加到主屏幕的站点默认作为 Web App 打开，除非用户关闭 Open as Web App（WebKit Features in Safari 26.0，webkit.org）。这里保存的是 18.6.2 对照条件。
读取启动上下文
链接到“读取启动上下文”一节在手机的“设置 > App > Safari > 高级”中开启 Web Inspector。用线缆连接 Mac，在 Safari 的“开发”菜单选中前台页面。分别在 Safari 标签页和主屏项目中运行：
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);如果 display-mode 探针不可用，early return 会给操作者明确的人工记录动作。已归档的独立 App 输出含 standalone: true、installed: true、402 x 812 CSS px 视口和 402 x 874 屏幕。Safari 标签页与无 manifest 主屏项目则含 standalone: false、browser: true 和 402 x 678 视口。这些是单台设备、单个 build 的测量值，不能当作其他屏幕的判定阈值。
如需检查存储隔离，请在添加主屏项之前先向 Safari 写入标记：
localStorage.setItem('launch-marker', 'TAB-2026-10-20');localStorage.getItem('launch-marker');// "TAB-2026-10-20"原实验中，无 manifest 项目进入 Safari，因此看到了 Safari 的标记和 Service Worker；独立主屏 App 使用另一套 localStorage 与 IndexedDB。WebKit 记载，Safari 17.2 会把 Cookie 复制到新建的主屏 Web App，但不会复制其他本地存储，创建后也不再共享其他网站数据（WebKit Features in Safari 17.2，webkit.org）。所以 localStorage 结果不能代替 Cookie 结论。
核对图标来源
链接到“核对图标来源”一节让各图标的画面明显不同，添加后对照主屏图块。18.6.2 实验中，页面同时提供 180 px apple-touch-icon 和 manifest 图标时，主屏采用前者；只提供 manifest 图标时，采用 192 px purpose: any 图标；两者都没有的页面得到字母图块（主屏图标选择）。
这条记录只对应归档截图中的设备条件，不能确定其他 iOS 版本、其他图标集合或其他 purpose 值会怎样选择。生产图标不符预期时，先检查实际取回的 apple-touch-icon 与 manifest，不要同时替换所有候选文件。
记录状态栏边界
链接到“记录状态栏边界”一节对比 CSS 视口与 screen.height，再用探针元素读取 env(safe-area-inset-top)。默认状态栏样式下，原实验的竖屏视口高 812 CSS px，屏幕高 874 px，页面视口外留下 62 px；顶部安全区读数为 0。Web App Manifest 允许 standalone 保留状态栏等系统界面（Web Application Manifest，display，w3.org）。
单独安装的 black-translucent 案例配合 viewport-fit=cover 后，视口为 402 x 874，顶部 inset 为 62 px。它属于另一种配置，不能用来改写默认样式结果。测量过程和截图见状态栏 black-translucent 几何记录。
处理启动失败
链接到“处理启动失败”一节若 iOS 18.6.2 上点图标进入 Safari，而预期是独立 App，请在同一 Safari 会话检查实际返回的 manifest。确认链接可访问、响应是有效 JSON、start_url 位于 scope 内，并且 display 是 standalone 或 fullscreen。删除已保存项目，修正响应后重新添加。再次启动时，预期结果为 navigator.standalone === true 且 display-mode: standalone 匹配。
如果仍进入 Safari，请保留 manifest 响应、截图、系统 build 和控制台输出。原基线没有测试“只有旧式 capable meta、没有 manifest”的页面，也没有测试 iPadOS、其他 iPhone 型号或其他 iOS 18 build。测试条件之外的差异应形成新记录，不能并入这次结果。