近日一名开发者在博客分享了自己提交应用（基于 Electron 7 开发的 App）到 Mac App Store 的经历。
Electron 是一个跨平台桌面应用开发工具，支持使用 JavaScript, HTML 和 CSS 等 Web 技术开发桌面应用。知名开源项目诸如 GitHub 打造的 Atom 编辑器和微软打造的 Visual Studio Code 编辑器均使用 Electron 开发。
由于此应用不是采用原生开发的应用，所以这位开发者为了能成功将应用提交并通过 Mac App Store 的审核，他根据网络上的教程采用了 Electron-Packager 对应用进行打包。
不过开发者在按照教程操作后，却发现苹果的审核回复称无法打开所提交的文件。他判断是审核者无法打开来自 elektro 编辑器的文件（elektro 是开发者提交的应用），因为他没有添加用户读取和写入的权限。经过以下的调整后，他再次提交了应用。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<!-- Add entitlements here -->
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
</dict>
</plist>
然而经过调整后再次提交依旧没有通过审核。对此，开发者表示一脸茫然。接着，他又提交了一款基于 Electron 名为 trommel 的应用。结果又是意料之中被拒绝了，不过这次却意外地收到了不同于之前的原因：
可以看到，苹果之拒绝这款应用是因为它使用了私有框架（non-public framework）。作者不是唯一一名遇到此问题的人，于是他向苹果反馈自己目前正在使用 Electron 开发应用，但不能更改任何这些私有框架的用法。
苹果对此的回应是，当提交的应用使用或引用了私有 API 就会被拒绝。如果开发者无权访问二进制文件或不确定如何删除有问题的 API，请与服务提供商联系以获取技术支持。重点来了，被拒绝后，如果后面继续提交此应用时出现使用或隐藏私有 API 的情况，可能会导致 Apple Developer 帐户被禁用，并从 App Store 中删除所有关联的应用程序。
而这位开发者目前面临的情况是：由于调用这些 API 属于 Electron 框架的行为，并非应用执行的，而且 Electron 框架使用这些 API 已经有好几年了。但由于近期苹果更新了服务端的应用审核流程，能检测和识别出这些违反其应用审核规定的私有 API，最后导致开发者的应用无法通过审核。
苹果的这次举动不禁让人回想起当年对一些使用热更新框架的应用的“警告”。
当时苹果向所有开发者推送警告邮件，宣布未来将禁用 APP 内部的“动态分发”功能，并要求开发者在自家 APP 中删除 JSPatch 相关框架，否则 APP 将面临下架或禁止上架。
结合此次的事件来看，其实这一切都十分符合苹果的一贯作风 —— 让所有事情可控、保证安全。开发者能用什么不能用什么都尽量在自己的控制范围内。大多数开发者使用热更新框架修复 bug，或者弄一些临时的小功能配置，这些没有问题，但总会有少数开发者借此去调用私有 API 以实现某些不当企图，这正是苹果不可控的。
因此在此次事件中，我们也就不难理解苹果为何会严厉禁止调用私有 API 的应用。
猜你喜欢: