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

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

一、送審前先準備什麼？

還在評估預算？先用iOS App 開發成本清單與預算表分開計算免費測試、會員年費、AI 工具與後端支出，再決定何時付費上架。

公開發佈需要 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 沒出現在清單，或狀態顯示有問題

這一步還不是 App Review。Apple 會先處理上傳的檔案，完成前它不會出現在可選擇的 build 清單。先到 App Store Connect 看這個 build 目前的狀態，再決定下一步；不要在還沒看懂原因前連續上傳。

要請 AI 協助時，貼上狀態名稱與錯誤原文，以及對應的 Version／Build，要求它說明該改的是 Info.plist、隱私資訊清單、專案設定還是程式，並附上依據。限定只處理這個錯誤，不要讓它順便升級套件或重寫專案。狀態定義以 Apple 的上傳狀態說明與build 狀態說明為準。

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

第一次找朋友試用，可以接著看 TestFlight 外部測試教學與 15 分鐘試用腳本，把邀請、回報與修復後複測串起來。

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

商店資料不是裝飾。它同時影響使用者是否看懂 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 官方準備說明。

App purpose
Reading Log helps users save books and track reading progress.

Review access
Use the demo account in the Sign-in Information fields.
The account contains a sample book named "Demo Book".

Steps to review
1. Sign in, then open the Library tab.
2. Tap "Demo Book". Its current progress is 10 pages.
3. Tap "Update progress", enter 15, and tap Save.
4. Return to Library, then reopen the book.
   Expected result: the saved progress is 15 pages.
5. In Settings > Account > Delete account, the user can
   initiate account deletion. Please perform this step last.

Special requirements
No additional hardware is needed. The backend is available
for review. This build has no paid features or in-app purchases.

七、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；恢復購買可實際運作。
• 名稱、圖示、截圖、描述與功能都屬於你或已有授權，沒有誤導或仿冒。

已經被退件：先決定改資料、改程式，還是補重現路徑

打開 App Review 的訊息，先記下 guideline 編號、Apple 測到的現象與你提交的 Version／Build。下面是處理方式示例，不是 Apple 對你個案的判定。

回覆用「問題 → 修改 → 驗證 → 請重新檢查的路徑」四段即可。下載資料包內有可填的英文框架；尚未完成的修正不要寫成已完成。 Apple 的回覆審核訊息說明支援附截圖與文件；未解決項目的處理步驟則說明如何編輯後重新送審。 儲存回覆不等於重新送出版本，最後要確認提交狀態。

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

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

送審前自查表：留下狀態與待辦

把「看過說明」與「真的測過」分開。逐項記錄目前狀態，下載後可補上版本、裝置與證據檔名，再把未完成事項交給 AI 協助修正。

自查項目整理自本文流程與 Apple 的 Before You Submit（2026-09-21 查核）。本表不涵蓋所有類型 App 的特殊規範；涉及付款、帳號刪除或其他特定功能時，仍須另核對適用條款。

本次只處理：[一個問題]
Version / Build：[填寫]；裝置 / iOS：[填寫]
重現步驟：[從哪個畫面開始、每一步操作]
預期結果：[填寫]；實際結果：[填寫]
證據：[去除帳密與個資後的畫面、錯誤或檔名]

先說明如何重現、哪些原因已確認，哪些仍是推測。
提出最小修正，列出影響範圍；不要清空資料或重建整個專案。
完成後列出實際跑過的測試、Version / Build、結果與未測項目。
若無法操作實機，明寫未測並交付我能照做的步驟。
只有符合預期且留下證據的項目，才回填自查狀態。

常見問題