TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Platypus 實測：把命令列腳本包成原生 Mac App，先看清分發成本
Platypus 從 2003 年維護至今，把 shell、Python 等命令列腳本包成可雙擊的原生 macOS App，生成物僅數百 KB。本文實際下載驗簽、用內建命令列工具生成測試 App，整理它的公證狀態、Homebrew cask 排定停用的時程，以及把未簽署 App 交給同事時對方要手動放行的 Gatekeeper 成本。
用 AI 摘要這篇文章：
把兩行 shell 腳本變成一個可以雙擊的 Mac App，要花多少功夫？我用 Platypus 5.5.0 實際跑了一次：生成物只有 236KB，點下去就會執行，速度快得像個原生小工具。但同一個 App 拿到 Gatekeeper 面前評估，結果是直接拒絕，理由寫著「沒有可用的簽署」。這就是 Platypus 今天最真實的樣貌：把腳本包成 App 這件事，它做了二十幾年而且做得很好；真正要算清楚的，是你把 App 交出去那一刻會遇到什麼。
Platypus 是冰島開發者 Sveinbjörn Þórðarson 從 2003 年維護至今的開源工具，BSD 授權，GitHub 上有 3,438 顆星。它的用途一句話講完：把命令列腳本包進一個正規的 macOS 應用程式包（.app），讓不想碰終端機的人也能用你寫的東西。shell、Python、Perl、Ruby、PHP、Swift、AppleScript 都行，包出來的 App 可以是進度條、文字視窗、選單列常駐、拖放接收器，或用 WebKit 顯示輸出的 HTML 版面。
先驗三關，再包一個 HelloTest
先驗下載包本身。從官方網站抓回 3.5MB 的 platypus.zip 後，依序跑 codesign、xcrun stapler validate、spctl 三個檢查。簽署是有效的：Developer ID Application: Sveinbjorn Thardarson（團隊代碼 5WX26Y89JP），時間戳 2025 年 12 月 2 日，啟用硬化執行時期，Intel 與 ARM 雙架構通用。但公證那關有狀況：app 內沒有釘選的公證票（stapler 回報 does not have a ticket stapled），spctl 的評估結果是 accepted，來源標示 Developer ID，而不是完整的 Notarized Developer ID。兩種標示差一個字，在別台機器上可能就是「直接打開」與「Apple 無法驗證」的差別。
再來是實際生成一個 App。Platypus 內建命令列工具（放在 App 的 Resources 裡，也有圖形介面選單可以安裝到系統路徑），我把一段印出問候與日期的 shell 腳本餵給它，指定文字視窗介面，幾秒鐘就產出 HelloTest.app。過程中它逐行印出正在做什麼：建立套件資料夾結構、複製執行檔、複製介面資源、複製腳本、寫入 AppSettings.plist、寫入 Info.plist、向 Launch Services 註冊。後面所有關於生成物的觀察，都來自這個自己包出來的成品。
有個細節順帶一提：命令列工具預設去系統安裝路徑找 ScriptExec 執行檔，沒裝過就會報錯。解法是把 App 裡隨附的 ScriptExec.b64（開發者把這支執行檔用 base64 編碼後塞在資源目錄）解碼還原，再用參數指給它。這個安排側面解釋了後面會講到的公證風波：一支沒有簽署的二進位檔以資料檔形態藏在 App 裡，正是 Apple 自動檢查管線敏感的東西。
236KB 的成品長什麼樣子
打開 HelloTest.app 的套件內容，裡面只有五個檔案：Info.plist、執行檔 HelloTest、AppSettings.plist、介面資源 MainMenu.nib，還有一個叫 script 的檔案。那個 script，就是我原本寫的 shell 腳本，一個字都沒動，明文放在裡面。
AppSettings.plist 是整個機制的線索。內容記著產生器版本（Platypus-5.5.0）、介面類型（Text Window）、直譯器路徑（/bin/sh）、字型（Monaco 13）、要不要接受拖放檔案等等。換句話說，包裝殼不知道你的腳本在幹嘛，它只負責按設定把腳本跑起來、把輸出畫在視窗裡。
生成物的輕巧是真的：整個 App 236KB，因為它沒有編譯任何東西，只是把一個小執行檔、你的腳本和幾份設定資源綁在一起。啟動也快，雙擊後視窗立刻出現，腳本輸出直接印在上面。
但簽署狀態就不好看了。codesign 顯示這個 App 只有 adhoc、linker-signed 等級的簽署，沒有團隊代碼，資源未封印。spctl 的評估毫不留情：rejected，來源是「沒有可用的簽署」。意思很直白：這個 App 在你自己機器上跑沒問題，可是拷貝到同事的 Mac 上，只要經過會加隔離標記的傳輸方式（AirDrop、雲端硬碟、通訊軟體下載都算），第一次打開就會被 Gatekeeper 攔下來，對方要到系統設定的隱私權與安全性裡找到「強制打開」的選項手動放行。
幾種介面型態各自的用途，從官方隨附的範例就能看出來。下載包裡帶了十幾個現成的範例設定檔：ImageResizer 把圖片拖到 App 圖示上就批次縮圖（拖放模式，檔案路徑自動變成腳本參數）；ProcessMenu 在選單列常駐顯示目前程序列表；FastDMGMounter 掛載磁碟映像檔；SpeakDroplet 把拖進來的文字唸出來；AdminPrivilegesDemo 示範怎麼以管理者權限跑腳本。這些範例本身就是現成的說明書，打開來看設定就知道每種介面適合什麼任務。
官方主視窗的設計也是同一個思路：選腳本、選直譯器、選介面類型，按下 Create 就產出 App，沒有專案檔或建置流程的概念。
官網還寫著 notarized，票呢
這輪實測最反常的發現在這裡。官方網站與 GitHub README 到現在都寫著下載包是「Developer ID signed and notarized」，但我手上的實測結果是簽署有效、公證票缺席。官網宣稱與實際狀態對不上。
原因在 GitHub issue #291 有開發者本人的說法。有使用者回報 5.5.0 裝不起來，跳出「Apple 無法確認 Platypus 是否不含惡意軟體」的警告，開發者自己在 2025 年 12 月 28 日回覆：他明明完成了公證這道麻煩手續，Apple 卻在某個時間點把公證撤銷了；他猜測原因是 app 裡以資料檔形式附帶的 ScriptExec 執行檔沒有簽署，被 Apple 的後處理管線抓到，但他也明說這只是猜測。他給使用者的建議是：確認軟體沒問題的話，到隱私權與安全性手動放行，或者直接從原始碼自己建置。
這段說明有兩個重點。撤銷原因只是開發者的推測，修復也沒有給出時程；repo 的 master 分支在 2026 年 3 月已把版本號推進到 5.6.0 但遲遲沒有正式發佈，狀況何時翻轉沒人保證。至於一般使用者的實際體驗，我的 spctl 評估是 accepted，代表攔截與否取決於每台機器怎麼取得公證紀錄。把它讀成「狀態不一致」的麻煩就好，別往「軟體有問題」的方向想。
包裝原理決定了它的輕，也決定了它的未簽署
從成品反推，Platypus 的做法是「包裝」而不是「編譯」。每個生成的 App 裡真正在跑的，是一支叫 ScriptExec 的小執行檔（原始碼公開在 repo 裡），它讀 AppSettings.plist 得知該用哪個直譯器、呈現哪種介面，然後執行放在 Resources 裡的腳本，把輸出接到視窗、進度條或選單列上。
好處很直接：生成物永遠輕巧，腳本改了重包一次就好，二十幾年來這套模式沒有複雜化，也難怪它能在不需要建置工具鏈的前提下活這麼久。代價的那面：每次生成都是一個全新的、未簽署的應用程式，在預設未簽署的狀態下，Gatekeeper 對它的態度是先攔再說。官方文件的常見問題也直接承認這點：Platypus 生成的 App 預設不簽署，要消除警告，你得用自己的簽署身分跑 codesign -s "your-signing-identity"。要做到別台機器完全無感安裝，後面還有公證這道手續，走的是 Apple 開發者方案的年費制度。
另外兩個官方明載、卻容易在「腳本變 App」的想像中被忽略的邊界：生成的 App 沒有標準輸入管道，不能跟使用者互動，sudo 這種要敲密碼的指令、Python 的 input() 都不會有反應，官方明言可預見的未來都不打算支援，要傳資料給腳本得靠參數、設定檔，或讓 App 以拖放模式接收檔案（丟進來的路徑會自動變成腳本參數）；還有 App 要求 macOS 11 以上（我實測下載包的最低系統版本是 11.5），更舊的機器只能回頭找 5.3 或 4.9 這些舊版。
現在要裝，三條路線的狀態不同
| 取得方式 | 版本 | 2026 年 8 月實測狀態 | 適合誰 |
|---|---|---|---|
| 官網直接下載 zip | 5.5.0 | Developer ID 簽署有效，公證票缺席 | 大多數人，遇到攔截手動放行 |
| Homebrew cask | 5.5.0 | 已列棄用（原因：未通過 Gatekeeper 檢查），排定 2026 年 9 月 1 日停用 | 短期還能用，之後要換路線 |
| 社群 tap（DilumAluthge/homebrew-tap） | 依維護者更新 | 使用者自行復活的 formula，非官方維護 | 堅持用 brew 管理的人 |
Homebrew 那條路的來龍去脈值得知道。homebrew-core 裡的 formula 曾在 2023 年 10 月被以「上游未維護」為由停用，後來整個被移出 core，當時是因為 5.4.1 之後將近三年沒有新版；cask 這邊則是在 2025 年 9 月、版本還停在 5.4.1 時，就因為下載包沒通過 Gatekeeper 檢查被標記停用（2026 年 9 月 1 日生效），三個月後 5.5.0 出爐，版本跟著更新，停用標記沒有拿掉。開發者對 Homebrew 的態度很坦然：他自己不想維護 formula，歡迎社群接手，後來真的有使用者在自己的 tap 裡復活了它。這也是判斷這類老牌個人專案時的常見結構：工具本身活著，週邊的自動化管道未必跟得上。
就指令而言，三條路分別是：官網抓 zip 解壓後拖進應用程式資料夾；brew install --cask platypus 目前還裝得動，只是會先噴一段棄用警告；堅持用 brew 管理的人可以改加社群 tap 再安裝。另外 Platypus 自己內建了 Sparkle 更新框架，等 5.6.0 正式發佈時，從 App 內選檢查更新有機會直接把公證狀態一併翻新，屆時安裝建議可能跟著改版，裝之前先看一眼 App 內的檢查更新。
四個會改變你決定的限制
互動輸入不支援，是硬邊界。你的腳本若需要中途回答問題、輸密碼，改成參數帶入或設定檔再包，不要指望 App 跳出輸入框。
分發成本要事先算。交給同事的每一個 Platypus App，對方第一次打開多半要走一遍手動放行；你之後改了腳本重包，新 App 又是一個新的未簽署程式，放行要再來一次。有自己開發者身分的人可以簽署加公證解決，但那就是每年固定的費用與流程。反過來說，如果這個 App 只在你自己或少數幾台機器上用，這些成本全部不存在。
腳本是明文的。收到你 App 的任何人，右鍵顯示套件內容就能讀到完整邏輯。對內部工具來說這是優點，出包時誰都能稽核；想藏商業邏輯的人選錯工具了。
維護是單人編制。發版節奏看歷史就知道這不是跑得快的專案：5.3 是 2018 年，5.4 相隔四年到 2022 年，5.5 又隔三年到 2025 年 12 月。但每次回來都是真的回來，master 分支到 2026 年 4 月底還有修 bug 的提交，開發者在 README 裡也坦然寫著這套程式是他 2003 年剛學 Objective-C 時寫的，「換他今天來寫不會長這樣」。經費模式是純捐款，GitHub 上 5.4.1 的安裝包累積了破萬次下載，5.5.0 到 2026 年 8 月約四千九百次。優點是方向一致、沒有商業模式介入，BSD 授權隨你改造；風險是 issue 只有一個人消化，回應速度看緣分，遇到急件得自己下場。同樣把終端機工作包成視窗工具的還有 DFU-Tools，那篇的情況剛好相反：工具年輕、授權狀態不明，兩篇對照著看更有感覺。
自己用、交給同事、發給大眾：界線先分清楚
自己用、或在一群願意配合的少數機器上用：直接從官網下載，這工具值得。包裝可靠、成品輕、BSD 授權沒有後顧之憂，遇到 Gatekeeper 攔截就照開發者說的手動放行一次。想先確認它合不合用，成本很低：裝好後別急著包自己的腳本，先打開隨附的 ImageResizer 範例跑一輪，看看拖放、執行、輸出整條路是不是你要的感覺，五分鐘就有答案。
要交給非技術同事常態使用：先想清楚更新節奏。如果腳本會常常改，每次同事都要再放行一次，這個摩擦可能比教對方開終端機還貴；要嘛申請自己的開發者身分把簽署公證做滿，要嘛把「常駐需求」交給真正的一般使用者工具。Mac 上其他開源小工具的取捨可以參考 FineTune 或 AppPorts 的例子。
要散佈給不特定大眾：這不是 Platypus 的戰場。它是開發者之間分享腳本的橋樑，原料假設是「你寫的腳本」，面對大眾的軟體該走正規的開發與簽署流程。
判斷標準很簡單：包好的 App 拿到目標機器上，第一次打開的體驗你能不能接受。能接受，Platypus 就是這個需求裡最省事的老字號；不能接受，卡住你的是你還沒決定要為自行簽署付出多少代價。若你想先感受命令列腳本在 Mac 上能玩出什麼花樣，這篇啟動碟教學是個不錯的起點；想看另一種「原始碼攤開驗」的開源工具案例，FlowScroll 聊的是同樣的信任問題。
