iOS App 上架教學從 Xcode 到 App Store 審核的完整流程

如果你還在決定第一款 App 要做什麼、該選原生專案還是手機生成器，先讀Vibe Coding 做 iOS App 的完整路線圖。這一篇只處理一個明確階段：App 已經能運作，接下來如何送進 App Store。

一、送審前先準備什麼？

公開發佈需要 Apple Developer Program 會員資格。Apple 在 2026 年 8 月的官方頁面列出的費用是每個會員年度 99 美元，部分地區會以當地貨幣計價；個人與組織帳號顯示在商店上的賣家名稱也不同。申請前先確認你要用個人姓名還是組織法定名稱上架。

費用與身分要求會調整，付款前請核對Apple Developer Program 加入說明。免費 Apple 開發者帳號可以在自己的裝置測試，但要透過 App Store 發佈，仍需要付費會員資格。

二、先在 App Store Connect 建立 App 紀錄

Apple 要求先建立 App Store Connect 紀錄，再上傳 build。進入 Apps，選擇新增 App，填入平台、App 名稱、主要語言、Bundle ID、SKU 與團隊存取範圍。SKU 只供內部辨識，不會顯示給使用者。

最重要的是 Bundle ID。它必須和 Xcode 專案完全相同，而且第一個 build 上傳後就不能更改。Apple 也說明，一個 build 是由 Bundle ID、版本號與 build string 的組合辨識。正式操作可對照新增 App 官方步驟與App 資訊欄位定義。

三、把 Xcode 專案整理成可上傳的 build

回到 Xcode 的 target 設定，逐一確認 Bundle Identifier、Team、Signing、Version 與 Build。Version 是使用者看到的版本，例如 1.0；Build 是同一版本內每次上傳的識別值。若同一個版本重新打包上傳，記得增加 Build，否則 App Store Connect 無法把它當成新的 build。

1. 1. 先做 Release build 驗收：不要只測 Debug。確認正式環境的 API、登入、推播、訂閱與遠端設定都指向正確服務。
2. 2. 用實機跑完核心流程：至少測首次啟動、權限允許與拒絕、登入／登出、資料新增／刪除、網路中斷與重新開啟 App。
3. 3. Archive 前清掉阻斷錯誤：選擇正式 target 與可發佈目的地，再執行 Product → Archive。不要看到一般 warning 就全部忽略，也不要為了消除 warning 讓 AI 大幅重寫已可運作的程式。

四、上傳 build，再用 TestFlight 做最後驗收

build 可由 Xcode、Transporter 等 Apple 支援的方式上傳。第一次上傳後，Apple 會先處理檔案；處理完成前，它不會出現在可選擇的 build 清單。這時先等 App Store Connect 的狀態或通知，不要因為幾分鐘沒看到就重複上傳多個 build。

Apple 的上傳 build 文件會列出目前支援的上傳方式與 Xcode 版本要求；這些條件會變動，因此本文不把某個 Xcode 小版本寫成永久規則。

build 處理完成後，先透過 TestFlight 安裝到至少一支不是日常開發用設定的 iPhone。重跑一遍新使用者流程，尤其檢查需要 Apple 審核人員操作的功能：登入、相機／相簿／定位權限、訂閱購買、恢復購買、帳號刪除與需要特殊資料才能看到的頁面。

五、填寫商店素材、支援資訊與隱私揭露

商店資料不是裝飾。它同時影響使用者是否看懂 App、審核人員能否驗證功能，以及 App 在商店中的呈現。Apple 目前規定 App 名稱與副標題各不超過 30 個字元；描述最多 4,000 字元，關鍵字欄最多 100 bytes。不要為了塞字重複 App 名稱或其他公司的名稱。

