本週先做兩件事：若 App 使用 iOS 27 SDK 或更高版本建置，立即補上 Apple 認可的啟動螢幕宣告，然後檢查 Release Archive 內的最終 .app 並重新上傳驗證；仍使用 iOS 26 SDK 的生產流程可以暫時保留，但應在 Xcode 27 測試分支完成遷移，不要等正式發版當天才處理。

這篇適合準備用 Xcode 27 測試或發布現有 iOS App、但仍依賴舊啟動畫面配置的獨立開發者。若團隊維護多個 Target、擴充功能或跨平台產生設定，也能用這套流程確認遠端打包機收到的二進位檔沒有偏差。

最後更新於 2026 年 8 月 27 日；版本與上傳邊界核實自 Apple TN3208 啟動螢幕技術說明、iOS/iPadOS 27 Release Notes、Xcode 系統要求 及 App Store Connect Release Notes。

01

iOS 27 啟動螢幕缺失：先判斷建置條件，再判斷版本去留

ITMS-90870 的關鍵不是 App 的最低部署版本，而是這次二進位檔使用的 SDK。Apple 已確認，使用 iOS 27 SDK 或更高版本建置的 iPhone、iPad App，必須包含指定的啟動螢幕鍵；缺失時，App Store Connect 可能回報啟動螢幕不符合要求。判斷依據可回看 Apple 的啟動螢幕要求。

請把三條流程分開管理：

  • 目前生產流程：若仍以 iOS 26 SDK 建置，可暫時維持既有提交流程，但要標記為短期回退路徑。
  • Xcode 27 Beta 5 測試流程：Apple 已確認這個版本的建置可上傳至 TestFlight。這是測試驗收入口，不是正式 App Store 生產接收日期的公告。
  • 未來生產切換：Apple 尚未在指定資料中確認 Xcode 27 正式版發布日期，也未確認 App Store 開始接收 iOS 27 SDK 生產建置的具體日期。因此不能把任何「秋季」推測當成排程死線。

這個區分很重要。把最低部署版本寫成 iOS 27，或把 Beta 可上傳 TestFlight 誤解為可直接送正式商店，都會讓修復範圍判斷錯誤。

02

第一項指標：宣告完整性，比畫面是否漂亮更先決

要通過伺服器校驗，最終 Info.plist 至少要有 Apple 認可的有效啟動螢幕配置。常見方向是 UILaunchScreen，或既有專案使用的 LaunchScreen.storyboard 相關設定；Apple 的 UILaunchScreen 配置說明列出鍵值與內容限制。

我們建議按專案狀態選擇：

  • 新建或以 SwiftUI 為主的 App：優先檢查 UILaunchScreen 是否由專案設定正確產生，並確認產物內真的存在。
  • 已有 UIKit 啟動畫面的 App：若 LaunchScreen.storyboard 已經是穩定資源，不必為了改名而重做；先確認它被正確指定並打包。
  • 多啟動情境或不同 Target：每個真正會提交的 App Target 都要有對應設定。不能只修主 App，卻漏掉另一個 Scheme 或白標版本。

空鍵、空字串、不存在的 storyboard 檔名，都不是修復。配置必須與實際資源及 Build Settings 一致。可對照 Apple 的啟動螢幕設定文件，不要只複製一段 plist 文字。

03

第二項指標：Target 覆蓋範圍，決定修復是否落到提交檔案

SwiftUI 自動產生 Info.plist 很容易造成錯覺。自動產生的是建置流程中的一部分，不代表所有 Configuration、Target 及腳本最後都輸出相同內容。UIKit 舊專案則常見另一種問題：原始 plist 已更新，但 Release Target 仍指向另一個檔案。

我們會逐層檢查：

  1. 在 Xcode 的 Project 與 Target 設定中，確認實際提交的 App Target。
  2. 分別查看 Release、測試用 Configuration，以及對應 Scheme。
  3. 找出 INFOPLIST_FILE、啟動螢幕相關 Build Settings 和資源 Copy 階段。
  4. 搜尋建置腳本是否在 Archive 前後產生或改寫 plist。
  5. 若使用 Flutter、React Native 或其他跨平台框架，檢查框架模板與 iOS Runner／主 App Target 的實際輸出，而不是只改跨平台根目錄的設定。

Apple 的 Build Settings Reference 可用來核對變數來源。這一步也能找出最常見的隱性成本：開發者在本機 Debug 修好，CI 或遠端伺服器以另一個 Scheme 建置，最後上傳的仍是舊配置。

04

第三項指標：Archive 產物一致性，才是修復完成的證據

源檔案正確，不等於 App Store Connect 收到的 .ipa 正確。建置設定、腳本、快取或不同 Scheme 都可能改變最終產物。因此驗收對象必須從「專案內的 plist」移到「Release Archive 內的 plist」。

可勾選的 Release 驗收清單

  • [ ] 使用與提交一致的 Scheme 和 Release Configuration 建立 Archive。
  • [ ] 在 Xcode Organizer 確認 Archive 的日期、版本和 Build 編號。
  • [ ] 匯出或解開最終 .app，檢查其中的 Info.plist。
  • [ ] 確認 UILaunchScreen 或有效 storyboard 宣告不是空值。
  • [ ] 確認宣告指向的 storyboard、圖片或資源實際包含在 .app。
  • [ ] 對照建置前後的脫敏 Build Settings，確認沒有腳本覆寫。
  • [ ] 保存 Archive 檢查結果、脫敏路徑及上傳日誌。
  • [ ] 先上傳 TestFlight，確認 ITMS-90870 不再出現，再決定生產提交。

