安裝安全性

由 DuoUpdater 自己主導安裝流程，才讓下面這些檢查有辦法做到。每一項檢查，針對的都是「用軟體取代軟體」這件事在你的 Mac 上可能出錯的地方。

它從不強制結束正在執行的 App

安裝程式本身不會結束任何東西。更新完成後重新開啟 App 是另外一個步驟，預設開啟，也可以在「設定」裡關閉⁠——執行時，送出的只是一般的 terminate()。App 會照常跳出自己的儲存提示，也可以拒絕結束。拒絕結束的 App 會維持執行，並保留「重新開啟」按鈕，所以未儲存的工作內容絕不會因為被強制結束而遺失。

值得知道的是：重新開啟是在新版本已經寫入磁碟之後才發生的。所以如果你拒絕結束，就會有一份已更新的 App 套件，和一個仍在執行舊程式碼的行程並存，直到你自己重新開啟它為止。這正是那一列上「重新開啟」按鈕的意思。

在取代任何東西之前的五項檢查

EdDSA，僅限 App 自己提供公開金鑰時才會檢查。有些廠商發布的是未簽署的 feed；這些不會直接被拒絕，只是得靠自己通過剩下的檢查。凡是有發布金鑰的 App，就必須產生有效的簽章⁠——下面有一個刻意保留的例外。

接著，不論來源為何，下載回來的套件都要通過四項檢查：

• Developer ID 簽署，做嚴格且徹底的驗證⁠——涵蓋每一種架構，也包含內嵌的程式碼，不只是外層套件。
• Team ID，必須與要被取代的那個 App 相符。
• Bundle identifier，取自簽章本身，而不是取自 Info.plist，所以就算重寫 plist 也無法藉此蒙混過關。
• 可執行的架構，讀取自實際的 Mach-O 切片。這台 Mac 無法執行的建置會被拒絕，不會被裝上去然後壞掉。

下載回來的東西一旦被判定屬於另一個開發者，就會被拒絕，而不是照裝不誤。

例外情況：當某個廠商更換簽署金鑰、卻沒有先發布過渡版本時，舊金鑰就再也無法驗證他們之後發布的任何東西。與其讓這個 App 永遠卡住，DuoUpdater 會把驗證失敗的 EdDSA 簽章「記下來」而不是直接拋出錯誤，只要其餘四項檢查都通過、而且下載回來的套件帶有能驗證 feed 的新金鑰，安裝仍然可以繼續進行。這種情況下，真正撐起信任的是 Developer ID 和 Team ID 這兩道關卡。

大版本升級需要你先確認

跳到新的大版本時，畫面上出現的是一則警告，而不是一鍵按鈕，因為對商業軟體而言，這可能代表需要新的授權。決定權在你；DuoUpdater 不會刻意把它做得很輕鬆，藉此替你做決定。

安裝前，所有東西都會立即重新檢查一次

已經開著看了一個小時的清單，內容早就過期了。真正置換之前，系統會再檢查一次，所以不會對一個其實已經被其他東西更新過的 App，多此一舉地重複安裝。

還原用備份

被取代的那份 App 套件會被保留下來，可以還原回去。duo backups 會在命令列裡列出所有還原點；App 本身也提供同樣的功能。

偵測是否需要重新開啟

如果某個 App 已經在磁碟上完成更新，但正在執行的仍是舊的建置⁠——這是透過 LaunchServices 比對出來的，不是用猜的⁠——那一列就會顯示「重新開啟」動作，而不會被回報為已是最新版本。磁碟上的版本和正在執行的版本，是兩件不同的事，那一列會告訴你哪一個已經過期了。