Latest macOS 更新檢查工具：把全機 App 的新版本狀態一次看清

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Mac 上想知道哪些 App 有新版本，通常得開 App Store 的更新頁、再開 Homebrew 敲指令，剩下那些官網下載的 App 則要一個一個自己查，查久了大多數人的結論就是放著不更新，等到外掛壞了或安全修補沒跟上才一次處理。Latest 這個開源工具承諾把這三件事收進同一個視窗：掃一遍整台機器，列出所有過期的應用程式，能代裝的直接按按鈕裝。

它免費、走 GPL 授權、有繁體中文介面，專案從 2017 年活到現在。不過在 2026 年的今天裝它之前，有三個問題值得先問清楚：它到底檢查哪些來源、一鍵更新在新的 macOS 上還靈不靈、以及安裝本身需要付出什麼代價。

Latest 檢查的範圍，比你想像的透明

Latest 由德國開發者 Max Langer 一人維護，在 GitHub 上有約 4,800 顆星，全部用 Swift 寫成，授權條款是 GPL-3.0。它把 Mac 上的 App 分成三種來源，各自走一條獨立的檢查路徑，掃完在同一份清單裡並列。

Mac App Store 的應用程式是辨識起來最明確的一群。判斷方式很老實：看 App 套件裡有沒有 App Store 的收據檔案，有就走 Apple 的 iTunes Lookup API 查最新版本號。這條 API 是公開的，請求會帶著你系統設定的地區碼，台灣機器查的就是台灣商店的版本。在 Apple Silicon 機器上從 App Store 裝的 iPhone、iPad App，也會被歸進同一類一起查。

為數更多的另一群，是用 Sparkle 架構做更新的 App。Sparkle 是 macOS 圈非 App Store 軟體的事實標準更新框架，絕大多數官網直接下載的 Mac 軟體都用它。Latest 會讀每個 App 資訊清單裡寫的更新 feed 網址，直接去抓那份 XML 比對版本。遇到少數沒寫 feed 網址、但用 DevMate 服務的老 App，它還會主動拼出 DevMate 的網址去試。

開發者族群常用的 Homebrew Cask，則是走法最粗的一條路。把 Homebrew 官方的 Cask 索引整份抓下來，我實測這份 JSON 有 19,034,331 位元組、收錄 7,778 個條目，抓一次快取一小時。好處是版本資訊統一，代價是每次快取過期都要重新下載將近 19MB。

配對的邏輯藏在原始碼裡，也解釋了後面會提到的誤報問題：Cask 索引裡沒有記 bundle identifier，Latest 只能先用 App 名稱比對，撞名再用 bundle identifier 猜測消歧，如果還是分不出來就寧願略過。作者在註解裡自己寫明這條路不好走，因為同一個名稱可能對應多個條目。

整份程式碼裡沒有任何遙測或分析元件，發出請求的對象就只有 iTunes 查詢、Sparkle feed、Homebrew 索引，加上作者自己維護的一份排除清單。那份清單放在 GitHub 上，我數了一下，列了 34 個無法正確判斷版本的 bundle identifier，讓這些 App 不納入 Homebrew 比對，避免誤報。

下載之前，先看簽章這關

從 GitHub 或官網下載的 0.11 版 DMG，我掛載後驗了三層：程式碼簽章是開發者自己的 Developer ID（Max Langer，團隊編號 VFABJ5RE5Q），Gatekeeper 檢查結果是「Notarized Developer ID」，公證票也確實釘在 App 裡，離線也能驗。整個 App 只有 7.6MB，最低系統需求停在 macOS 10.15，等於 2019 年以後的機器都能跑。這兩層驗證對一般使用者的實際意義是：下載來的安裝檔先被 Apple 掃過一次惡意程式碼，開發者又對包內容簽了名，事後被竄改會被系統拒開。對一個要碰你整台機器 App 清單的工具來說，這關過了才值得繼續談。

安裝方式有三條：官網直接下 DMG 拖進應用程式資料夾、用 Homebrew 下 brew install --cask latest，或從 GitHub Releases 頁拿。Latest 自己的更新也走 Sparkle，更新 feed 的簽章同時掛了新版 ed25519 和舊版 DSA 兩套。我抓了那份 feed，內容還停在 0.11 版，也就是說目前 0.12 的兩個 beta 都不會透過穩定通道推送，想搶先得自己上 GitHub 載。

