上架套件：從你的程式碼寫成的商店頁面

先看數字：一份平均水準的上架資訊需要

• 每個商店四到五種不同像素尺寸的截圖
• 一個圖示要輸出八種以上的尺寸
• 涉及聯絡人或位置資訊時，權限清單可能超過十幾項
• 一份含有數十個是非題分支的隱私問卷，決定了審核人員是否會在第一天就拒絕你的應用程式

再乘以三個商店——Play 商店、App Store，如果你要發布擴充功能，還有 Firefox 的附加元件上架頁——你面對的，就是為一個早已開發完成的應用程式，花三個下午裁切截圖、填寫表單。這還只是枯燥的數字部分。

每個提交至商店的建置版本都會取得一份自動產生的上架套件，專門用來彌補那道落差——開發者原本希望應用程式做的事，與編譯後的執行檔實際做的事之間的落差。

套件中其餘的部分則簡單多了

• 截圖取自正在執行中的應用程式本身，而非模擬圖——經過構圖、依各商店規格調整尺寸，並在格式需要時附上面板說明文字。
• 圖示會輸出成各商店要求的完整尺寸家族，加上該商店額外要求的任何宣傳圖或特色圖。
• 上架文案——標題、簡短描述、完整描述——根據應用程式的實際功能撰寫，這聽起來理所當然，但只要你讀過夠多堆砌形容詞的 App Store 上架文案，就知道並非如此。
• 權限說明會依每項權限逐一產生，並符合各商店所要求的格式。

這些事嚴格來說都不難。只是麻煩到讓人跳過，或是草草了事做錯。

最嚴格的部分：隱私問卷

即使出於善意，這部分也很容易出錯。你開發了一個應用程式，自認為沒有收集任何資料，於是在問卷上勾選「不收集資料」就繼續下一步。結果三週前你其實加入了一個當機回報 SDK 卻忘了，或是某次相依套件更新悄悄帶入了分析呼叫。現在你的上架資訊說一套，你的執行檔做另一套——這要嘛是對使用者的無心謊言，要嘛是在審核時被迅速標記的捷徑，兩者都不是好結果。

所以這份套件不會只憑你的說法。它會先掃描應用程式的實際原始碼再作答：只有在程式碼確實沒有任何網路連線、也未內建分析工具的情況下，才會做出「不收集資料」的聲明。如果應用程式確實會回傳資料，聲明就會如實反映——不論這是否好聽。我們寧可上架資訊誠實，也不願它對自己過於寬待。而且這也剛好是能通過審核的版本，因為審核人員檢查的正是掃描所檢查的內容。

填好，不只是歸檔

凡是商店提供 API 的地方，套件會直接推送上架資訊，全程無需人工介入。凡是商店堅持要用自家後台的地方，套件會自動完成表單填寫，只留下商店規定必須由真人點擊的少數步驟。

各商店完整的細項比較請見從提示詞到應用程式商店。