Orion Store: a serverless Android app store built on public JSON and GitHub releases

The problem Orion Store actually addresses

Installing an Android app that is not on Google Play usually means opening a GitHub releases page, picking the right asset, checking whether the file matches the package you already have, and repeating that every time an update lands. The README frames the project as a reaction to that: "Orion is built for people who care where software comes from, not just how quickly it downloads." The stated goal is a store client that keeps the delivery path visible rather than hiding it behind a private service layer.

The audience is narrower than a general app store. Orion Store is Android-first, and the README lists Android-native install, update and security tooling as a core capability. The catalog is maintained in a separate repository, RookieEnough/Orion-Data, which holds the live catalog, configuration, notices and release metadata. That split matters: the client repository you are reading contains no app listings, so anyone evaluating the project has to look at two repositories, not one.

How the client resolves a package: public JSON plus upstream release APIs

The architecture is a static front end with no store-owned backend. According to the README, the app pulls catalog data from public JSON, resolves releases from GitHub, GitLab and Codeberg, and keeps source provenance visible. The repository layout is consistent with that: the top level holds App.tsx, index.tsx, components/, hooks/, store/, utils/ and workers/, which is a Vite React application, alongside android/, capacitor.config.ts and plugins/ for the native shell.

Two directories are worth noting for anyone auditing the flow. workers/ suggests background work runs in web workers rather than on the main thread, which fits a client that queues downloads. scripts/ and .github/scripts/apk_hunter.js back the mirror script declared in package.json, so the mirroring step is a Node script you can read rather than a service you have to trust. State is handled with zustand, and idb-keyval is a dependency, which points to IndexedDB as the local persistence layer for installed-package tracking and queue state. The README does not document the JSON schema of the catalog, so the field names are only discoverable from Orion-Data.

Installing Orion Store on Android and running your first update check

The README does not give an install command for end users; the project's releases page is where the APK lives, and the homepage at rookieenough.github.io/Orion-Docs is the documentation entry point. What the repository does document precisely is the build path, because package.json carries the scripts.

To build the web bundle locally, clone the repository and run the build script. The build script runs the TypeScript compiler first, so a type error stops the bundle:

npm install
npm run build

For a live development server with hot reload, the dev script wraps Vite:

npm run dev

To produce the Android shell, the Capacitor CLI is a devDependency, and android/ is already committed. The typical sequence after a build is to copy the web assets into the native project and open it in Android Studio:

npx cap sync android
npx cap open android

The repository also ships a lint script that is just the TypeScript compiler in check-only mode, and a test script that runs Vitest once:

npm run lint
npm test

The mirror script is separate and is invoked directly:

npm run mirror

After the first launch, the app tracks installed packages locally and surfaces update availability. The README describes an update center with installed version checks, queue state and a ready-to-install state, and it mentions an optional Shizuku path for faster one-tap installs through the Capacitor bridge.

Where Orion Store is the wrong tool

The most concrete limitation is platform coverage. The README calls Orion Store an Android-first client, and the repository contains an android/ directory with no iOS counterpart. Anyone searching for Orion Store on a PC or an iPhone will not find a first-party build here, and the project does not claim one.

The second limitation is trust. The README's own framing is transparency, not curation: catalog entries are plain data, and releases are resolved from upstream sources. That means the safety of any given package depends on the upstream repository, not on a review process inside Orion Store. There is no mention of signature verification, malware scanning or a submission review in the README, so a user who wants a vetted catalog is looking at the wrong project.

Third, the split between client and data is a real operational dependency. The app is useless without RookieEnough/Orion-Data, and the README does not document what happens when that repository is unreachable or a catalog entry points at a deleted release. The README also does not document rollback behaviour for a failed install, so that path is unverified from the repository alone.

Orion Store compared with Obtainium and F-Droid

Obtainium solves an overlapping problem from the opposite direction. It tracks apps you already have by their upstream release pages and checks those pages for new versions; you add each app yourself. Orion Store instead presents a curated catalog maintained in Orion-Data, so discovery is built in, but the catalog is only as current as that separate repository. If you want to follow an app that nobody has added to the catalog, Obtainium is the more direct tool.

F-Droid differs at the packaging layer. It builds applications from source on its own infrastructure and signs the results with its own key, which is why its catalog is narrower and its build times are longer. Orion Store redistributes or points at upstream release artifacts, which is why it can carry apps F-Droid will not build, and also why it cannot make the same guarantee about what is inside them. The README's phrase for this is "inspectable metadata": you are expected to inspect, not to assume.

Licence and the cost of keeping the client current

Orion Store is licensed under GPL-3.0, and the LICENSE file sits at the repository root. For anyone forking the client, that means derivative distributions of the app must carry the same licence and source availability terms. The catalog in Orion-Data is a separate repository with its own terms, so the licence of the client does not automatically describe the data it renders. This is a description of the files, not legal advice; read both repositories' licence files before redistributing anything.

The maintenance picture is active: the last push was on 2026-09-08, and the most recent release, 1.4.0 ("The Obsidian Update"), carries the same date. Two earlier releases, 1.3.6 on 2026-08-17 and 1.3.5 on 2026-07-21, show a release cadence of roughly monthly point updates. The upgrade cost for a self-builder is low, because the toolchain is standard Vite plus Capacitor, but the dependency list includes capacitor-unity-ads pinned to "latest", which means a fresh npm install can pull a different version than the last build did. That is the one dependency worth pinning in a fork.

Editorial conclusion

Orion Store fits Android users who already install apps from GitHub releases and want a catalog that shows where each package comes from, and developers who want a Vite and Capacitor client they can read end to end. It does not fit iOS users, desktop users, or anyone who wants a signed store with a review process, because the repository ships no iOS target and no desktop build. Before adopting it, open RookieEnough/Orion-Data and confirm the catalog entries you care about are still maintained there, since the client depends on that separate repository for its data.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. RookieEnough/Orion-Store on GitHub