請把「源專案設定」和「伺服器實際收到的二進位檔」分成兩份記錄。Apple 的上傳 App 說明及建置狀態說明可用來核對上傳後的狀態，但不能取代本地 Archive 內容檢查。

05

第四項指標：首次啟動結果，與伺服器合規是兩個驗收面

ITMS-90870 消失，只代表伺服器校驗這一關通過。使用者看到的啟動畫面仍要另外確認。Apple 建議先刪除裝置上的舊 App，再重新安裝和啟動；否則系統可能保留舊快取，令修復結果看起來沒有生效。

驗收時記錄以下現象：

  • 是否出現空白畫面或舊圖殘留。
  • 圖片是否被錯誤裁切。
  • 文字、標誌及背景是否落在安全區域內。
  • iPhone 與 iPad 的方向或尺寸變化是否造成異常。
  • SwiftUI、UIKit 和跨平台入口是否都走到預期的啟動配置。

模擬器適合快速重現與截圖，但正式發布前仍要保留真機檢查。不要把「感覺啟動較快」寫成性能結論；本篇沒有對啟動時間作本站實測，也沒有足夠證據支持這種比較。

06

第五項指標：上傳結果，比本機成功 Archive 更接近完成

遠端建置或自動化流程要使用與生產一致的 Xcode、Scheme、Configuration 和 Archive 入口。否則本地修復可能只對本機環境有效，遠端 Mac 仍會因自動產生 plist 的路徑、腳本版本或環境變數不同而失敗。

建議採用以下順序：

  1. 在測試分支固定 Xcode 27 Beta 版本，並記錄 Xcode 系統要求。
  2. 將專案、簽名資料及建置腳本放到可回退的版本狀態。
  3. 在獨立 macOS 環境執行一次互動式 Release Archive。
  4. 用同一個 Scheme 和 Configuration 執行自動化 Archive。
  5. 比對兩份 .app 的 Info.plist、啟動資源及 Build 設定。
  6. 先送 TestFlight，保存處理結果和 ITMS-90870 狀態。
  7. 在 Apple 公布正式生產接收條件前，不把 Beta 測試流程替換成唯一的商店發布入口。

若現有電腦無法安裝對應 Xcode，您可以先閱讀遠端 Mac 雲端訂閱方案，把它當作獨立的相容性驗證環境，而不是立刻改動目前穩定的生產打包機。對需要持續跑 Archive 的團隊，也可先從 MESHLAUNCH 的 Mac 遠端環境確認連線方式與權限是否符合測試流程。

07

常見驗收問題

ITMS-90870 Missing launch screen 應如何處理？

先確認建置 SDK 是否為 iOS 27 或更高版本。接著在實際提交的 App Target 補上有效啟動螢幕宣告，檢查 Release Archive 內的最終 Info.plist 和資源，再重新上傳 TestFlight。若錯誤仍在，優先追查 Scheme、Configuration 及腳本覆寫，不要先刪除 DerivedData 或重裝 Xcode。

SwiftUI 自動產生 plist，為何仍會被判定缺少啟動螢幕？

因為自動產生設定可能只套用在某個 Target 或 Configuration。跨平台框架也可能在建置時重新生成 iOS 設定。請以 Archive 內的 Info.plist 為準，逐一比對 Release 設定、Runner 或主 App Target，以及任何會改寫 plist 的腳本。

應選 UILaunchScreen 還是 LaunchScreen.storyboard？

新 SwiftUI 專案通常可沿用 UILaunchScreen 方向；已使用 storyboard 的 UIKit 專案則可先保留原架構。選項本身不是唯一判準，重點是鍵值有效、資源存在、Build Settings 指向正確，並且在最終 .app 內可被確認。

如何檢查 Archive 裡的啟動螢幕？

建立 Release Archive 後，在 Organizer 找到匯出的 .app，查看其中的 Info.plist，確認啟動螢幕鍵值及相關資源均已封裝。再刪除舊 App，使用模擬器快速複核，最後以真機確認首次啟動畫面，並把結果與上傳日誌一併保存。

Xcode 27 Beta 建置能否送到正式 App Store？

截至 2026 年 8 月 27 日，Apple 已確認 Xcode 27 Beta 5 建置可上傳 TestFlight，但尚未在指定資料中確認 Xcode 27 正式版日期及 App Store 接收 iOS 27 SDK 生產建置的具體日期。生產切換前，必須重新核對官方 Release Notes，並保留 Xcode 26 回退流程。

對已經在本機修好的專案，我們仍建議再用一套獨立、可回退的 macOS 環境重跑 Xcode 27 Archive 和 TestFlight 上傳。現有方案若依賴共用打包機，常見缺點是 Xcode 版本被其他專案鎖住、腳本修改無法追溯，以及本機與 CI 的 Target 設定不一致；若使用個人電腦，則可能無法安裝測試所需版本。短期租用 MESHLAUNCH 的 Mac，可把相容性驗證與穩定生產機分開，先完成這次啟動螢幕校驗；但若需要長期固定負載或實體硬體介面，自購 Mac 仍較適合。