換到新 iPhone 後，我找不到 X。到 App Store 點下載雲朵，它轉了一下，又變回雲朵，沒有錯誤提示。最後讓下載恢復正常的，是從 Mac 對這支 iPhone 的 X 發出一次明確限定範圍的卸載請求，再回到 App Store 重新下載。
這篇記錄我和 Codex 怎麼找到線索、實際改了什麼，以及這次經驗如何變成開源的 macOS 工具 App Restore Rescue。工具能從使用者主動開始的短時間監看，或自行選取的本機日誌，找出回復衝突候選 App，再讓使用者逐一確認是否卸載。它不能只憑下載按鈕轉圈，就判定手機有同一種故障。
我最初的要求很簡單：先調查，不要修改。換機後已經有一堆帳號與 App 重新設定完成，我希望先知道卡在哪裡，再決定要付出什麼代價。
當時確認到的狀況是：手機還有充足空間，相關限制沒有開啟，設定的 App 清單沒有 X，iCloud 備份頁也沒有顯示整機仍在回復。搜尋與 Siri 的最佳化尚未完成，確實可能影響搜尋體驗，但這個畫面本身無法解釋 App Store 為何拒絕下載。
換機後還有背景工作，原本就是正常流程的一部分。Apple 說明，完成初始設定後，App、照片與其他內容仍可能繼續下載；也提供查看 iCloud 回復狀態的方法。這些文件說明正常流程，不能直接證明我的手機仍在正常回復，或證明所有下載失敗都出自同一原因。Apple：從備份回復裝置、回復後缺少資料時的檢查方式。
真正讓方向收斂的是裝置日誌。X 的下載嘗試出現了這個錯誤：
ASDErrorDomain Code=506 "Duplicate restoring request"同一條排查線索裡，系統仍認為這個 App 已有一個由 AirTraffic 建立、意圖為 Restoring 的安裝協調工作（coordinator）；新下載卻找不到對應的 placeholder，下載 asset 也沒有正常進入佇列。
可以把 coordinator 理解成系統管理安裝流程的工作紀錄，placeholder 是尚未完成的 App 佔位狀態，asset 則是要下載的內容。這組訊息支持的推論是：X 的舊回復工作仍阻擋新的下載，但後續工作已經接不上。它比「網路可能不順」具體，也比「整台手機的 App 資料庫壞了」範圍小得多。
我沒有直接檢查 iOS 的內部資料庫，因此不會宣稱已證明是哪個檔案或哪一筆資料損壞。最初是什麼事件造成這個狀態，也沒有定論。「換機後發現」是時間順序，還不是特定機型或 iOS 版本造成故障的證據。
另外一個需要查清楚的細節，是 X 的識別碼。日誌裡的 com.atebits.Tweetie2 看起來不像 X，但它確實是官方 iOS App 使用的 Bundle ID：X 官網的關聯檔案列有 8248RGMF2D.com.atebits.Tweetie2，App Store 頁面的產品 ID 則是 333903271。舊名稱保留在技術識別碼裡，本身不是異常。X 官方關聯檔案、X 的 App Store 頁面。
我也曾懷疑是不是近期品牌或產品整合造成影響。官方確實公布了把 Grok、Grok Bot、Cursor 與 X Premium 放在一起的訂閱方案，頁面也使用 SpaceXSI 名稱。但商業訂閱組合與 iOS 的 Bundle ID、安裝協調狀態，是不同層次的事；目前沒有證據把這些變動與這次下載失敗連起來。官方訂閱公告。
網路上能找到其他人的相近經驗，但證據必須分層看：
| 公開資料 | 可以支持什麼 | 不能據此斷言什麼 |
|---|---|---|
| PTT 作者 cinnamo1208 的換機經驗 | 同樣出現 506 與 Duplicate restoring request，App 也不在一般清單中；作者回報透過電腦端處理後恢復下載 | 不是通用保證；留言有人回報 Google 與 X 沒有成功 |
| Reddit 的 Finder 回復案例 | 出現 AirTraffic 的 Restoring 與新安裝意圖衝突，和本案有相近機制線索 | 該篇沒有展示相同的 506 訊息，也沒有已確認的修復結果 |
| Apple 的回復說明 | 初始設定完成後，App 可能繼續在背景下載 | 不是 Apple 對這個特定故障的公告，也沒有提供發生率 |
感謝 cinnamo1208 的 PTT 原文（可閱讀的鏡像與留言）提供方向；Reddit 的第一手案例也值得交叉閱讀。這些是個案，沒有整體換機人數或一致的檢測方法，所以我無法回答「究竟有多常見」，更不會用幾篇貼文推算比例。
甚至只有 ASDErrorDomain 506 也不夠。Jamf 記錄過 Mac 正在安裝 App 時出現一般的重複請求，Microsoft 也記錄過特定 macOS 版本的 506 安裝問題。平台、完整錯誤文字與回復情境都需要一起看。Jamf 的重複安裝說明、Microsoft 的 macOS 案例。
PTT 案例包含先嘗試安裝舊 IPA、再移除的做法。我這次採取的操作更少：確認 Bundle ID 與目標手機後，直接透過開源工具 ideviceinstaller 提出單一 App 的卸載請求。沒有下載未知來源 IPA，也沒有先安裝舊版 X。
第一次執行時還遇到另一層問題：Codex 的受限制執行環境回報 No device found。手機其實已接上並解鎖；在允許存取 USB 裝置服務的環境裡，唯讀列舉能找到正確手機。這次前後對照確認了執行環境的存取差異，不能把第一次的訊息直接解讀成線材壞掉或手機沒接上。
確認連線與授權範圍後，我才讓 Codex 對指定手機、指定 Bundle ID 重試卸載。結果是 Uninstall: Complete，程序結束碼為 0。接著我回到手機，手動在 App Store 重新下載 X，這次成功了。
這兩段結果要一起看：命令完成，表示卸載請求回報完成；App Store 真的能重新下載，才是我關心的問題已解除。這也支持「針對這個 App 處理安裝狀態有效」的判斷，但仍不足以證明所有 506 都能用同一招修好。
卸載不是無損的清除快取。它可能刪除這個 App 在手機上的本機資料。 即使圖示不見了，也不能假定本機沒有資料。必要的資料與備份應先確認；Apple 的一般刪除重裝建議同樣提醒可能失去 App 儲存的資料。Apple：App 無法正常運作時。
我把這次操作整理成 App Restore Rescue，希望下一個遇到類似問題的人，可以先看清楚候選項目與操作範圍。
工具的工作流程是：
- 以 USB 接上並解鎖 iPhone，核對目標裝置。如果系統要求信任這部電腦，由使用者自行決定並完成。
- 選擇開始短時間監看
appstored，等工具顯示「已開始監看」後，再到手機的 App Store 手動點一次有問題 App 的下載雲朵，等這次嘗試結束。監看本身只讀取訊息；點下載則可能直接成功安裝。如果已經有包含失敗過程的本機日誌，可以直接匯入，不必再次點擊。 - 掃描與
ASDErrorDomain 506、Duplicate restoring request有關且能關聯到 Bundle ID 的紀錄，列出候選 App。候選代表「這份日誌曾經出現相關錯誤」，不代表「目前仍然故障」。工具不會自動點下載、不會持續在背景收集完整日誌，也不會上傳日誌。 - 使用者選擇一個候選 App，先做唯讀檢查。App 清單中查不到項目，也不能單獨當成沒有任何殘留狀態的證據。核對手機與 Bundle ID、閱讀資料刪除提醒後，才明確確認卸載。操作逐一進行，不預設批次刪除。
- 完成後，由使用者回到 iPhone 的 App Store 重新下載，親自驗證結果。
日誌檔可能混有其他裝置、歷史錯誤或已修復的事件。即時監看也可能因為時段不對、訊息未輸出或資訊被隱去而抓不到線索。因此「沒有候選項目」不能解讀成「所有 App 都正常」。掃描結果只是排查輔助，無法取代核對目前症狀，也不能保證找出所有換機後尚未完成的 App。若只有一般下載問題，應先依 Apple 的下載排查步驟檢查、正常重新啟動並重試；持續失敗時，把已去除識別資訊的錯誤交給 Apple 支援。
App Restore Rescue 沒有遙測。原始日誌只留在本機記憶體，介面會遮蔽裝置識別資訊。日誌與候選 App 清單仍屬於你的資料，請不要把原始診斷封存檔直接貼到公開 issue。
工具需要使用者自行安裝 ideviceinstaller 1.2 或更新版本，以及相關裝置連線工具。底層的裝置通訊與卸載能力來自 libimobiledevice 與 ideviceinstaller，後者是 GPL 授權的獨立專案；這些上游維護者應得到完整的功勞。ideviceinstaller 的授權檔案。
偏好終端機的人，可以閱讀原始碼與上游文件，不必使用 GUI。以下是這次操作的結構，範例使用佔位符，不包含我的裝置識別碼。先確認工具版本並唯讀列出 USB 裝置：
ideviceinstaller --version
idevice_id -l核對列出的裝置，把 <YOUR_IPHONE_UDID> 換成你自己的值。下一行會發出 X 的卸載請求，可能刪除其本機資料；只有在確認目標與風險後才執行。 其他 App 必須另行核實自己的 Bundle ID，不要套用 X 的識別碼。
ideviceinstaller -u '<YOUR_IPHONE_UDID>' uninstall com.atebits.Tweetie2這個語法對應 ideviceinstaller 1.2 的介面；較舊版本的參數不同。這不是依 coordinator UUID 直接刪內部紀錄的工具，而是向手機的 App 安裝服務提出指定 Bundle ID 的一般卸載請求。上游使用說明、1.2.0 原始碼。完成後仍要回到 App Store 重試。若依然失敗，保留已去識別化的錯誤供進一步排查，不要把操作擴大成不明範圍的清理。
原始碼放在 dAAAb/app-restore-rescue，下載見 GitHub Releases。初版 macOS App 使用 ad hoc 簽章，沒有 Developer ID 簽章，也沒有經過 Apple 公證。這不是 Apple 提供或認證的修復工具；無法接受這個發行條件的人，可以審閱原始碼自行建置，或採用上面的 CLI 流程。
我能確認的是：這次 X 在明確限定的卸載之後，恢復了 App Store 下載。公開案例與工具的價值，是讓下一次排查有可以核對的證據、清楚的作用範圍，以及一個真正需要使用者確認的修改步驟。