RepoStore: an Android app store that reads GitHub releases
Explore apps published on GitHub, view release details, and install APKs instantly — all in one place. Developed using pure Kotlin, optimized for modern Android devices.
At a glance
- What is it?
- RepoStore is a native Android application that turns GitHub releases into a Play Store style catalogue, showing only repositories whose latest release actually contains an APK asset, and letting you install, track and update them from one place. It is written in Kotlin with MVVM, MIT licensed, and the newest release is v1.0.21 from 2026-08-16.
- Who is it for?
- RepoStore fits a user of F-Droid-style open source Android software who wants a single catalogue and an update flow without a traditional store, and it fits an Android developer who publishes release APKs and wants their project discovered automatically. It does not fit a user whose apps come from the Play Store, or a developer whose releases ship as app bundles rather than APKs, because the discovery rule requires a `.apk` asset in the latest release.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 68 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A store that discovers apps by checking for an APK in the latest release
RepoStore is a GitHub-powered Android app store that discovers repositories shipping real installable APKs and lets you install, track and update them from one place, and the description in the repository calls it a native Android app that turns GitHub releases into a clean, Play Store style experience.
The discovery rule is what makes it work, and it is stricter than a keyword search. Only shows repositories that actually provide installable APK assets. Detects installed apps and shows update availability. Always installs from the latest published release with changelog. And presents a polished details screen with stats, README and developer info.
The mechanics are described step by step in the readme. The app uses GitHub's `/search/repositories` endpoint with Android-focused queries, applies scoring based on topics, language and description, and filters out archived repos. For each candidate it calls `/repos/{owner}/{repo}/releases/latest` and checks the `assets` array for `.apk` files, excluding the repo from results if none is found. So the filtering is not a heuristic over a title or a description, it is an actual asset check against the release API.
The consequence for a developer is direct, and the readme spells out the four conditions. The repository must be public. It must have at least one published release created via GitHub Releases rather than only tags, and the latest release must not be a draft or a prerelease. The latest release must contain at least one `.apk` file, with GitHub's auto-generated source artifacts ignored. And the project must be discoverable by search or topics, where topics like `android`, `mobile` and `apk` help the ranking and having stars makes a project more likely to appear in the sections.
No private indexing and no manual curation is involved, and if a repo meets the conditions RepoStore can find it through search and show it automatically with no manual submission required.
Four sections, one install action, and a local database of what you have
The feature list is organised around the lifecycle of an app rather than around screens, and reading it top to bottom is the clearest picture of what the app does.
Smart discovery gives home sections for Trending, Recently Updated and Featured projects, shows only repos with valid APK assets, and offers category-based filtering for apps.
Latest-release installs fetches `/releases/latest` for each repo, shows only assets from the latest release, and gives a single Install action with download progress. That last point matters: the user is not choosing among assets, the app takes the latest release's APK.
The rich details screen shows the app name, version and Install button, the stars, forks and language stats, the rendered README content as an About this app section, the latest release notes with markdown formatting, and a screenshot gallery with a fullscreen viewer. The screenshots are detected from the repository contents, which is a nice touch, since a project that keeps its screenshots in the repo gets them for free.
Install and update tracking opens APK downloads with the package installer, tracks installations and shows an Open button for installed apps, and detects when updates are available. The tracking is in a local database, so the Open button appears for apps you have installed through RepoStore even if the repository is later deleted.
On appearance, it is Material 3 with Material You support, dark mode with system theme support, and a Play Store inspired interface.
On GitHub integration, sign-in is optional and uses the OAuth device flow, and the payoff is stated: it increases the API rate limit from 60 to 5,000 requests per hour. That is a large difference for an app that queries the search API across several sections, and it is also the reason the rate limit appears in the feature list at all. Signed-in users can also view developer profiles and repositories.
The Support Developer feature is a UPI payment integration with a QR code, which detects installed UPI apps such as GPay, PhonePe and Paytm, with one-tap payment support.
Three distribution channels, none of them the Play Store
The download section shows three channels, and the presence of all three is the point.
There is F-Droid, with the package at `com.samyak.repostore` and a Telegram channel linked in the readme. There is IzzyOnDroid, the same package name. And there is the GitHub releases page, pointing at the latest release.
None of them is the Play Store, and the readme explains why with a caution notice: Free and Open-Source Android is under threat, Google will turn Android into a locked-down platform, restricting your essential freedom to install apps of your choice, and it asks readers to make their voice heard through keepandroidopen.org.
That framing is not decoration, it is the design constraint. An app store that indexes GitHub releases, installs APKs directly and has an F-Droid listing exists because sideloading outside the Play Store is a practice the project wants to be easy, and RepoStore is one more step in making it comfortable.
It also means the app is useful to exactly the audience that has already decided that open source Android software is worth the extra install friction. For a user whose apps all come from the Play Store, the catalogue is a niche of a niche.
The tech stack section names the platform floor. The minimum Android SDK is 26, which is Android 8.0. The language is Kotlin with Coroutines and Flow, the platform is Android Native with ViewBinding, and the architecture is MVVM. The badges in the readme confirm Kotlin 1.9, Material 3 and MVVM, and the CodeFactor badge suggests the project is tracked by an automated code quality service.
The repository layout matches an Android Studio project, with `app/` for the application module, `GitCore/` as a separate module, `fastlane/` for release automation, `build.gradle.kts` and `settings.gradle.kts` for the Gradle setup with the `gradlew` wrapper, `screenshots/` for the store images, and a `test_icon_resolver.kt` at the root.
Why the latest-release rule is both the feature and the limitation
The decision to always install from the latest release is the one design choice that explains the rest of the behaviour, and it has costs that the readme does not soften.
The benefit is that there is no version picker. The user taps Install and gets the newest published build, with the changelog shown alongside. For an open source app that is usually what you want, because the newest release is the one with the fixes.
The cost is that a release with a problem takes everyone at once, and there is no way to install an older build through the app. The `assets` array of a release can contain several files, and RepoStore shows only the assets from the latest release, and it takes the APK from there. For a project that publishes multiple APK variants per release, for example one per architecture, the app has to pick one, and the readme does not describe how.
The second cost is the exclusion of prereleases and drafts. The discovery conditions require the latest release to not be a draft or a prerelease, which keeps broken builds out of the catalogue, and it also means a project that ships only betas never appears at all.
The third is the APK-only requirement. The latest release must contain at least one `.apk` file. A project that ships Android App Bundles exclusively, which is what the Play Store requires, is invisible to this catalogue. For an open source project that wants both, shipping an APK alongside the bundle is the price of appearing.
The fourth is the dependency on the release API being consistent. Everything hinges on `/repos/{owner}/{repo}/releases/latest` returning a predictable `assets` array, and the rule that GitHub's auto-generated source artifacts are ignored is a special case that shows the author has had to handle the noise.
Where RepoStore is the wrong tool
The first case is a user whose software comes from the Play Store. There is no catalogue of commercial apps here, no Play Protect, no Play billing and no Play Store update cycle. If your apps are on Google Play, this app adds nothing.
The second case is a developer who wants reach rather than distribution. The discovery mechanism is the public GitHub Search API, and the readme says plainly that topics like `android`, `mobile` and `apk` help ranking and that having stars makes a project more likely to appear in sections. So a popular project in a crowded topic outranks an obscure one, and the trending and featured sections are populated by the same signal. If you want people to find your app, the discovery path is GitHub popularity, and that is a different strategy from listing on a store.
The third case is a project that ships only app bundles, as noted above. That is the majority of new Android applications, and the condition is not negotiable within this catalogue.
The fourth is a security-conscious organisation. The app installs APKs downloaded from GitHub release URLs, outside the Play Store's verification. The readme's caution notice is about platform freedom rather than about install risk, and the app is not making any claim about verifying the source of the APKs it finds, and the code path is a plain download handed to the system package installer. For a device fleet under a device management policy that requires Play Store distribution, this app is not deployable regardless of how good it is.
There is also a small but real limit to the Open button. It appears for apps the app has tracked as installed, and the tracking is in a local database, so an app installed outside RepoStore does not get an Open button, and an app installed on a different device does not either. The feature is a record of what RepoStore did, not a general package manager.
Editorial conclusion
RepoStore fits a user of F-Droid-style open source Android software who wants a single catalogue and an update flow without a traditional store, and it fits an Android developer who publishes release APKs and wants their project discovered automatically. It does not fit a user whose apps come from the Play Store, or a developer whose releases ship as app bundles rather than APKs, because the discovery rule requires a `.apk` asset in the latest release. Before you publish an app hoping to appear in it, read the four discovery conditions in the readme, and note that the app is distributed on F-Droid, IzzyOnDroid and GitHub releases, so you can install it without a Google account.
Frequently asked questions
How does RepoStore decide which apps to show?
It uses GitHub's `/search/repositories` endpoint with Android-focused queries, scores by topics, language and description, filters out archived repos, then calls `/repos/{owner}/{repo}/releases/latest` and keeps only repos whose latest release contains a `.apk` asset. There is no manual curation or private index.
What are the conditions for my project to appear in RepoStore?
The repository must be public, have at least one published release created via GitHub Releases rather than only tags, the latest release must not be a draft or prerelease, and it must contain at least one `.apk` file. Topics like `android`, `mobile` and `apk` help it rank in search, and having stars makes it more likely to appear in the sections.
Where can I get RepoStore?
It is on F-Droid and IzzyOnDroid under the package name `com.samyak.repostore`, and the GitHub releases page carries the latest build. It is not on the Play Store, and the readme links the keepandroidopen.org campaign about platform restrictions on installing apps of your choice.
What does signing in with GitHub change in RepoStore?
Sign-in is optional and uses the OAuth device flow. The stated benefit is a higher API rate limit, from 60 to 5,000 requests per hour, and it also lets you view developer profiles and repositories.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/samyak2403-repostore)Was this useful?