App Store 一鍵更新，2025 年 11 月之後要重新看

這是整個工具在 2026 年最需要說清楚的一段。

Latest 幫 App Store 應用程式裝更新的原理，是借用 macOS 私有框架 CommerceKit，把更新直接塞進 App Store 自己的下載佇列。這條路 Apple 從來沒有公開支援過，多年來能走是因為框架剛好沒擋。2025 年 10 月，這個狀況先在 macOS 26.1 測試版上現身；11 月初，26.1、15.7.2、14.8.2 三個正式版一起出廠，Apple 在其中修了一個與安裝流程有關的安全問題，修完之後這條路就斷了。

斷的細節作者自己在 GitHub issue #514 裡查過，那則討論累積了 53 則留言。他從系統日誌裡發現，App Store 的下載服務 storedownloadd 沒辦法再和安裝服務 installd 溝通，連線錯誤代碼是 201，甚至用反組譯器去翻了系統服務的內部，最後的結論是這大概是 Apple 刻意的變更，不是巧合的壞掉。從 26.1 的測試版一路跟到正式發布前的 RC 版，行為都一樣。

作者的修補放在 0.12-beta2（2026 年 2 月發布）：改透過一個特權輔助程式來安裝。代價寫得很明白，安裝這個輔助程式是可選的，同時這個版本暫時要求 Full Disk Access 權限，而且作者自己承認還沒查明為什麼需要，也還沒做任何提示，權限沒給的話安裝會直接失敗，畫面上沒有警告。

整理成白話：穩定版 0.11 在上述三個 macOS 版本之後的系統上，App Store 應用程式只剩「檢查」能用；要恢復「代裝」，得裝八個月前的 beta、多裝一個特權程式、再開全磁碟權限。這三道加起來，對多數人來說不如直接開 App Store 的更新頁自己按。

有兩個但書讓這件事不至於全盤失望。第一，這段封路只影響 App Store 來源，用 Sparkle 的 App 完全不受影響，Latest 的作法是針對目標 App 現場建立一個 Sparkle 更新器，用那個 App 自己的更新機制與簽章下載安裝，等於代你按下 App 自己的更新按鈕。第二，0.12 系列的第一個 beta（2025 年 11 月）主要內容是支援 macOS Tahoe 的 Liquid Glass 新介面和換新圖示，介面翻新先行、功能修補在後，看得出這個專案的更新節奏是照作者自己的空檔排的。

順帶一提，在斷裂發生前，這條 App Store 代裝路線也有但書：裝更新時借用的是你機器上已登入的 App Store 帳號，macOS 12 之後 Apple 放寬成不必逐一確認帳號資訊，這也是它多年來能安靜運作的原因之一。換句話說，這個工具從來不是繞過什麼付費牆，它只是把你本來就能免費重新下載的更新，換一個入口按下而已。

主畫面的長相，從官網的示意圖可以看得出輪廓：清單列出所有找到更新的 App，每筆附上現有版本與最新版本的差異，右側是該次更新的內容說明與更新按鈕。App Store 來源的更新說明抓的是商店頁上的版本資訊，Sparkle 來源則讀開發者寫進 feed 裡的更新事項，Homebrew 來源沒有說明可讀。對照前面三條資料路徑，等於你能並排看到每個 App「改了什麼」，再決定要不要裝。

Pin

Pin

偵測得到，不等於裝得動

除了 App Store 這條大斷裂，還有幾個長期限制值得放進期待管理。

Homebrew 來源的 App 只能被偵測，不能在 Latest 裡完成更新。程式碼裡對這類 App 的處理是把更新按鈕做成外部動作，按下去只是打開那個 App，實際更新還是得自己開終端機。2023 年就有人開 issue 要求把 Homebrew 更新收進來（#288，23 則留言討論至今），仍然是開著的狀態。另外這個來源不會顯示更新說明，因為 Cask 索引裡本來就沒有這個欄位。

Homebrew 版本誤報也吵過很長一段時間。前述名稱配對的模糊地帶，加上 Cask 索引記的版本和開發者實際發行的版本對不齊時，Latest 會告訴你有更新，裝完發現版本沒變。作者在 0.10.1 和 0.10.2 連續兩版修過一整輪這類問題，變更紀錄裡寫著修正大量其實已是最新版的誤報，但源頭是索引資料品質，工具端只能緩解，沒有根治。

