Quiver Launcher for GitHub and GitLab App Libraries

Why Quiver Launcher Exists Beyond GitHub Release Pages

Quiver Launcher addresses a specific gap between browsing a repository and using the binaries attached to its releases. GitHub and GitLab can expose many builds, but neither release page by itself gives an ordinary user a persistent, searchable desktop library organized by name, repository, folder, or custom tags. Quiver turns those release assets into installable and launchable entries managed from one application.

The project targets people who collect portable applications, desktop tools, games, or mods distributed through release pages. It also supports manually managed entries with no GitHub or GitLab repository. That matters for software whose files come from a website, archive, or another distribution channel but still benefit from a common launcher. Files can be placed in the app folder and opened from the library rather than being tied to release metadata.

Quiver began as a fork of GithubLauncher and was renamed to avoid using the GitHub trademark. The repository attributes additions such as tag filters, library management through the Quiver catalog, mod support, and interface changes to that fork history. The current README also lists Windows and Linux release packages, an Android package, and macOS support that remains work in progress. Platform maturity therefore differs even though the library model is presented consistently.

Quiver's Release Asset and Local Library Data Flow

Quiver connects library entries to release assets published by GitHub or gitlab.com. According to the README, a user can download, install, update, and launch those apps through the application. Automated release checks and in-app update checks are also listed as capabilities, but the cleaned README excerpt does not document the internal API calls, asset-selection rules, supported archive formats, or command-line behavior. It would therefore be unsafe to infer that every repository layout is compatible.

The persistent library is file based. On Windows, the README places apps.json and settings.json beside current/, alongside Apps/ and Cache/. Current/ contains app binaries and is replaced during an update. Apps/ and Cache/ are separate directories, while the catalog and other interface views organize or retrieve the installed entries. Based on the repository layout, the C# solution is divided among the desktop and Android projects, Models/, Services/, ViewModels/, Views/, Themes/, and shared application files such as App.axaml.cs. This suggests a desktop-style interface, although the README does not expose the full runtime architecture.

The App Catalog adds a network-backed discovery layer. On its first opening, and whenever the user searches, sorts, or filters, it reads catalog data through the quiverlauncher.com API. Opening an app can add it to the local library, after which the Library view and Download/Launch button handle the entry. Reviews are handled on the website rather than stored as part of the documented local workflow.

Installing Quiver Launcher and Adding a First App

Windows users should download QuiverLauncher-win-Portable.zip from Releases, extract it, and run QuiverLauncher.exe from the extracted folder. The portable directory is the operational unit. Moving it also moves apps.json, settings.json, Apps/, Cache/, and the current application files, so the directory should be kept together.

For Linux, select QuiverLauncher-linux-x64.AppImage or QuiverLauncher-linux-arm64.AppImage. The documented first run places the AppImage in its own directory, restores the executable bit, and starts Quiver Launcher:

mkdir -p ~/QuiverLauncher
mv QuiverLauncher*.AppImage ~/QuiverLauncher/
cd ~/QuiverLauncher
chmod +x QuiverLauncher*.AppImage
./QuiverLauncher*.AppImage

GitHub downloads do not preserve the executable bit for these AppImages, so chmod +x is part of installation rather than an optional refinement. If the AppImage directory cannot be written, the documented fallback is ~/.local/share/QuiverLauncher/, or $XDG_DATA_HOME/QuiverLauncher when that variable controls the data location.

After the interface opens, choose App Catalog and select an app. An internet connection is required for the catalog and its search, sort, or filter operations. Open the selected app and choose Add to library. The app should then appear in Library, where the Download/Launch button is used to obtain and start it. Users without a supported repository can instead choose + Add New Entry and select manually managed apps, place files in the app folder, and open the entry from the library.

On macOS, the README says to download the package from Releases and keep QuiverLauncher.app in a writable folder if portable data is required. It explicitly describes macOS support as work in progress, so the availability of a package should not be treated as equivalent to the documented Windows and Linux paths. Android users are directed to QuiverLauncher-android.apk.

Search, Tags, Catalog Filters, and Kiosk Restrictions

Quiver organizes installed entries with custom tags and searches the current list by name, tag, repository, or folder. This local filtering differs from App Catalog discovery. Catalog filters cover project type, platform, console, and AI use, and the catalog can also show how an app is reported to run for other players. The README calls this catalog the Quiver catalog and links it to quiverlauncher.com.

