開發一個 App 要多久？真實時程

開發一個 App 要多久：簡短的答案

開發一個 App 要多久？沒有人能誠實地給你一個通用的數字，因為時間主要取決於兩件只有你自己知道的事：第一版的大小，以及你每週能投入多少小時。不過，時程中有一部分是事先就知道的：Apple 的各個步驟是以天計算，而不是以月計算。例如 Apple 表示，90% 的提交會在 48 小時內完成審查。

所以真正的關鍵在於界定範圍。一個只做一件事、只上 iOS、用的技術堆疊不是當天才第一次接觸的 App，只要規律投入，幾週就能做出來。一份包含十二個功能、橫跨兩個平台的清單，可能拖上好幾個月，最後根本上不了架。這篇指南會一步一步拆解時間都花在哪裡，讓你能估算自己的時程。

我自己也在發布 iOS App：Solys（一個內建小遊戲的鬧鐘）和 TradaZen（一個交易模擬器）都已經上架 App Store。Nolera 和 Clic 曾被 Apple 退件，之後修正了。下面這些步驟，是我每次上架都會走過的流程。

行動 App 的開發時間：取決於什麼？

在談步驟之前，先列出讓行動 App 開發時間產生差異的因素，從影響最大到最小。

• 第一版的功能數量。 這是目前為止最主要的因素。每多一個功能，就多了畫面、空狀態、要處理的錯誤和測試。
• 帳號與後端。 資料只留在手機上的 App，比需要註冊和跨裝置同步的 App 簡單得多。
• 付款。 訂閱需要在 Apple、RevenueCat 和你的程式碼裡做設定，還要測試購買。
• 一個或兩個平台。 同時發布 iOS 和 Android，就是兩份資料、兩次審查、兩輪測試。我在同時開發 iOS 與 Android App 裡詳細談過這個選擇。
• 你可用的時間。 每週十小時和每週四十小時，時程當然不一樣。
• 你的起始程度與 AI 的使用。 AI 大幅加快寫程式的速度，對其他部分的幫助就小得多。後面會再談。

一步一步：開發 iOS App 時，時間都花在哪裡

1. 界定點子

這一步決定了其他所有步驟。你要確定目標使用者、要解決的問題、主要功能、商業模式，以及哪些東西不放進第一版。如果這一步拖了好幾週，代表該做的決定還沒做。一份一頁的需求規格書就足以把它收尾。

2. 開通 Apple Developer 帳號

沒有這個每年 99 美元的帳號，你就無法發布，而 Apple 的企業開發者計畫也無法取代它。以個人身分註冊時，Apple 表示如果你在購買後 24 小時內沒收到加入確認，就要聯絡客服。以公司身分註冊時，必須先取得 D-U-N-S 編號：Apple 預估最多需要 5 個工作天才能拿到，之後最多再 2 個工作天資訊才會傳到 Apple。這件事要和開發同時進行，不要留到最後。詳細內容請看 Apple 開發者帳號：價格與註冊。

3. 做出主要功能

這是差距最大的地方，而且幾乎都來自範圍。一個定義清楚、包含空狀態和錯誤處理的功能，做起來很快，尤其是用 React Native、Expo 和 AI。每個「順便加一下」的功能，都會拉長這一步以及之後的每一步。iOS App MVP 這一頁能幫你在對的地方砍掉功能。

4. 用 TestFlight 在你的 iPhone 上測試

只用模擬器不夠：有些當機只會出現在實體手機上。只要你的 build 處理完成，就能開始內部測試。如果要給外部測試者，Apple 說明送給某個群組的第一個 build 要經過 App Review，之後的 build 不一定需要完整審查。所以第一次要預留一點時間。完整說明請看 TestFlight：測試你的 iPhone App。

5. 串接訂閱

在 App Store Connect 建立商品、在 RevenueCat 裡連結起來、做出付費牆、測試購買和回復購買。有一個時程上要知道的重點：Apple 要求每種類型的第一個 App 內購買項目必須和新版本的 App 一起送出。如果你忘了，第一次提交就會在沒有訂閱的情況下送出，你得重新跑一輪。完整的工作內容在 iOS App 內訂閱這一頁。

6. 準備 App Store 頁面

尺寸正確的螢幕截圖、描述、關鍵字、隱私權聲明、使用條款連結、給審查人員的備註。如果一切都事先準備好，只要幾個小時。如果送出當天才第一次看到這些欄位，可能要花好幾天。

7. Apple 審查

依照上面引用的 Apple 數據，審查本身通常很快。真正花時間的是被退件：每次退件都代表要讀原因、修正、重新送出，再等新的回覆。我在 App Store 審核時間裡詳細整理了實際的時間，以及哪些因素會拉長它。

App 的時程在一開始靠砍功能贏回來，在最後因為才發現 Apple 的規則而輸掉。

用 AI 開發一個 App 要多久？

AI 確實改變了第 3 步所需的時間。Claude、ChatGPT 或 Cursor 幾秒鐘就能寫出畫面、導覽和簡單的邏輯，而幾年前這些需要好幾個小時的查找。

但它對第 2、4、5、6、7 步的改變就小得多。沒有主控台的存取權限，也沒有在相關裝置上實際執行測試，agent 無法確認 Apple 帳號、訂閱或畫面呈現的狀態。這些檢查需要一套測試機制，即使 agent 能參與自動化。結果是：有了 AI，建構時間縮短了，但時程中花在設定、測試和審查上的比例相對變大。我在用 AI 開發 iOS App 裡有詳細說明。