穩定性方面，2026 年 8 月還有人反映 Sequoia 上的偶發崩潰（#600），7 月有修啟動崩潰與版本字串解析的分支還沒併入主線。功能面上沒有排程自動檢查，想查就得手動開 App（#599 是相關的功能請求，尚無時程）。另外，被標成有限支援的 App 預設不顯示在清單裡，這是 0.11 起就有的設計，設定裡可以打開；2026 年 4 月曾出現一波連打開設定也看不到的狀況（#579），後來社群定位出是 Homebrew 索引格式變動引發的問題，5 月已經復原。這些對一個業餘專案來說不算意外，但如果你打算把它當常駐工具，值得先知道。

排程、系統版本與 App Store 更新頁的差別

裝了之後會不會在背景自動檢查？現況是不會，沒有排程功能，檢查這個動作只發生在你打開 App 的時候。想要被動提醒的人要等 #599 的進度，或自己用 launchd 之類的工具排程。

哪些 macOS 版本能裝？App 本身最低要求 10.15，等於 2019 年以後的機器都行。但 App Store 應用程式的代裝功能，在 macOS 26.1、15.7.2、14.8.2 之後的系統上需要 0.12-beta2 加特權輔助程式加全磁碟權限才走得通，前文的三道關卡是版本問題，不是機器新舊問題。

它和 App Store 自己的更新頁比起來差在哪？App Store 頁面只看得到商店來源的 App；Latest 的價值在於把官網下載的 Sparkle 類軟體、Homebrew 裝的軟體一起收進同一份清單，並列版本差異。反過來說，如果你的 App 全部來自 App Store，現階段它對你的意義確實有限。

檢查派該裝，代裝派要先看系統版本

如果你的需求是「我想一眼看清整台 Mac 還有哪些 App 落後」，Latest 目前仍然是免費方案裡最乾淨的選擇之一：檢查路徑全部攤在陽光下、零遙測、有繁中介面、下載有簽章有公證，最低支援到 macOS 10.15 的老機器。從官網的示意圖看，主畫面就是一份有待更新 App 的清單加上每個 App 的版本差異與更新說明，按鈕一鍵送裝。

如果你要的是「全自動把更新裝到好」，就要看你的系統版本與 App 來源。Sparkle 類的 App 代裝沒問題；App Store 來源在新版 macOS 上，現況是穩定版裝不動、beta 版要開權限，這筆帳得自己算。Homebrew 來源則從頭到尾只有檢查。

幾種典型情境：設計師或文字工作者，機器上一堆從官網下載的付費工具，這類 App 多半用 Sparkle，Latest 的價值最高；開發者混用 Homebrew 和官網安裝，可以拿它當統一儀表板，但 brew 那半邊要自己動手；單純只用 App Store 的人，在 macOS 15.7.2、14.8.2、26.1 之後的系統上，短期內它幫你裝不了什麼。如果你平常就會固定整理 Mac 上的工具箱，例如用 IconChanger 換 App 圖示、拿 MacOptimizer 做系統維護，Latest 可以補上「版本狀態」這一塊；想替 macOS Tahoe 挑一套 Launchpad 替代品的人，也可以看看 LaunchNow 的 Launchpad 替代方案，或從 Xingshu 開源軟體清單 挑選要裝的軟體。

專案本身走的是業餘維護節奏，README 裡作者自己說得明白，這是用空閒時間寫的，更新不定期。九年累積下來有 43 種語系（繁體、簡體中文都在列）、四千多顆星，GitHub 上的問題討論區到 2026 年 9 月都還有新的問題單進來，專案活著，只是慢。官網有捐贈頁，想用行動支持開發者繼續修 App Store 那條路的人，可以從那裡進去。

授權與專案狀態

Latest 採 GPL-3.0 授權，原始碼在 GitHub（mangerlahn/Latest），可自行編譯。穩定版 0.11 於 2025 年 6 月發布，0.12 目前進行到第二個 beta（2026 年 2 月），主線最後一次更新在 2026 年 7 月。macOS 各版本的實際行為可能隨 Apple 後續調整變動，App Store 更新功能是否在之後的版本恢復，可以追 issue #514 的最新進度。