The catalog depends on the quiverlauncher.com API, whereas library files remain local. The documentation does not state whether catalog entries remain usable after their underlying service becomes unreachable, so users who depend on that feature should not assume offline catalog operation. Manually managed entries provide a separate path for apps with no GitHub or GitLab repository.

Kiosk mode is available under Settings → General → Kiosk mode. It keeps the next launch fullscreen and limits the interface to browsing and launching while hiding settings, catalog, add, update, and exit controls. Ctrl+Alt+K toggles the lock state without requiring a restart. An optional PIN is stored only as a hash and is required only for unlocking.

For a command-line cabinet shortcut, the README documents the following option:

--kiosk

It starts one locked session without changing settings.json. This is convenience control, not kiosk hardening. Quiver states that it does not block the Windows key, Alt+Tab, or Ctrl+Alt+Del. A public Windows machine may still expose the underlying session, and the README points to Windows Assigned Access, shell replacement, or a Linux Gamescope or cage session when the launcher must be the only available interface.

Library Recovery, Migration Boundaries, and Update Costs

Quiver keeps verified library snapshots in Backups/apps/ beside apps.json on Windows, Linux, macOS, and Android. The repository points to docs/library-recovery.md for restoration instructions. This is a library-level recovery facility, not evidence that downloaded application files or every setting can be restored. The documented structure separates apps.json metadata from Apps/, Cache/, current/, settings.json, and Backups/, so backing up only the JSON file would not preserve the whole portable installation.

Upgrades have a clear compatibility boundary. The in-app updater cannot migrate Quiver Launcher 2.4.x or older to version 3.0 or higher. The documented procedure is to download a fresh 3.x version, install it separately, and copy the existing library over, following MIGRATING.md. Users should preserve the entire old portable directory until they have confirmed that the new library opens correctly and that their manually added app paths remain valid.

Routine updates replace application binaries under current/. Because library data is stored beside the launcher on desktop platforms, moving an updated installation away from its original directory without moving the data can make the application appear empty. Linux has an additional write-permission consequence: if the AppImage folder is read-only, data moves to the documented user-data fallback rather than remaining portable.

The project is not archived, and the last push was on 2026-10-15. Release v3.5.1 was published on 2026-10-15 after v3.5.1-rc.3 and v3.5.1-rc.2. Those facts indicate recent development activity, but they do not establish the compatibility of every release asset with every managed app. Quiver uses the MIT license. The repository includes a separate TRADEMARKS.md file, so adopters should review both files for their intended use rather than treating the MIT label as permission to use every project name or asset.

Quiver Launcher Versus Manual Releases and Package Managers

The closest alternative is downloading each release asset manually from GitHub or GitLab and extracting it into a folder. That approach has fewer moving parts, makes every downloaded file visible to the user, and avoids dependence on Quiver's catalog API for discovery. Its cost is operational: updates, version selection, application organization, and launching become repetitive once more than a few apps are involved.

A conventional package manager is a different alternative rather than a feature-for-feature substitute. Package managers usually express dependencies and installation state through a package format and repository metadata. Quiver's documented workflow centers on release assets plus local entries in apps.json, with downloaded files managed beneath the portable installation. The README does not claim dependency resolution, system-wide package installation, or unattended repository administration, so Quiver should not be selected on the assumption that it replaces those capabilities.

Quiver is also less appropriate for managed application distribution environments where changes require centralized policy, scripted deployment, or immutable machines. Its kiosk controls simplify operator-facing use, but the README explicitly says they do not isolate the underlying operating-system session. Such environments should treat Quiver as the application interface and provide isolation through the operating system or session manager.

Editorial conclusion

Quiver Launcher is appropriate for users who routinely install release assets from GitHub or GitLab and want catalog discovery, local library management, filtering, and recovery snapshots in one interface. It is less suitable for applications that require conventional package managers, dependency resolution, or unattended system-wide deployment, none of which the README documents. Before adopting it, verify that the apps you use publish installable assets in the expected GitHub or GitLab release structure, and back up the portable directory containing apps.json, Apps/, Cache/, and Backups/ before changing versions. For installations upgraded from 2.4.x or older, use a fresh 3.x build because the in-app update cannot perform that migration.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tgeorgiadis/quiver-launcher on GitHub