Apple 在 2026 年 11 月 12 日更新 App Store Connect 說明：從 2027 年初起，部分含 On-Demand Resources 的上傳將不再接受；公告沒有列出確切生效日。Apple 的 ODR 上傳限制說明 因此，新 App 與過去未使用 ODR 的 App 應在限制開始前移除上傳內容中的 ODR；已使用 ODR 的存量 App 不代表立即停用，現在應先盤點範圍，再評估遷移至 Background Assets。這不是一鍵轉換，完成後還要以 Xcode 本地模擬服務和專案發布流程驗證。
最後更新於 2026 年 11 月 12 日；上傳限制與技術流程核對自 Apple App Store Connect 說明及 Background Assets 開發文件。
本文適合需要核對 ODR 上傳資格的 iOS App 與遊戲開發者。
負責資源下載架構的工程師，可用本文盤點標籤、請求程式碼與資產包策略。
Apple 平台 CI 與發布工程師，可依檢查項目安排 Xcode 建置、本地測試和分發驗收。
先分清楚上傳限制、平台棄用與既有 App
這三件事不能混為一談：上傳限制決定特定 App 的 ODR 封裝是否還能送交；平台棄用表示技術方向正在轉變；已使用 ODR 的 App 則不因此立即停止運作。
Apple 說明，從 2027 年初起，不再接受來自新 App，或過去未使用 ODR 的 App、且包含 ODR 的上傳。公告未提供確切日期，也不是宣告所有既有 ODR App 同時失效。App Store Connect 的限制說明 因此，判斷依據應是 App 的使用歷史與待上傳產物，而不是只看 Xcode 專案目前能否成功建置。
另有一項平台層面的變化：Apple 指出 ODR 自 iOS 27、iPadOS 27、tvOS 27 與 visionOS 27 起棄用，並建議採用 Background Assets。Apple 的 ODR 文件與遷移方向 棄用不等同於既有 App 當下不可用；但若新功能仍綁定 ODR，維護成本會延續到下一輪平台相容性與發布驗收。
以專案歷史和封裝產物確認適用範圍
不要只搜尋程式碼中的 NSBundleResourceRequest。專案可能仍保留 ODR 設定，或封裝產物含有資源，即使目前功能路徑已經不常觸發。反過來說，找到舊程式碼也不代表每次上傳一定含有 ODR。
建議在遷移分支先完成以下核對：
- [ ] 查閱 App 過往發布紀錄，確認是否曾以 ODR 提供資源。以實際發布過的版本和功能為準，不只看目前分支。
- [ ] 檢查 Xcode 專案中的 ODR 設定、資源標籤及建置配置，確認它們是否仍參與目前封裝。
- [ ] 封存候選版本後檢查產物，確認是否包含 ODR 資源包；不要以「建置成功」代替上傳資格檢查。
- [ ] 搜尋
NSBundleResourceRequest的建立、請求、完成及釋放流程，記錄每個呼叫對應的畫面、關卡或內容解鎖功能。 - [ ] 對照歷史 App 版本與本次待上傳內容，將專案標記為「新 App／此前未使用 ODR」或「已使用 ODR 的存量 App」。
- [ ] 把判斷結果和封裝檢查納入發布檢查，下一次更動資源設定時重新核對。
如果不能確認既有版本是否實際使用過 ODR，先查發布資料與程式行為，再向發布負責人確認；不要把專案設定中曾出現 ODR，直接當成已使用的證明。
依資源需求選擇 Background Assets 策略
Background Assets 的遷移工作是重新設計資源交付流程，不是把舊標籤改名。舊 ODR 的標籤可能和程式中的資源請求、生命週期管理及錯誤處理緊密耦合。換成 asset pack 後，必須重新回答：資源何時需要存在本機、下載由誰負責、App 如何確認可用，以及下載未完成時使用者會看到什麼。
| 決策情境 | 選項與責任 | 適合的判斷方式 | 遷移時要驗證 |
|---|---|---|---|
| 希望由 Apple 託管資產包 | Managed Background Assets；依 Apple 文件建立資產包，並設定 Apple-hosted 下載流程 | 團隊希望資產包隨 App 發布流程管理，並能配合 App 版本驗收 | 封裝關係、資產包發布狀態、App 如何判斷資源已可用 |
| 希望自行管理資產包託管 | Unmanaged／自行託管；專案負責自行配置資產包與交付端點 | 團隊已有自行管理下載與維運的能力，需要自行負責託管流程 | 端點設定、版本對應、失敗重試，以及下載後的本機可用性 |
| 舊 ODR 專案仍在服務 | 先保留可回退的舊流程，分批遷移到預定策略 | 先按內容、畫面或關卡切分，避免一次改動全部資源請求 | 舊、新資源路徑切換、離線行為、下載失敗與使用者提示 |
建立 Managed asset packs 時，應依 Apple 文件核對資產包建立方式，而不是假設舊 ODR 標籤可直接沿用。Managed asset packs 建立文件 如果選擇 Apple-hosted，另要確認下載設定與 App Store Connect 的上傳、維護責任。Apple-hosted 資產包下載設定 自行託管則需要團隊負責專案設定與交付端點，不能把 Apple-hosted 的流程照搬過去。Unmanaged Background Assets 專案設定
提醒：系統管理下載不代表下載一定成功。請在 App 內明確區分「已發起下載」與「資源已在本機可用」，並為網路中斷、空間不足或資產包版本不符保留處理路徑。
以遷移風險安排驗收順序
把遷移拆成可分別驗證的工作，可以避免只確認資產包能產生，卻漏掉 App 執行時的資源狀態與發布關係。
先盤點依賴。 對每個 ODR 標籤記錄資源內容、使用位置、請求時機與釋放時機。將與畫面切換、關卡進入、付費內容解鎖相關的程式碼單獨標記；這些呼叫通常最需要重新確認載入時機。
再定義可用條件。 為每種資源寫清楚 App 何時必須取得本機副本。可延後載入的內容，和首次啟動或主要流程必須即時可用的內容，不應只因為過去共用同一個 ODR 標籤，就放進同一個下載策略。
接著建立資產包。 按照前述託管選擇建立 Managed 或自行託管的 asset packs，並確認每個資產包與 App 版本、功能及下載時機的對應關係。Apple-hosted 資產包有專屬的上傳流程，應依文件核對上傳與發布關聯。Apple-hosted 資產包上傳流程
然後替換請求邏輯。 逐一處理原有 NSBundleResourceRequest 呼叫，確認新程式碼在哪個狀態下開始下載、如何得知資源可用、畫面何時可以繼續，以及失敗時如何重試或顯示替代內容。Apple 的 API 文件可協助釐清舊請求介面的行為，但不能代替專案層級的遷移設計。NSBundleResourceRequest API 參考
最後做兩層驗收。 先使用隨 Xcode 提供的本地 mock server 測試資產包行為，再走專案實際的分發流程，檢查 App 與資產包是否按預期關聯。Apple 提供本地測試步驟，也有 Apple-hosted 資產包的 TestFlight 測試文件可供核對。Background Assets 本地測試文件 Apple-hosted 資產包 TestFlight 測試流程 本地測試通過只證明該測試路徑符合預期，不等於 App Store 審核已通過。
把發布風險寫進遷移決策
遷移排期可依下面的條件落地：
- 新 App 或此前未使用 ODR：從下一次待上傳版本開始，檢查封裝並移除 ODR；新資源交付優先評估 Background Assets。
- 已使用 ODR 的存量 App：先確認當前服務路徑、標籤與資源請求，再排定分階段遷移。不要因公告就直接停止服務或下架。
- 仍無法證明歷史使用情形：暫緩把專案歸類為存量豁免，先核對實際發布版本和待上傳產物。
- 採用自行託管：把端點維運、資產版本管理與失敗處理列入驗收責任，不要只測 Xcode 本機流程。
- 採用 Apple-hosted：把資產包上傳、App 版本關聯及 TestFlight 驗收納入發布檢查，確認負責人與流程都有紀錄。
如果遷移要在 macOS 上跑 Xcode、封裝資源並重複驗證，CI 團隊應先確認目前建置主機能否穩定提供 macOS 與所需工具鏈。metalvnc 的遠端 Mac 開發環境資訊可作為評估選項；若需要臨時測試或短期遷移環境，也可先查看遠端 Mac 方案與計費方式，並參考使用說明確認連線方式。
相較之下，沿用 Windows 或 Linux 建置主機無法直接提供完整的 Xcode/macOS 驗證環境；只靠單一開發者的本機 Mac，則可能受限於裝置可用性與建置排程；自建 Mac mini 又需要自行處理硬體採購、維護與長期占用。若工作只是階段性的資源包遷移與發布驗收，租用 metalvnc 的遠端 Mac 可減少先購置實機的負擔；若團隊需要長期固定重載，或工作依賴實體連接埠，則應先評估自有設備是否更合適。
常見問題
限制是否有確切開始日期？ Apple 公布的是從 2027 年初開始，沒有列出確切日期。發布排程應以 Apple 後續更新為準，不能自行把某一天當成官方截止日。
已使用 ODR 的 App 是否必須立即遷移？ 不必把公告解讀為立即停用。Apple 表示已使用 ODR 的 App 近期仍可繼續運作；團隊應先盤點並安排遷移，而不是直接停止服務。
Background Assets 能否直接替代舊資源請求？ 不能假設標籤和程式碼可原樣移植。下載時機、託管責任、資源可用狀態與失敗處理都要重新設計。
Xcode 本地測試完成就能確認發布成功嗎？ 不能。本地 mock server 測試用來驗證資源行為；之後仍要走專案實際的上傳或 TestFlight 流程，確認 App 與資產包的發布關係。
常見問題
On-Demand Resources 何時會受到 App Store Connect 上傳限制？
Apple 表示限制從 2027 年初開始，適用於新 App，以及過去未使用 On-Demand Resources、但上傳內容含有 ODR 的 App；目前沒有公布確切生效日期。先核對歷史版本與待上傳封裝，不要只因為專案仍能建置就判定上傳合規。
已上線的 App 使用 ODR，現在就得停止服務或遷移嗎？
不是。Apple 說明，已使用 ODR 的 App 近期仍可繼續運作；上傳限制、平台棄用與既有 App 立即失效是不同事項。建議先盤點資源請求和內容生命週期，再依發布排程安排遷移與回歸測試，不必把這項公告解讀為立即下架通知。
Background Assets 可以直接取代 NSBundleResourceRequest 嗎？
不能假設可以直接替換。NSBundleResourceRequest 的標籤、資源請求時機及釋放行為，未必對應到 Background Assets 的 asset pack 和下載策略。遷移時要重新定義資源何時必須可用、由誰託管，以及 App 如何確認資源已落地，並測試下載失敗時的回退路徑。
如何用 Xcode 在本機測試 Background Assets？
依 Apple 文件建立 asset pack，使用隨 Xcode 提供的本地 mock server 測試下載、資源可用性與錯誤處理，再透過專案實際使用的分發流程驗證 App 與資產包的關係。mock server 測試通過只代表本地行為符合預期，不等於 App Store 審核或 TestFlight 驗收已通過。