Morphe Patches is 317 AI generated diffs tested by one person on one machine

The author's own terms come before the patch list

The disclaimer is the first substantive section, and it is unusually direct. This is a personal collection of patches made in spare time, with a little and mostly help from AI. Everything in it is AI generated, mostly for fun and learning, and then tested enough not to explode. Patches work for the author on the author's machine, and anyone using them on anything important is told to test first, with the word seriously added for emphasis.

The rest of the terms set the same tone. Issue triage is described as something the author might get to when bored. Patch requests are welcome, but only after reading a pinned announcement discussion. Donations are invited with a prayer emoji, and the page is titled with the author's handle.

This matters for how the rest of the catalogue should be read. 317 diffs across 227 apps is a large corpus by any measure, and the quality bar stated for it is one person's smoke test on one machine. There is no test suite claim, no compatibility matrix, and no per-patch description of what a diff changes or which build path it touches. The number describes coverage; the disclaimer describes assurance, and the two are not the same kind of fact.

Anything the app checks on a server is out of reach

The request rules contain the most useful line in the repository, and it is a limit rather than a feature. Before requesting a patch, contributors are asked to check whether the feature depends on server-side validation. Region-lock bypasses are refused outright.

That single question settles the ceiling for the whole project. A patch here is a diff applied to an application package, which means it can change what the app does locally and what it sends, and cannot change what a remote service returns or decides. Subscription state, entitlement checks, account validity and region gating all live on the other side of that line. So the honest description of a collection like this is not that it unlocks features, it is that it changes client-side behaviour, and the request template exists to filter out the requests that ask for the rest.

The rest of the request rules are ordinary hygiene: search existing issues and discussions first, include the app name, the package name and the Play Store link when possible. Those three fields are the identity triple the whole catalogue is keyed on, since the patch list stores one row per app keyed by package name, and two different apps can share a display name while no two share a package.

Two hundred and twenty seven apps at about one patch each

The current release header states 317 patches across 227 apps, which works out to roughly one point four patches per app. The table confirms it. Most rows carry a single patch. A handful carry more: two Amazon storefront apps get eight each, 1.1.1.1 gets three, and one launcher gets two. Everything else in the visible table is one.

That distribution says more about the project than the total does. This is not a body of deep modifications, it is a broad sweep of one change per app, and the maintenance model follows from that. A patch tied to an app version goes stale the moment the developer publishes an update, so the real work is not writing 317 diffs once, it is re-basing them against however many Play Store releases those 227 apps publish in a year.

The repository anticipates that, and it has a dedicated issue template for it, separate from the ordinary bug report and named for a patch that broke after an app update. Having a named form for the dominant failure mode is a reasonable sign that the author has watched it happen often enough to want it categorised.

Version strings arrive in 227 incompatible dialects

The version column is a free text copy of whatever the target app calls itself, and the visible rows show how little can be assumed about it. One app reports `v1.0.12` with a leading letter, another `v4.37.0`, a weather app reports `21.1.15-3-rc` with a release candidate suffix in the middle, a document reader reports `26.08.01` which reads as a calendar date, a file manager reports four segments as `1.6.0.4`, and a shopping app reports `32.17.0.300` with a build counter.

None of these can be ordered or range-matched against each other, and none can be compared to a version the user can read off their own device without knowing that app's convention. A patch therefore matches an app by name plus an exact string, not by a version constraint, which means there is no way to ask which patches still apply and no way to say that a patch is compatible with anything above or below the recorded value.

The detailed page for each app is a markdown anchor generated from the display name and the package name together, and the release table links into those anchors. So the catalogue is readable by a person navigating from the README and not addressable by a tool, which is a reasonable choice for a hobby project and a limit for anything automated.

A patched build is identified by three axes, and only two are recorded

The bug report template is the most revealing document in the repository, because it defines what a reproduction is. Four things are required: logs, the app version, the patch source release used to create the patched APK, with the examples given as `stable v1.8.0` and `dev v1.8.0-dev.3`, and the APK source and type, with the examples given as an APKMirror arm64-v8a APK and an APKPure XAPK.

Read that as an identity, a resulting build is determined by three independent axes: which app version was targeted, which patch source release produced the diff, and which mirror the original package came from. The last axis is the one that is easiest to overlook. Two packages with the same name and version from two different mirrors are not the same file, and an XAPK is a container rather than a single package. So the same patch applied to the same app version can produce different results depending on provenance, and none of the three axes is stored alongside the patch.

The logs requirement is a fourth element and the most useful for a user, since the page routes readers to a capture instructions section before they open a report. A project with no test suite and one maintainer can still debug well if it insists on logs, and this one does.

Two release channels, and the headline count trails the branch

Releases come in a stable line and a development line. The recent history shows v1.22.0 as the stable release on 2026-09-15, v1.22.0-dev.1 published eight minutes earlier the same day, and v1.23.0-dev.1 on 2026-09-20. The patches list header says the latest generated patch source release and channel are shown at its top, and what it currently shows is the dev channel, so the catalogue a reader sees is the development build rather than the stable one.

The count in that same header comes from the release that carried it. The last push to the default branch is dated 2026-10-01, eleven days after the v1.23.0-dev.1 tag, so 317 patches across 227 apps describes the state of the dev channel as of 2026-09-20 rather than the branch as it stands.

The release machinery explains the shape of those numbers. The package manifest carries no application dependencies at all, only development dependencies, and every one of them is release tooling: semantic-release with conventional commits, a Gradle semantic release plugin to move the Android version, a Git plugin, an exec plugin, a release notes generator, and a backmerge plugin. The release notes themselves are pulled from a different repository, an external changelog project consumed as a git dependency at a branch named bundle, so the human-readable changelog for these patches is generated somewhere else and read back in.

Five representations of one catalogue and a licence boundary

The same inventory is published five ways: a machine readable list, a bundle descriptor, a markdown detail page per app, a checksum file, and a png that exists to render the release on a hosting page. Generating all five from one source is the right approach, and it also means the build owns five outputs that must agree with each other, with the checksums being the only one that would reveal a disagreement.

The licence is GPL-3.0 with a NOTICE file at the root. That licence covers the patch source, which is what the repository distributes. It does not touch the applications the patches target, and those are third party products with their own terms, several of them carrying names that are someone else's trademarks. The list is explicit about who it touches, since each row links to a Play Store listing for the exact package.

The build side is small. The primary language is Kotlin, with a Gradle project at the root holding `settings.gradle.kts`, `gradle.properties`, a committed wrapper, an `extensions/` directory and a `patches/` directory, and the release tooling described above driven from a package manifest that has no runtime dependencies at all. This article stops at that boundary on purpose: what the patches contain, how they are applied and how a source is registered are all outside what a reader should copy from here.

Editorial conclusion

This is a hobby artefact and the repository says so in its first section, which is the right place for that information. For a developer who patches software on hardware they own, the interesting part is the shape of the problem rather than the patches: 227 apps, roughly one generated diff each, version strings in 227 incompatible dialects, and a maintenance load that grows with every Play Store update. Two things to weigh before touching it. Nothing here has been verified on anything except the author's machine, by one person, in spare time, so treat the corpus as a set of untested suggestions rather than working builds. And decide for yourself whether a client-side diff to a third party app is something you want on your device at all, because the maintenance story, the licence boundary and the fact that every target is somebody else's product all point the same way. This article deliberately gives no installation or application steps.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. rushiranpise/morphe-patches on GitHub