uni-apks publishes prebuilt patched Android apps and the fingerprint to check them

A release pipeline rather than a source project

The description of this repository is short: pre-built APKs from various patch sources. That is the whole product, and understanding it as a release service rather than a library changes how you should evaluate it.

What the repository contains is a build system. The top level entries include main.py, a src/ directory, a bin/ directory, a config.toml, a pyproject.toml, a uv.lock, a .python-version file, a sig.txt file, a morphe.keystore file, an icons/ directory with its own README, a CONTRIBUTING.md, an AUTHORS file and a LICENSE. The build badge in the README points at a GitHub Actions workflow, and the README states that everything happens through public GitHub Actions to ensure security and transparency, and that for maximum security you can always build the applications yourself using the provided source code or official methods.

That is the design rationale of the whole project. Anyone can read the build code, watch the automated build run, and reproduce the output. The convenience is that you do not have to.

The build code is described as a complete Python rewrite, based on an adaptation first implemented by j-hc, and the README credits that work explicitly. The Python side is light. The pyproject.toml lists exactly two runtime dependencies, beautifulsoup4 at 4.15.0 or later and curl-cffi at 0.16.3 or later, which suggests the build code parses patch sources over the network rather than doing anything heavy locally. The project requires Python 3.13 or later, and both ruff and pyright are configured against that target, with pyright in strict mode over src and main.py.

The version in pyproject.toml is 0.0.0, which is a placeholder rather than a released version. The meaningful version numbers live in the release tags, which carry a date and a patch source, for example 26.10.11-morphe and 26.10.10-piko.

Two patch sources and six apps between them

The apps are organised by the patch source that produced them, and the README links each source to its own repository.

The Morphe group covers YouTube, YouTube Music and Reddit. The Piko group covers X, Twitter and Instagram. The Piko entry shows two separate Obtainium configurations for X, one under X branding and one under Twitter branding, which suggests the two clients are separate packages built from the same source with different branding applied.

Each app in the table links to its Play Store listing, so the app identity and package name are visible, and each has one or two Obtainium import configuration badges, with some marked as experimental. The release pages are filtered by tag suffix, so the Morphe releases and the Piko releases are listed separately.

What the patches are meant to do is described in the features list: ad blocking, which the README says blocks all types of ads, enhanced features that squeeze more out of the app, customization, optimization for performance and size, persistence, meaning the patched app will not be updated or overwritten by the Play Store, and automatic updates through Obtainium using individual configs.

That list describes a class of software that is worth naming plainly. These are modified copies of applications that other companies distribute and that carry their own terms of use. The patches are not licensed to you by the app vendors, and the project is explicit that it is not affiliated with the patch creators and is intended for educational and personal use only. The disclaimer is the part of the README to read before anything else.

One SHA-256 fingerprint for every official release

The repository addresses the obvious objection to a binary distribution channel, which is that you cannot tell what you downloaded. The answer is certificate fingerprint verification, and the mechanism is simple: all official releases are signed with the same key, so the certificate fingerprint is a constant.

The README gives the value:

1894fee4df44d1823f3666db4743566d043dd72cbc13566433c1908270a4be10

To check a downloaded APK, you compare its signing certificate fingerprint against that value. If it matches, the file was signed by the same key this project uses, which means it came from a build this project made rather than from someone repackaging and re-signing it.

The signing key itself is in the repository, as morphe.keystore, and the sig.txt file at the root is presumably the signature material that goes with it. That is worth thinking about for a second, because it means the trust model is: the keystore is public, so the fingerprint proves the file is unmodified relative to a build from this key, but it does not prove the build was benign. Anyone with the keystore can produce an APK with the same fingerprint.

In practice the fingerprint does what it is meant to do. It ties the file to a specific publisher and lets you detect a third party re-sign, which is the common failure mode for prebuilt APKs from unknown sources. It is not a proof of what the code does, and the README does not claim it is.

Obtainium configs are the replacement for store updates

The persistence and auto-update features are two halves of one design decision, and it is the most consequential one in the repository.

