症狀：你執行模擬內存警告操作，卻不確定 App 是否真的收到通知，或是否只是模擬器畫面停頓。
最快解法：先在 Xcode 27.2 RC 的實際環境確認入口，再用回呼或日誌驗證 App 收到警告，接著檢查資源清理；真實低記憶體、系統終止與恢復仍須以相應證據驗收，必要時在實體 iPhone 複測。
適合維護圖片、媒體或大型資料快取，且需要確認警告後清理行為的 iOS 獨立開發者。
正在使用 Xcode 27.2 RC 的你，可以據此判斷模擬警告是否適用於目前的驗收項目。
負責遠端 Mac 或建置環境的你，也能用本文劃清模擬器測試與實體設備證據的界線。
最後更新於 2026 年 10 月 28 日；Xcode 版本狀態與已知問題依據 Apple 的 Xcode 發布記錄、Xcode 系統需求及版本發布說明核對。
Xcode 27.2 RC iOS 記憶體警告測試的驗收指標
不要把「選單操作完成」當成「App 已收到警告」，也不要把「App 收到警告」當成「真實低記憶體情境已通過」。這些是不同層級的證據：模擬入口、App 回呼、資源釋放、生命週期結果，以及系統是否終止程序。
Apple 在 2026 年 10 月 19 日發布 Xcode 27.2 RC；可用的 macOS、SDK 與 Swift 資訊，應以Apple 的 Xcode 系統需求頁面和RC 發布說明為準。Apple 的發布說明曾記錄 Beta 2 的模擬記憶體警告選單問題，但這不代表 RC 已修復，也不代表 RC 仍有相同問題；你必須檢查目前版本的說明並實際操作確認。
Xcode Device Hub 是核對模擬裝置與相關操作狀態時可參考的入口，但畫面上看得到選項，不足以證明 App 收到警告。你可以參照 Apple 的 Device Hub 說明，再以 App 端可觀察的回呼或日誌補足證據。
第一關：模擬入口是否確實觸達 App？
先確認測試條件
開始前，記下 Xcode 版本、所選模擬器與正在執行的 App 版本，並確認測試操作是對準目前那個模擬裝置。若版本不符合專案需求，或選單狀態與預期不同，先停下來核對 Xcode 27.2 RC 發布說明和系統需求，不要沿用其他 Beta 版的測試結論。
接著執行一次模擬操作，同步觀察 App 的畫面、除錯輸出及專案既有日誌。你要找的是能連結到警告處理路徑的證據，例如回呼內明確記錄事件，而不是只看到選單消失、模擬器畫面刷新或操作介面短暫停頓。
怎麼判斷 Xcode 27.2 RC 的模擬入口有效？
只有在操作後觀察到 App 端的警告事件，才把入口記為已觸達。若沒有回呼或日誌等證據，這次操作應記為「未確認」，而不是「通過」；接著檢查目標裝置、目前選取的執行目標與 RC 發布說明，再重新測試。
第二關：iOS 記憶體警告回呼是否執行？
App 收到警告，才有條件驗收自己的清理邏輯。依專案架構檢查適用的應用程式委託、作用中檢視控制器或通知處理路徑，並將回呼記錄與測試操作的時間及頁面狀態對照。Apple 的低記憶體警告回應文件可用來核對應用程式應如何回應這類通知。
以下項目可直接加入你的驗收紀錄：
- [ ] 操作前記錄目前頁面、使用者輸入與主要資料狀態。
- [ ] 確認預期的警告處理程式有執行，而不是只憑畫面變化推斷。
- [ ] 記錄回呼發生時的頁面、快取狀態與必要診斷訊息。
- [ ] 測試操作結束後，確認 App 仍可繼續使用目前功能。
如果畫面卡頓或模擬器暫停，卻沒有警告回呼證據，應把這些現象和收到警告分開記錄。除非已確認它們與 App 的警告處理流程有直接關聯，否則不能拿來替代回呼驗收。
第三關：驗收警告後的可清理資源釋放
回呼有執行，不代表清理達到預期。你要逐一確認警告處理邏輯會釋放哪些資源，以及釋放後功能是否仍可正常使用。優先檢查可重新載入的圖片快取、可重新計算的資料、非目前畫面所需的暫存物件，以及其他產品定義為可丟棄的資源；不要把使用者正在編輯的內容或唯一資料當成可隨意清除的快取。
在相同測試路徑下，比對警告前後可觀察的記憶體狀態與功能表現。Apple 的記憶體使用資訊收集指南可協助你選擇診斷資料；若需要調查程序被系統終止的原因，也可參考Jetsam 事件報告說明。
怎樣驗收清理而不誤判？
確認清理路徑確實執行，並逐項重用受影響的畫面與功能；檢查是否能按需重新載入資料、使用者輸入是否保留，以及是否出現新的錯誤。沒有實際測量證據時，不要宣稱釋放了特定記憶體數量、達到某個門檻，或提升了某個百分比。
注意：警告回呼是 App 收到警告的證據，不等同於量測結果；一次畫面操作也不能單獨證明資源已釋放，應把回呼紀錄、狀態變化與功能複測分開留存。
第四關：驗收切換背景後的狀態恢復
內存警告測試若只記錄「沒有崩潰」，會漏掉狀態丟失、畫面重建異常或資料無法重新載入等問題。你應在同一測試路徑中記錄警告前後的頁面狀態、使用者輸入與關鍵資料，再切換至背景並返回前景，確認 App 如何恢復。
- [ ] 警告前的必要使用者輸入仍可取得，或已按產品預期保存。
- [ ] 清理後返回畫面時，可重建的資料能按需重新載入。
- [ ] 切換背景與返回後，導覽位置及關鍵畫面狀態符合產品設計。
- [ ] 日誌能區分 App 自行清理與生命週期變化造成的結果。
若某項狀態只在特定頁面或資料載入順序下丟失，請記錄可重現的操作路徑；不要以一次成功返回前景，推論所有恢復路徑均已通過。
第五關：模擬警告與系統終止證據的界線
模擬內存警告能否證明 App 會被系統終止？
不能。模擬警告可用於測試 App 的警告回應，但它本身不證明裝置在真實記憶體壓力下會採取哪種處置，也不等同於 App 被系統終止。Apple 提供的 Jetsam 事件報告說明可用於調查相關系統診斷證據；若驗收目標包含終止後恢復，應分開檢查終止證據與下次啟動的狀態恢復結果。
依驗收目標選擇證據，不要把以下結果混為一談：
- App 收到警告：以回呼或日誌證明警告處理路徑執行。
- App 發生崩潰：以相應的崩潰診斷資料調查，不將它直接寫成系統終止。
- App 被系統終止：應取得與終止相符的診斷證據，再驗證重新啟動後的資料與狀態恢復。
按證據條件選擇驗收方式
- 若目標只是確認警告回呼及清理邏輯，且 App 端有可觀察證據，則以模擬操作完成這一部分驗收，並清楚標示為模擬環境結果。
- 若目標包含真實低記憶體狀態、系統終止或裝置上的恢復行為，則補做實體 iPhone 測試；沒有設備證據時，結論應標為尚未完成，而不是改用模擬警告代替。
- 若目前無法取得實體 iPhone，則保留模擬測試、App 日誌與現有診斷資料，明列缺少的設備證據及未驗收項目；不要宣稱已驗證真實低記憶體行為。
第六關：整理遠端 Mac 與實體 iPhone 的證據
遠端 Mac 可以提供執行 Xcode、管理專案及檢視日誌的 macOS 環境，但遠端桌面可連線或模擬器測試通過，都不能代替實體 iPhone 上的低記憶體驗收。遠端測試紀錄至少應包含 Xcode 與模擬器執行資訊、操作路徑、App 日誌、警告後狀態，以及哪些結論只適用於模擬環境。
沒有實體 iPhone 時，怎麼判斷驗收還缺什麼？
按驗收目標逐項對照：入口是否觸達、App 回呼是否執行、可清理資源是否釋放、功能與狀態是否恢復，以及是否取得真實終止或低記憶體證據。前幾項可以由模擬環境與 App 診斷紀錄支持；涉及真實裝置記憶體狀態的項目，則應標示為待實體設備驗證。
若你考慮把 Xcode 工作移到遠端 Mac，應先確認實際可用的 Xcode 版本與專案所需的測試方式，再判斷是否能取得完成驗收所需的實體設備。你可以先看 KVMFLUX 的使用情境，並在選用前核對遠端 Mac 方案資訊。
對只偶爾執行 Xcode 的開發者，自行購買 Mac 會帶來硬體採購與維護成本；若沿用現有 Windows 或 Linux 環境，則仍須另找 macOS 建置與測試方式；而只靠模擬器，也無法補足真實低記憶體與系統終止的設備證據。若你目前缺少可用的 Mac，短期租用 KVMFLUX 可讓你取得遠端 macOS 環境執行 Xcode 工作，但仍要按驗收目標安排實體 iPhone 複測。若長期持續重載、需要本機實體介面，或必須把 iPhone 接在身邊操作，購買自己的設備可能更合適；決定前，先核對方案中的 Xcode 可用性與設備測試條件。