整理 | 褚杏娟、核子可樂
“這不是傳統意義上的錯誤。我最近經歷了一次‘磨難’，在我將 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 應用程式，但 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/
AICon 全球人工智慧開發與應用大會將於 8 月 18 日至 19 日在上海舉辦，匯聚頂尖企業專家，深入端側AI、大模型訓練、安全實踐、RAG應用、多模態創新等前沿話題。現在大會已開始正式報名，6 月 30 日前可以享受 8 折優惠，單張門票節省 960 元（原價 4800 元），詳情可聯絡票務經理 13269078023 諮詢。
關鍵詞
方法
社群
開發人員
應用程式
問題