Orion Store

A transparent app store built around public releases, inspectable metadata, and automation you can actually follow.

Sources Supported

Overview 🌌

Orion Store is an Android-first store client that leans on public sources instead of hiding everything behind a private service layer. The app pulls catalog data from public JSON, resolves releases from GitHub, GitLab, and Codeberg, and keeps the delivery path understandable enough that users can see where things come from and how updates are discovered.

This repository is the client application itself. The live catalog, configuration, notices, and release metadata used by the app are maintained separately in RookieEnough/Orion-Data, which keeps the UI and the store data cleanly separated.

Orion is built for people who care where software comes from, not just how quickly it downloads.

At a glance:

• Public JSON catalog with inspectable configuration
• Multi-source releases (GitHub, GitLab, Codeberg)
• Android-native install, update, and security tooling

What makes Orion different ✨

The point of Orion is not to pretend infrastructure does not exist. It is to reduce hidden infrastructure and move as much of the important behavior as possible into public, inspectable layers. Catalog entries are plain data. Release sources stay visible. Automation is handled through workflows and workers that can be reviewed, rather than through a black-box backend that users have to trust on faith.

That design carries through the app. Orion tracks installed packages, surfaces updates, manages download state, supports install flows on Android, and exposes developer-facing diagnostics for people who want to see what the store is actually doing under the hood.

Feature atlas 🚀

Rather than treating Orion like a download button with a search bar, the app is built as a complete release-aware client. The best way to explain it is to show the major capabilities as systems, not as a long checklist.

Release intelligence Orion reads public metadata, resolves upstream releases, and keeps source provenance visible instead of burying it behind a store-owned backend. Public JSON Mirrors Multi-source parsing	Update center Installed packages are tracked locally, update availability is surfaced clearly, and queued downloads stay organized instead of disappearing into the background. Installed version checks Queue state Ready-to-install
Native install flow Orion is not limited to web-only behavior. On Android it can hand off installs natively and support faster one-tap workflows through Shizuku for users who want that path. Capacitor bridge Install handoff Shizuku option	Sentinel security Security tooling is built into the product rather than stapled on as an afterthought, with rapid scans, deeper file analysis, and signature-driven checks for risky packages and APKs. Rapid scan Deep scan Threat shards
Power tools Beyond installation, Orion includes utility workflows for APK extraction, package inspection, and system app controls for users who need more than a simple storefront. APK extraction Package detective System app tools	Developer visibility Orion exposes the guts of the system when needed: mirror source, cache state, GitHub API quota, source switching, and debugging surfaces that make failures easier to understand. Developer mode Diagnostics Metadata inspection

Source support 📡

Orion treats multiple upstream platforms as first-class citizens, which matters because app distribution should not depend on a single forge being the only path worth supporting.

• GitHub is the primary release path and the center of most automation.
• GitLab is supported for repository metadata and raw release sourcing.
• Codeberg is supported as a real upstream, not a decorative fallback.

Screenshots / UI preview 🖼️

The app leans into a compact, card-driven interface with a dark shell, loud accents, and clear state changes for downloads, updates, and tools. Here is the actual gallery from the project assets:

How the project is structured 🧭

The application is built with React, TypeScript, Vite, Tailwind CSS, and Capacitor 7. The main app shell lives in App.tsx, the UI is split across components/, persistent client state is managed in store/, Android-native functionality is bridged through plugins/AppTracker.ts, and heavier background work is pushed into workers/ for release aggregation, relay logic, image handling, and Sentinel support.

The repository also includes a bundled apps.json fallback so the client can still run with local data when needed. In normal operation, though, Orion is designed to consume public remote data and public release metadata rather than rely on a private API server.

Area	Responsibility
App.tsx	Application shell, data loading, update orchestration, and navigation
components/	Storefront UI, app detail flows, settings, modal surfaces, and submission screens
store/	Zustand state for settings, downloads, installs, persistence, and local identity
plugins/	Android-native bridge for package inspection, downloads, installation, scanning, and file actions
workers/	Release resolution, Sentinel logic, relay workflows, image handling, and delta aggregation

Local development 🛠️

For day-to-day UI work, the web build is enough:

npm install
npm run dev

If you want a production build or a quick type check, use:

npm run build
npm run lint

Android-specific features such as package detection, native downloads, installation handoff, Shizuku integration, and most of the security tooling depend on the Capacitor plugin and only work in the Android shell. To run that version, build the web assets and sync the native project:

npm run build
npx cap sync android

After that, open android/ in Android Studio and run the app on a device.

Data, workers, and automation 🤖

Orion is best understood as backend-light rather than backend-free. The catalog and remote configuration are public, but the project still uses a few narrow pieces of infrastructure where they make sense. This repo includes Cloudflare worker code for things like leaderboard relay, image proxying, delta aggregation, submission handling, and Sentinel support. The automation story continues in .github/workflows/, where mirrors, submissions, leaderboard processing, deployment, and threat updates are handled through GitHub Actions.

That split is intentional. The app stays focused on the client, while the data and automation layers remain separately inspectable.

Contributing 🤝

Contributions are welcome, especially in the areas that matter most to a store client: installer reliability, release resolution, UI polish, Android behavior, security tooling, and documentation. If you are changing catalog entries or store metadata, that work usually belongs in the data repository or the submission flow rather than in this client codebase.

If you want to understand the moving parts before opening a change, start with App.tsx, plugins/AppTracker.ts, workers/core.worker.ts, and the workflow files under .github/workflows/. That path gives a good overview of how the store loads data, resolves releases, and automates maintenance.

Community 💬

The project lives across a few public surfaces:

• Orion-Data: github.com/RookieEnough/Orion-Data
• Discord: discord.com/invite/CrM6y4ujnq
• Buy Me a Coffee: buymeacoffee.com/rookiez

---

Made with 💜 by RookieZ