近日一名開發者在博客分享了自己提交應用（基於 Electron 7 開發的App）到Mac App Store的經歷。

Electron是一個跨平臺桌面應用開發工具，支持使用JavaScript, HTML和CSS等Web技術開發桌面應用。知名開源項目諸如GitHub打造的Atom編輯器和微軟打造的Visual Studio Code編輯器均使用Electron開發。

由於此應用不是採用原生開發的應用，所以這位開發者爲了能成功將應用提交併通過Mac App Store的審覈，他根據網絡上的教程採用了 Electron-Packager對應用進行打包。

不過開發者在按照教程操作後，卻發現蘋果的審覈回覆稱無法打開所提交的文件。他判斷是審覈者無法打開來自elektro編輯器的文件（elektro 是開發者提交的應用），因爲他沒有添加用戶讀取和寫入的權限。經過以下的調整後，他再次提交了應用。

com.apple.security.app-sandbox com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.allow-dyld-environment-variables com.apple.security.files.user-selected.read-write

然而經過調整後再次提交依舊沒有通過審覈。對此，開發者表示一臉茫然。接着，他又提交了一款基於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的應用。