Android 要禁止侧载,那 iOS 能侧载吗?技术路径是怎么样?

最近《Android 准备禁止侧载》的讨论里，大家对于 iOS 支不支持侧载的讨论还是蛮热烈的，而实际上，对于非欧盟地区 iOS 也是有“合规”的侧载渠道，也就是不需要越狱也可以侧载。

❝

就像 Android 虽然要禁止侧载，但是也计划提供支持开发者选项等待 24 小时的路径，另外通过 adb 的路径也还能用一样，iOS 在开发者模式下，也有一条侧载途径，并且可以做到免费+全自动。

因为 Apple 对于每个 Apple ID 都可以免费注册为“个人开发者” ，“个人开发者”可以给自己的设备安装自己签名的 App ，当然，免费的有有 3 个 App 上限和 7 天有效期限制，这原本是给开发者测试用的，而现在这个路径也经常被用来实现侧载场景。

一开始有一个叫 AltStore 的实现，它可以通过电脑的常驻服务（AltServer）充当了一个“本地服务器”，负责处理应用的签名过程，从而让 ipa 可以通过你的 Apple ID 安装到手机，当然，每 7 天就需要刷新一次，其实也挺麻烦的。

所以后来基于这个技术路线，又出现了一个 SideStore， SideStore 做的事情本质是：帮你自动完成“签名 + 安装 + 7天刷新”这一整套流程。

简单说就是，当你用数据线连接 Mac 并点击“信任此电脑”之后，Xcode 安装测试 App 时 iOS 内部会开启开发者调试相关服务，而 SideStore 就是通过“配对文件（pairing file）”模拟那台信任过的电脑。

当然，它也是需要一些技术门槛，具体就不展开了，简单说就是 SideStore 通过工具拦截 iOS 的请求，把验证开发者的请求重定向到手机本地进行处理验证，这个验证需要一个 pairing file（设备配对记录），而这个文件实际上是在你第一次用电脑（或工具）信任这台 iPhone 时，从设备导出的开通“开发通道”的凭证，这个 pairing file 用途是：

• 证明设备已经信任侧载工具
• 允许 iOS 内部开发服务（MobileInstallation 或等效通道）被 SideStore 调用

❝

当然，这个配对文件可能会随机失效，或者在设备更新/重置后失效，需要重新生成/导入。

不过，苹果也在收缩这个场景，例如 iOS 26.4 现在需要验证传入的 socket 是否位于本地子网（local subnet）上，如果检测到 utun 位于子网之外，连接就会被拒绝，这是一个“网掩码检查”（netmask check），只是这个问题后续也有人在支持解决。

所以实际上 iOS 也是可以做到“合规”侧载，只是这个侧载门槛还是比较高的，比起 Android 就算禁止侧载后的 24 小时冷静期或者 adb 安装的门槛还高，所以大部分时候你认为非欧盟不可以侧载，其实也没错。

实际上这也是一场攻防过程，iOS 开发者安装应用属于必须提供的路径，而现在 SideStore 把这个途径给自动化，所以严格来说也算是在合理情况下的利用漏洞，至少它不需要越狱不是么？

另外 iOS 26.4 中调整了账户切换流程，把退出登录放在设置里面的账号设置，需要点击媒体与购买项目才能退出账号，这对于需要经常切换账户的用户来说确实麻烦：

而对于这个情况，也有人提前做了一些应对方式，例如  Lakr233/AssppWeb 就做了一个基于 Web 的 iOS 应用获取和安装工具，它的核心亮点在于零信任架构（Zero-Trust Architecture），也就是服务端不需要（也无法）获取你的 Apple ID 账号密码。

AssppWeb 就是一个运行在你浏览器里的“iTunes 客户端”，它利用后端服务器作为跳板来绕过网络限制，但所有的逻辑判断和加密都在你本地完成，目的是实现网页版本的多个苹果下载账号管理：

核心类似于：它把“和 Apple 私有接口打交道（登录/购入/拿下载信息）”这件事放到浏览器里，服务器只负责“下载公开 CDN 上的 IPA + 注入 SINF/Metadata + 生成安装链接”，这个其实理念也和 SideStore 类似，不得不说，开发者们为了“方便”也是无所不用其极。

当然，都用 iOS 了，一般人也不会去折腾这些，会折腾这些的，一般也都是技术情怀，只是，确实存在这样的技术路径。