“这不是传统意义上的错误。我最近经历了一次‘磨难’，在我将 Python 从 3.11 更新到 3.12 后，苹果拒绝了我 App Store（具体来说是 Mac App Store）上的应用程序更新。” Eric Froemling 在 GitHub 的 issue 中说道。
当然，苹果方面并没有直接向 Froemling 阐述拒绝 Python 应用的理由。在向苹果提起申诉并要求停止审查时，苹果最终告知他，parse.py 和 parse.pyc 属于有问题的文件。
在 Froemling 多方检查后才发现，是因为 Python 3.12 中添加了一个“itms-services”字符串，并且苹果似乎正在扫描此字符串并自动拒绝包含它的任何内容。在从 Python 捆绑副本中删除该字符串后，他才终于通过了审核。
实际上，受 Python 3.11 至 3.12 版本升级的影响，苹果应用商店已经将部分 Python 应用下架。
“现在回想起来我感到很沮丧，没能想到早一点对 Python 本身的 itms-services 进行全文检查，也没能偶然发现其他人遇到过这个问题。”虽然 Froemling 随后表示，但他的遭遇还是引起了社区的强烈反应。
CPython 核心开发者 Russell Keith-Magee 于 6 月 17 日在 Python Core Deveopment 论坛上发起了一项讨论：我们到底愿意为适应 App Store 的审核流程付出多少？
具体来讲，这次的问题是苹果的 macOS App Store 会自动拒绝任何包含 itms-services 字符串的应用程序。该字符串是用于从 iTunes App Store 申请应用程序安装的自定义 URL 前缀；但 macOS App Sotre 要求上架的应用程序全部沙盒化，即禁止使用这些 URL。苹果的自动审核流程会捕捉 urllib 解析器中处理这些 URL 的代码，因此即使相关应用程序从未使用 itms-services://URL 也无法幸免。其存在于标准库中，所以应用程序将被粗暴拒收。
对该字符串进行一些轻微混淆似乎可以避免这个问题。然而，这并不能保证冲突得到永久解决，而且可能会引发混淆军备竞赛；另外，后续我们可能还会遇到更多类似的应用程序验证问题。
虽然目前的问题来自 macOS 应用程序，但 iOS、Android 和微软等应用平台也存在类似的 App Store 自动审核流程。苹果的审核绝对是其中最……偏执且阴晴不定的一种——但这并不代表其他平台做得更好，目前各平台的验证和接收流程均完全不透明。
Russell Keith-Magee 提出了 CPython 解决这类问题的几种思路：
第一种思路是将“被应用商店所接纳”设定为 CPython 的设计目标，并纳入可满足该要求的相关补丁。
也就是说，用户不需要进行任何额外修复即可保证 CPython“与应用商店相兼容”，但这必然会将某些比较丑陋的混淆代码合并进软件产品。而如果后续规则再次发生变化，可能还需要添加更多补丁；另外哪些旧规则被移除，核心开发团队也不敢断言原本的特定混淆可以同步去掉。
如果选择这种方式，则意味着各 Python 发行版将不再是“官方”Python，因为其经过了修改以适应分发要求。
“我不知道到底应不应该将此视为安全或者品牌形象意义上的风险。但参考之前已经为不同 Linux 发行版专门推出了 Python 补丁，所以这可能也不是什么大问题。”Russell Keith-Magee 说道。
另外一种思路是将这个问题划交给分发环节处理。
CPython 的项目现状就是，生成捆绑应用程序的工具（包括 Briefcase、Py2app、Biuildozer 等）负责修复 CPython，确保其能够被应用商店所接受。以 Briefcase 和 Buildozer 为例，这些工具还会修复并构建自定义 CPython 库。
从历史角度讲，这是因为 CPython 本身就无法对 iOS 和 Android 提供开箱即用支持；3.13 源代码现在无需修复即可工作……但如果将其视为一个分发问题，则修复在本质上将成为一项持续性要求。
这个思路还有另一个问题，即 CPython 是否应该将已知的一切应用商店限制纳入开发考量。
开发人员很快达成共识，并提出了一项有望在 Python 3.13 中尽快实现的解决方案。
Russell Keith-Magee 抛出问题后，社区众多开发者纷纷参与讨论并提出了自己的建议。
另一位 CPython 核心开发者 Alex Gaynor 建议，该项目可以尝试一种 Keith-Magee 没有提到的方法，这主要是受到 Gaynor 在处理加密库方面的经验启发。
该加密库经常收到投诉，称其拒绝解析技术上并未生效、但却被广泛使用的证书。他表示目前的做法是接纳解决这类问题的 PR 请求，不过“前提是其必须体量小巧、本地化，而且质量要有一定保证”。
他随后又补充称，这些补丁只在有人向第三方（也就是本次纠纷中的苹果）申诉，并得到承诺会采取措施的情况下才会被接受。他建议为解决方案设定时间限制，以便在为用户提供良好体验的“同时，也不致让大企业习惯于将种种奇怪的问题外化到自由开源项目身上。”
同为 CPython 核心开发者的 Brandt Bucher 则首先好奇所谓混淆方案能不能行得通，或者说是否会被苹果视为规避审核过程。这个问题似乎没人能够回答，Keith-Magee 用“暂时无解”加表情符号予以回复。
在 Bucher 看来，Gaynor 的方法似乎很有吸引力，但也有点文不对题。毕竟苹果几乎没有申诉程序，而 Python 项目也没有可用的渠道来“提出在原则上有助于修改政策的意见”。
曾参与编写 Python 最佳实践文档的 Alyssa Coghlan 则提出了另一建议，就是使用 JSON 配置文件——urllib 会读取该文件来设置模块级属性，“而非对所有与 schema 相关的知识进行硬编码。”也就是说，这样能让应用程序生成器直接从配置文件中删除“itms-services”，而不必直接修改 urllib.py。
Keith-Magee 也认可这种方案的可行性，但提醒称“我还是觉得可以用混淆或者分发阶段的修复来处理，没必要搞得太矫枉过正。”
6 月 20 日，Keith-Magee 在论坛上写道，他想到了另外一种方法：添加一个名为“-with-app-store-patch 的构建时选项，借此删除已知存在问题的代码。他表示在默认情况下，iOS 平台会启用该选项，而其他平台则会禁用该选项。如果开发人员打算通过 macOS App Store 分发应用程序，则可以在为 macOS 构建应用时使用这种方法。
他还建议，此选项可以接受带有补丁的文件路径，这样当 Python 新版本发布、问题消失且应用商店在维护窗口后做出相应调整时，分发者也能继续提供补丁更新。”
Coghlan 则询问大家要不要尽快“把这类隐患管起来”。她认为，目前议案中的选项名称既过于宽泛、又过于狭窄。名称中的“app-store”部分太宽泛，会涵盖一切应用商店，而不只是是苹果应用商店；“补丁”部分又太狭窄，因为补丁既可以指代遵守苹果政策，又可以代表想个办法逃避审核。也就是说，应用商店的合规性检查问题仍然没得到解决。
Keith-Magee 支持从选项名称中删除“补丁”的建议，转而将其更名为“-with-app-store-compliance”形式，以便与平台标识交互以确定内容范围。
最终在 6 月 25 日，Keith-Magee 给出了用于实现 -with-app-store-compliance 配置选项的 PR 请求。在请求中，他表示可以将该选项用于 iOS 或 macOS 以外的平台，但目前尚无实际用例。如果一切顺利，此请求有望在 Python 3.13 中生效。
纵观整个事件，像 Python 这样的免费软件项目不得不浪费时间以寻求绕过不透明审核流程的状况着实令人沮丧，否则开发人员就无法为非免费平台继续编写软件。而 Keith-Magee 和其他 CPython 开发者采取的方法，似乎已经是当下最不坏的选择，在保证应用上架的同时也尽可能维护了 Python 应用程序开发者的良好体验。
但可以肯定的是，这绝对不会是该项目最后一次遇到这种“天降横祸”。
参考链接：
https://discuss.python.org/t/handling-incompatibilities-with-app-store-review-processes/56011/3
https://lwn.net/SubscriberLink/979671/4fb7c1827536d1ae/