A patched app installed by hand carries a signature that differs from the Play Store version. Android will therefore refuse to update it in place, and any attempt to install the store version over it fails. The README states the effect directly: the patched app will not be updated or overwritten by the Play Store. That is not a defect, it is the point, because a store update would silently replace your patched build with the unpatched one.

The update path is Obtainium, an app that tracks and installs releases from source, and this repository publishes per-app import configurations for it so a user does not have to write them. The configurations are linked from the app tables, and the README calls some of them experimental, which is a signal about the maturity of those specific configs rather than of the mechanism.

The practical consequence for anyone evaluating this is that the update story is different from the store story. You are no longer relying on Google to deliver a signed, tested update on a schedule. You are relying on a third party app to fetch a release from this repository and install it. That is a smaller trust surface than it looks if you verify the fingerprint on each download, and a larger one if you do not.

The release cadence is high. Recent tags include 26.10.11-morphe from 2026-10-11, 26.10.10-piko from 2026-10-10 and 26.10.06-morphe from 2026-10-06, so patches are rebuilt as upstream apps change.

GPLv3, an explicit disclaimer and a truncated README

The licence section is straightforward. The project is open source and distributed under the GNU GPLv3 licence, with copyright held by krvstek for 2026, and the README says you are free to use, modify and redistribute it provided you keep the original copyright notices intact. The AUTHORS file lists the copyright holders, the icons directory credits base icon designs by kazimmt with modifications for this project, and the canonical source is named as the GitHub repository, which is the usual way of saying that a mirror or a reupload is not the original.

The disclaimer has three parts and one instruction. The project is not affiliated with any patch creators mentioned, and is intended for educational and personal use only. All builds are done using publicly available tools, and the repository automates the process for convenience. Everything happens through public GitHub Actions for security and transparency. And the closing line, which is cut off in the README, begins by saying the repository only provides pre-built APKs and starts a sentence beginning with if.

That truncation matters a little, because the sentence appears to be the disclaimer about responsibility for the binaries, and you are left without its ending. The full version should be read on the repository page before you install anything.

The documentation pointer is the CONTRIBUTING.md file, which the README describes as the place for the full configuration reference, setup instructions and the contributing guide. The README itself is largely a download page with badges and a feature list, so a user who wants to know how the build is configured needs to go to that file.

Building the patches yourself instead of downloading a binary

The alternative is not another app, it is doing the work yourself, and the repository supports that route directly. The README points to the Morphe and Piko source repositories, and says you can always build the applications yourself using the provided source code or official methods.

The difference in approach is where the trust sits. If you build from the patch sources, you are trusting the upstream patch project and your own toolchain, and you produce the artifact on your machine. If you download a release from here, you are trusting this repository's CI, its keystore and its configuration, and you are getting an artifact that someone else built.

The middle path is the fingerprint check, which reduces the second option to something close to the first: you accept the repository as the publisher, and the fingerprint confirms the file was not modified after it was built.

There is a third consideration that is not about trust at all. The patched apps are built against upstream application versions, and upstream applications change. When YouTube, Reddit or Instagram ships a change, a patched build can stop working or behave oddly, and the fix is a rebuild. A repository that rebuilds on a near daily cadence, as the tag dates here show, exists to shorten that window. The corollary is that you need a recent build, and a stale patched APK in your drawer is the failure mode to plan for.

If your requirement is a working, updated app without touching a build chain, this repository is the shortcut. If your requirement is an app you can point at and explain, build it yourself.

Editorial conclusion

Adopt uni-apks if you want patched Android builds without maintaining your own toolchain, and you are comfortable running an app that is not distributed through the Play Store and that updates through Obtainium rather than the store. Do not adopt it if you need a store signed update path, if your organisation blocks sideloaded packages, or if a patched build of a Google or Meta service conflicts with your policy. Before installing, verify the certificate fingerprint against the SHA-256 value in the README, read the disclaimer that the project is not affiliated with the patch creators and is for educational and personal use, and check the CONTRIBUTING.md file for the build and configuration reference.

Frequently asked questions

Official sources

1. krvstek/uni-apks on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases