動機

從兩個角度看待 AppImage：使用者與開發者。以下章節將分別說明。

為什麼使用者會想用 AppImage？

請看以下使用者情境：

「我希望在穩定的散布版上執行最愛應用程式的最新版本，但該散布版只提供舊版。」

「我需要同時使用某個應用程式的多個版本。」

「我想把喜愛的應用程式連同資料一起放在可攜式磁碟上，以便在任何 Linux 電腦上處理我的檔案。」

「我在企業或大學環境中想執行特定軟體，但沒有『安裝』應用程式的權限。」

以上情境都能透過 AppImage 達成。它是在簡單使用體驗與檔案大小之間的取捨。其獨特的使用體驗可確保即使不熟悉技術的人也能順利上手。AppImage 主要是一種以使用者為中心的軟體打包方式。

由於 AppImage 已存在一段時間，已開發出許多實用的可選功能，包含 高效率更新、所謂的 桌面整合、以及 軟體目錄 等。不過，這些都不是基本體驗所必需的。AppImage 的設計目標是:ref:最多三步就能執行 <ref-download-make-executable-run>。

一項重要優勢是 AppImage 從一開始就設計為不需超級使用者權限即可執行。幾乎所有主流散布版都相容 AppImage，且不需使用者修改基礎系統。AppImage 內建自己的執行階段，若打包得當就不需外部資源。例如在大學實驗室中，學生可將 AppImage 放在 USB 隨身碟上，於任何電腦上正常使用。

總結來說：AppImage 提供簡單且一致的使用體驗，擁有龐大的使用者基礎與生態系，並有許多工具可改善使用者體驗。

為什麼開發者會想製作並散布 AppImage？

許多開發者發現，他們能以可行的成本將應用程式部署到多數作業系統。他們可以說「我為 Windows 製作二進位檔」或「我為 macOS 製作二進位檔」。然而，對 Linux 來說，他們經常面臨無法「為 Linux 製作二進位檔」，而是必須為 Ubuntu、Debian、CentOS、openSUSE 等各別製作。也就是說，必須為每個散布版製作二進位檔。

問題在於 Linux 只是核心，而使用者實際使用的作業系統是彼此獨立的專案，有各自的目標與考量。它們提供的函式庫版本與組合各不相同，且大多要求軟體以散布版的二進位檔為依據進行連結與散布。因此，某個二進位檔要能執行，必須針對該散布版的函式庫集合 編譯。一旦換到另一個散布版，其函式庫集合不同，就可能崩潰或拒絕執行。

為解決此問題，必須像在其他平台上避免缺少共享函式庫（或版本不相容）一樣，將相依函式庫與自己的軟體二進位檔一併散布。

這可透過傳統的 tarball 來達成，裡面包含所有函式庫，並可能附帶某種「執行腳本」以確保只使用這些函式庫。但這樣有幾個重大缺點。首先，要找出必須打包的正確函式庫集合並排除會造成問題的項目（如最低層相依：libc、libdl 等）並不容易。更糟的是，使用者面對的是必須解壓的壓縮檔，還需要教他們如何執行其中的軟體。此外，這些資料會留在硬碟上，使用者必須自行管理，沒有任何輔助工具。

為了提升可用性並降低維護成本，AppImage 因而誕生。AppImage 打包了程式、其相依函式庫與執行所需的所有資源。它們是單一二進位檔，遵循「一個應用程式 = 一個檔案」的核心原則。

對開發者而言，製作 AppImage 非常簡單。有工具可從所謂的 AppDir 產生 AppImage。也有簡單工具可為既有軟體建立 AppDir，這些工具能意識到跨散布版的不相容性並嘗試避免。而一旦 AppImage 建置完成，就能在所有主流桌面散布版上「直接執行」。

停止為「散布版」製作二進位檔，從今天起開始為「Linux」製作二進位檔吧！