摺疊螢幕拖一下就過去了？iPhone Duo 的 Drag and Drop，考的其實是資料層功課

把鏡頭拉近一點，先看這條新聞裡最容易被略過的那一行。2026 年 9 月 10 日，蘋果秋季發表會推出首款摺疊產品 iPhone Duo 之後，Apple Developer 網站已經把 Duo 列為獨立的適配主題，多顯示、多 Scene、相機體驗等教學影片陸續上架。近期有開發者在掘金發布了一篇《iPhone Duo 適配 Drag and Drop 實現方案》，把這個看似邊角的功能拆開講，讀完會發現一件事：Duo 適配最花功夫的地方，跟新手勢無關，跟資料怎麼被可靠地傳過去有關。

拖放不是一個 API，是兩層責任

iOS 的 Drag and Drop 從 2017 年 iPad 多工時代就存在，架構上分成互動層與資料層。互動層由 UIDragInteractionDelegate 負責「從哪裡拖、拖什麼、拖的時候預覽長什麼樣」，UIDropInteractionDelegate 負責「哪裡能接、接什麼、放下之後怎麼處理」。如果來源是列表或表格，UICollectionView 與 UITableView 各有對應的 drag/drop delegate，系統會幫忙處理手勢與滾動的衝突，這比自己手寫長按手勢穩得多。

資料層的主角是 NSItemProvider。它是一個非同步的資料提供者，搭配 UTType 宣告資料格式，雙方靠這份「資料協議」知道彼此在傳圖片、文字、URL 還是 PDF。自訂物件要被拖出去，就實作 NSItemProviderWriting；要接進來，就實作 NSItemProviderReading。

用日常一點的比喻：互動層像郵局的櫃檯人員，決定信怎麼收、怎麼遞；NSItemProvider 是信封，裡面裝的內容可以晚一點再填，但格式要雙方都認得；UTType 則是信封上寫的語言標籤，收件人看到標籤才知道該用什麼方式打開。

localObject 的陷阱：同一張桌子上的捷徑，換張桌子就失效

這篇適配方案裡最值得劃重點的一段，是關於 localObject 的提醒。在傳統單螢幕 iPhone 上，App 內部拖放常常偷懶：因為來源物件就在記憶體裡，直接把整個物件塞進 localObject 傳過去，快又省事。

問題在於，Duo 展開後是雙區域、多 Scene 的世界。拖放的兩端可能分屬左右兩個 Pane，甚至一邊是自己的 App、另一邊是別人家的 App。這時 localObject 這條捷徑隨時可能斷掉，真正可靠的傳輸通道是 NSItemProvider 裡註冊的資料表示，也就是那個 PNG 的 NSData、那段文字、那個 URL。這與我們先前在蘋果 2026 秋季發表會的產品節奏分析裡觀察到的方向一致：Duo 不是把螢幕變大而已，它把 App 從「獨佔一面螢幕」的世界搬進「與別人共享一面螢幕」的世界，過去靠單一視窗假設寫出來的程式碼都會被重新檢驗。

換句話說，Duo 適配的核心原則可以濃縮成一句工程判斷：App 內拖放可以用 localObject 加速，但永遠要保留 NSItemProvider 的讀取路徑當作正規軍。這就像公司內部轉文件，走內部信箱很快，但文件本身的格式與內容必須完整到「寄給外部客戶也看得懂」的水準，否則哪天流程換了，文件就成了廢紙。

左右 Pane 的佈局，別再寫死任何寬度

互動設計層面，Duo 典型的拖放場景是左邊一個來源 Pane（可拖的圖片、檔案、卡片），右邊一個接收或編輯區。實作原則說來不玄，卻每一條都對應一個真實的翻車點。

左右區域的佈局不能寫死螢幕寬度，要交給 Auto Layout、Size Class 與 Safe Area。這在多尺寸裝置走了十幾年的 iOS 上本是常識，但實務上大量歷史程式碼仍藏著寫死的 frame 與 magic number，摺疊裝置一展開，這些假設全數現形。

Drop 的判斷要基於 UTType 而非具體類別。判斷「對方丟來的是不是圖片」比判斷「是不是 UIImage」來得穩，因為跨 App 之間你拿到的永遠是資料表示，對方 App 記憶體裡的類別跟你無關。

Drop 區域要給明確的 hover 狀態，邊框高亮或背景變色都行。這聽起來是視覺細節，實際上是雙區域裝置上的可用性底線：使用者把卡片拖過螢幕中線時，需要即時知道「這裡收得下」。大圖不要同步解碼，loadObjectOfClass 的回調之後再回主更新 UI，否則拖放的流暢感會直接被解碼卡死。

對照我們在iPhone Duo 上市與市場考驗的分析中提到的處境：這款定價一萬六起的裝置，短期內用戶基數有限，開發者適配的投資報酬需要時間驗證。但 Drag and Drop 這類基礎互動的適配成本低於重寫整個介面，卻能直接決定 App 在展開態「像原生」還是「像被拉寬的手機 App」，屬於優先順序值得放前面的那類工作。

對開發者與一般使用者的「所以呢」

這篇技術文章的價值，在於它把 Duo 適配從「要不要重做介面」的大哉問，收斂到幾個可執行的檢查點：資料傳遞走 NSItemProvider 而非 localObject、佈局交給約束系統、Drop 判斷基於 UTType、解碼非同步、hover 狀態清楚。對正在評估適配優先順序的團隊來說，這是一份可以直接拿去對程式碼庫盤點的清單。

對一般使用者，訊號也很單純：摺疊 iPhone 買回來之後，前幾個月的體驗落差會出現在「跨區域拖東西」這種小動作上。哪家 App 把卡片從左屏拖到右屏編輯區時順暢、有回饋、不閃退，哪家就是真的做了功課。規格表上看不到的，往往才是重點，而這次那個重點，藏在 NSItemProvider 這個十幾年前就存在的老元件裡。新的硬體形態，最後考的常常是最基礎的工程紀律。