• 截圖要呈現真實 App 體驗。App Store Connect 接受 1 到 10 張截圖；同一介面可提供最高解析度版本讓系統縮放，尺寸請直接看 Apple 最新規格。
• Support URL 是必填，頁面要有實際聯絡資訊，讓使用者能回報問題或提供建議。
• iOS App 必須提供 Privacy Policy URL；隱私政策要與 App 實際行為一致，不是複製一份通用文字。
• App Privacy 要包含你和第三方 SDK 收集的資料。分析、廣告、登入、雲端與 AI 服務都要逐一盤點。
• 若 App 讓使用者建立帳號，App 內也要提供發起刪除帳號的方式，不能只提供暫停或停用。

逐欄填寫時，可同時開啟 Apple 的平台版本資訊欄位說明、截圖規格與App Privacy Details。帳號刪除則以Apple 的帳號刪除要求為準。

六、讓審核人員能完整操作你的 App

App Review Information 不會出現在商店，但它往往決定審核是否順利。填入能即時聯絡到的姓名、Email 與電話；如果功能需要登入，提供不會過期、資料完整的 demo 帳號。特殊操作、測試步驟、硬體需求或某個功能藏在哪裡，都寫進 Notes。

Apple 明確指出，登入資訊或特殊設定不完整可能延遲審核，甚至無法通過。不要假設審核人員會自己註冊、付費或猜操作路徑。需要特殊硬體或難以重現的環境時，依 Apple 指引準備示範影片或補充資料。詳見App Review 官方準備說明。

七、Add for Review 之後，還要正式 Submit for Review

在版本頁選好正確 build、完成必填資料後，先按 Add for Review，把版本加入送審草稿。這時狀態是 Ready for Review，還沒有真正送出。接著進入 Draft Submissions 檢查項目，再按 Submit for Review，Apple 才會收到審核申請。

這個兩段式流程是目前最容易被舊教學漏掉的介面差異。正式送出前，請直接比對 Apple 的Submit an app 官方步驟。

發布方式可選手動、自動或不早於某個日期。第一版若希望保留最後檢查時間，手動發布通常比較容易控制；通過後再自行按下發布。Apple 的公開流程也提醒，核准後實際出現在 App Store 最多仍可能需要 24 小時。

八、送出前做一次「退件原因反推」

被退件不代表產品失敗，但很多退件其實可以在送出前避免。先不要背網路上的「十大退件理由」，而是從自己的功能逐項對照最新版App Review Guidelines。下列清單是第一次送審最值得先驗證的產品行為。

• App 沒有會阻斷使用的 crash、空白頁、假按鈕、測試文案或未完成入口。
• 權限說明能清楚解釋用途；拒絕權限後，App 不會卡死或無限要求。
• 隱私政策、App Privacy 答案與第三方 SDK 的真實資料流一致。
• 需要登入的功能有有效 demo 帳號；審核人員能看到完整核心流程。
• 有帳號建立功能時，App 內找得到刪除帳號入口，並說清楚訂閱如何處理。
• 使用第三方社群登入時，重新核對 Guideline 4.8 的等價登入服務要求。
• 販售數位內容、訂閱或功能時，付款方式符合 Guideline 3.1；恢復購買可實際運作。
• 名稱、圖示、截圖、描述與功能都屬於你或已有授權，沒有誤導或仿冒。

九、AI 可以加速送審，但不能替你承擔產品責任

AI 很適合把已知資料整理成檢查清單、協助解讀 Xcode 錯誤、草擬商店描述，或把 App 的資料流整理成隱私盤點初稿。但 AI 不知道你的正式環境到底送了哪些資料，也不能替你確認 Apple 帳號、合約、Bundle ID 與 build 是否正確。

送審前 15 分鐘檢查表

• App Store Connect 與 Xcode 的 Bundle ID 完全一致。
• 選到的是正確 Version／Build，build 已完成處理。
• TestFlight 版本已在實機跑完首次使用與核心流程。
• 名稱、描述、關鍵字、截圖、支援 URL 與隱私 URL 都已完成。
• App Privacy 包含第三方 SDK，內容與實際資料流一致。
• 需要登入時，demo 帳號可用且不會過期。
• Review Notes 說清楚特殊設定、測試路徑與聯絡方式。
• 確認發布方式，再依序完成 Add for Review 與 Submit for Review。

常見問題