AI 导入案例
同一服务的 iOS 应用，是占会员多数的主战场。尽管如此，通知却比 Android 更加悄无声息地沉默着——上一代的通知通道已经完全中断。继实录⑥（Android 篇）之后，这次我们整理iOS 特有的卡点，以及两个系统共通的「不动旧服务器就把通知现代化」的经过。
「察觉不到的故障」，恰恰最值得优先解决。
多数用户在 iOS 上。而在 iOS 上，通知是死的。
iOS 应用与 Android 一样，也是用原生外壳显示既有 Web 服务的WebView 封装＋通知的结构。通知发送依赖上一代机制，当那条通道无法使用时投递即告停止。由于多数用户都在这一侧，影响范围最大。把这里迁移到现代的推送基础设施，是这次最大的回报。
iOS 的卡点，全是「只有真机才会暴露」的问题。
iOS 上的问题，主要是虚拟设备和代码审查都看不出来、只有在真机上才会浮现的那一类。
外壳用 Swift 重做，咨询内容与会员原样保留。
iOS 应用由 AI 代理重做为最新的原生结构（Swift＋WKWebView＋现行通知基础设施）。从项目骨架生成一直跑到真机确认，在 Mac 上以真机构建确认了运行。所显示的咨询内容（既有 Web 服务），以及约 14,000 台注册设备这一会员资产，都原样继承下来。
| 项目 | 此前 | 重做之后 |
|---|---|---|
| 通知通道 | 上一代的通知方式 （已终止服务・无法发送） | 现行推送基础设施＋新方式的认证密钥 |
| 应用外壳 | 世代较旧的原生实现 | 以 Swift＋WKWebView 重新生成 |
| 画面（咨询内容） | 显示既有 Web 服务 | 原样延续（保留会员资产） |
| 真机上的故障 | 日文乱码等 | 字体・角标・世代差异逐项处理 |
旧服务器没有更换，而是被现代化了。
两个系统共通的关键，在于发送侧的服务器。这台服务器运行在非常陈旧的运行环境上，现行的官方工具无法直接使用。于是我们把认证所需的签名处理自行实现，再连接到现行的推送基础设施。没有整台更换服务器，只把通知迁移到了现代方式。
此外，发送侧也从共享基础设施中剥离，重做为独立的推送服务，可以从管理界面选定对象后发送。
即使是被说成「不能用了」的移动应用，只要重做外壳、继承密钥与会员资产、把旧服务器现代化，重做只需一次，就能回到现行的运营。如果您也有已经放弃、觉得碰不得的应用，欢迎先从现物解析开始咨询。
※ 本文基于真实项目，在无法识别企业与服务的范围内做了一般化描述。数值为截至 2026 年 8 月实测所得的概数。所需周期与工作咨询内容因应用结构而异。