使用JavaScript检测iOS端Safari Webview与原生Safari差异

• PWA相关能力差异：第三方App调用的WebView（包含自定义WKWebView、SFSafariViewController两种官方实现）默认不提供系统级「添加到主屏幕」入口，分享面板会自动移除该选项；不会触发PWA安装相关的beforeinstallprompt事件；Service Worker的后台推送、离线持久化缓存能力受宿主限制，部分宿主会主动拦截Web Push权限申请。
• 权限与API差异：WebView的权限继承自宿主App，无法独立申请位置、相机、麦克风的持久授权；Apple Pay、屏幕录制、Safari扩展交互等原生Safari专属API默认被禁用，是否开放完全由宿主决定；原生Safari自带的阅读器模式、网页翻译、通用链接跳转能力在WebView中不可用。
• 存储策略差异：原生Safari的网站存储（LocalStorage、IndexedDB、Service Worker缓存）独立持久化，遵循系统统一的网站数据保留规则；WebView的网站数据默认与宿主App存储隔离，部分社交类宿主（如Twitter）会定期清理长期未访问的WebView站点数据，无法保证持久化存储可靠性。
• 交互逻辑差异：WebView的导航栏、操作菜单由宿主自定义，长按链接、页面预览的操作项会被宿主裁剪，不会展示原生Safari的全量操作选项。

采用「特征属性优先、UA匹配兜底、能力校验补漏」的组合检测方案，可覆盖Twitter等主流App的内嵌场景，误判率极低：

• 核心特征判定（全版本稳定）：所有第三方App内嵌的WebView环境下，window.navigator.standalone属性值为undefined。原生Safari浏览器中该值固定为false，已添加到主屏幕的PWA环境下该值固定为true，Chrome/Edge/Firefox等iOS端独立第三方浏览器会主动实现该属性，不会返回undefined。
• UA特征匹配：主流App内嵌WebView都会在默认Safari UA后追加自身标识，可通过正则匹配快速命中特定宿主：Twitter客户端内嵌WebView的UA会包含Twitter for iPhone/Twitter for iPad字段，其他常见内嵌场景可追加对应规则，如微信对应MicroMessenger、微博对应Weibo。
• 能力兜底校验：针对部分修改UA抹除宿主标识的场景，可补充检测原生Safari专属对象：原生Safari下window.safari对象存在且包含完整的pushNotification、extensions属性，WebView环境下该对象要么不存在，要么为宿主注入的精简空对象。

可直接复用的检测代码如下：

function isIOSAppEmbeddedWebView() {
  // 非iOS环境直接返回false
  if (!/iPhone|iPad|iPod/i.test(navigator.userAgent)) return false;
  // 已添加到主屏幕的PWA环境，不属于内嵌WebView
  if (window.navigator.standalone === true) return false;
  const ua = navigator.userAgent;
  // 匹配已知宿主的UA标识
  const hostUARules = /Twitter|MicroMessenger|Weibo|DingTalk|FBAN|FBAV/i;
  // 组合特征判定
  const isEmbeddedWK = window.navigator.standalone === undefined;
  const hasHostIdentifier = hostUARules.test(ua);
  const noNativeSafariObj = !window.safari || !window.safari.pushNotification;
  return isEmbeddedWK && (hasHostIdentifier || noNativeSafariObj);
}

检测命中内嵌WebView场景后，可直接展示操作引导：提示用户点击WebView右上角的更多按钮，选择「在Safari中打开」，再通过原生Safari的分享面板完成「添加到主屏幕」操作即可。

内容的提问来源于stack exchange，提问作者napster499