iOS Safari扩展开发：如何实现宿主应用主动向扩展发送消息

方案1：App Group共享存储 + 存储变化监听（推荐，适配iOS15+） #

• 为宿主App和Safari扩展的Target分别开启同一个App Group权限，确保两端可以访问同一共享存储区域
• 宿主App用户触发指定操作时，将需要推送的消息内容、唯一ID、时间戳写入App Group对应的UserDefaults实例，消息结构可自定义
• 扩展侧后台JS脚本注册browser.storage.onChanged监听事件，共享存储内容更新时会触发该事件，直接读取新值即可获取宿主推送的消息
• 若需要确认消息送达，可在扩展处理完消息后回写一个消费标记到共享存储，宿主侧按需读取标记即可

方案2：本地WebSocket长连接（适用低延迟、大消息场景） #

• 宿主App本地启动轻量WebSocket服务，监听本地空闲端口，按需配置后台网络权限避免退后台后服务被系统回收
• 扩展侧后台脚本初始化时主动连接本地WebSocket服务，保持长连接存活，内置异常重连逻辑
• 宿主需要发消息时直接通过已建立的WebSocket连接推送即可，该方案同样支持扩展向宿主主动发消息的双向通信需求
• 注意做好端口冲突检测，遇到占用时自动切换备用端口

方案3：扩展定时轮询（实现最简单，兼容性最高） #

• 开启App Group共享存储后，宿主将需要推送的消息存入共享存储的消息队列中
• 扩展侧后台脚本按业务可接受的时间间隔（通常2~5秒）轮询读取共享存储的消息队列，读取到新消息后处理，同时标记已消费或移除已处理消息
• 缺点是消息实时性受轮询间隔影响，优势是无额外兼容性风险，实现成本极低

补充说明：苹果目前仅在macOS平台开放了dispatchMessage(withName:toExtensionWithIdentifier:userInfo:completionHandler:)接口，iOS端暂未提供该能力的原生API，以上替代方案均可覆盖绝大多数业务场景。

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