讓時程爆掉的三件事

1. 開發途中改變主意。 每一次「順便加一下」都會重新打開範圍。對策：凡是不在第一版的東西，都白紙黑字寫成範圍外，變成下一版的素材。
2. 到最後才發現 Apple 的規則。 缺少示範帳號、小尺寸 iPhone 上畫面被切掉、評分請求放錯位置、訂閱缺少必要說明：每一個太晚才發現的問題，都要多花一整輪審查。App 被 Apple 退件這一頁列出了最常見的原因。
3. 一個人卡在設定問題上。 一張憑證、一個訂閱 ID、一個裝不起來的 build：這些卡關通常只需要一個正確的資訊，但在沒人能幫你的時候，可能讓專案停擺好幾天。

為什麼「更快」不一定更好

如果砍掉小螢幕測試、網路錯誤處理和購買驗證，App 可以很快上架。它會上架，然後在第一次碰到真實使用者時壞掉，而 App Store 上的第一批評分會記得這件事。

正確的目標不是單純的速度，而是在不犧牲 Apple 審查、也不犧牲第一印象的前提下，最早的上架日期。砍功能，永遠不要砍穩定性。

一個真實參考：TradaZen 上架前的 26 天

TradaZen 的第一個 commit 在 2026 年 6 月 21 日，第一個 TestFlight 在 6 月 25 日，上架則在 7 月 17 日：從第一個 commit 到 App Store，共 26 個日曆天。這不是 26 天全職工作，也不是所有 App 的平均值。上架之後，範圍也還在持續調整。

TradaZen 的詳細時間軸區分了建構階段、審查問題和方向轉換。這是一個拿來和你的專案比較的例子，不是一個可以照抄的上架日期。

怎麼估算你自己的時程？

與其相信網路上找到的數字，不如針對你的專案這樣算：

1. 寫好你的一頁需求規格書，列出第一版的所有畫面。
2. 用小時估算每個畫面，包含空狀態和錯誤處理，再加上付費牆和 App Store 頁面。
3. 除以你每週實際的時數，而不是你希望的時數。
4. 為至少一次和 Apple 的來回預留緩衝，尤其如果這是你的第一個 App。
5. 一開始就申請 Apple Developer，讓它永遠不會卡住最後階段。

如果結果看起來太久，不要逼自己做得更快：拿掉一個功能。

給自己設一個期限

固定的期限對守住精簡的範圍很有幫助。iOS Kit 把整條路切成四個階段：選出能賺錢的 App、做出 App 的核心並用 TestFlight 測試、串接金流，最後上架並讓人找到。每個階段的日期由你來定。首頁展示了用 Claude Code 開發行動 App 的這四個階段。

想估算自己的時程，免費診斷會從你的狀況和每週可用時間出發，告訴你該先處理哪個階段。

期限是一個工作框架，不是上架的保證：負責核准的是 Apple，而你的節奏也很重要。想看整個流程的全貌，開發 iPhone App 這一頁仍然是最好的起點。

常見問題

開發一個 iPhone App 需要多久？

主要取決於第一版的大小，以及你每週能投入多少小時。一個只做一件事、只上 iOS、用的工具不是當天才第一次接觸的 App，只要規律投入，幾週就能做出來。一份包含十二個功能、橫跨兩個平台的清單，可能拖上好幾個月，最後根本上不了架。

開發 iPhone App 有哪些步驟？

七個步驟：界定點子、開通 Apple Developer 帳號、做出主要功能、用 TestFlight 在你的 iPhone 上測試、串接訂閱、準備 App Store 頁面，最後通過 Apple 審查。界定範圍決定了其他所有步驟。Apple Developer 的申請要和開發同時進行，不要留到最後。

Apple 審核一個 App 要多久？

Apple 表示至少 50% 的提交會在 24 小時內完成審查，90% 會在 48 小時內完成。所以審查本身通常很快。真正花時間的是被退件：要讀原因、修正、重新送出，再等新的回覆。實際的時間詳見 App Store 審核時間。

AI 能讓開發 App 變快嗎？

可以，但主要是在建構階段。Claude、ChatGPT 或 Cursor 幾秒鐘就能寫出畫面、導覽和簡單的邏輯。AI 對 Apple 帳號、測試、訂閱、App Store 頁面和審查的改變就小得多。結果是：建構時間縮短了，但時程中花在設定、測試和審查上的比例相對變大。

什麼會讓 App 的時程失控？

主要有三件事：開發途中改變主意、到最後才發現 Apple 的規則，以及一個人卡在設定問題上。每一個太晚才發現的 Apple 規則，都要多花一整輪審查。要守住範圍，就把不在第一版的東西白紙黑字寫下來：它會變成下一版的素材。

有沒有發布 iOS App 時程的真實例子？

有：我的 App 之一 TradaZen，從 2026 年 6 月 21 日的第一個 commit 到 7 月 17 日上架，相隔 26 個日曆天。這不是 26 天全職工作，也不是所有 App 的平均值，而且上架之後範圍還在持續調整。把這個參考拿來和你的專案比較，但不要把它當成上架日期照抄。