QUIK's README sends every download to a different repository, and its release badge points at a manual workflow

Every download link resolves to octoshrimpy/quik

The documentation here is careful and specific, and almost none of its links point at the repository the documentation lives in.

The release workflow badge goes to `octoshrimpy/quik/actions/workflows/manual-release.yml`. The releases page is `octoshrimpy/quik/releases`. The F-Droid badge carries the identifier `dev.octoshrimpy.quik.fdroid`. The Obtainium badge is an `obtainium://app/` payload whose id field is `dev.octoshrimpy.quik`, whose url field is `https://github.com/octoshrimpy/quik`, and whose author field is `octoshrimpy`. Even the Play Store link that survives inside an HTML comment uses the same id, `dev.octoshrimpy.quik`. And the maintenance credit at the bottom goes to Marcos Jones, linked as `github.com/octoshrimpy`.

So a reader who opens this README and follows the download instructions installs a build from `octoshrimpy/quik`, and an application whose package id is not this repository's either. That matters for more than attribution: two builds with different ids cannot replace each other by an in place upgrade, and an update channel built from this tree would install alongside rather than over.

One link does use this repository's name. The community room is `#quik-sms:matrix.org`, which matches the owner here rather than the owner every other link uses.

The description line calling the app revived sits alongside all of this, so the repository is presented as a continuation while its documentation is wired to the original.

The Play Store entry is commented out and Obtainium filters on the word release

Two of the three distribution badges are live and the third is deliberately disabled, and the surviving ones carry configuration worth reading.

The Play Store markup is present in the source and wrapped in an HTML comment, so it renders as nothing. It was not deleted, which means the id it names, `dev.octoshrimpy.quik`, is still the one the project would use if it returned, and anyone who uncomments it gets the badge pointing at the upstream listing rather than at this tree.

F-Droid and Obtainium are the live paths. The Obtainium badge is not a plain URL: it is an encoded `obtainium://app/` payload carrying the app id, the GitHub url, the author, the display name, an `apkFilterRegEx` set to `release`, an `invertAPKFilter` set to false, and an `about` string that duplicates the project description. The filter is the part with teeth. Obtainium is told to keep only assets whose name matches `release`, so any artifact published under a different name is invisible to a user adding the app that way, and the F-Droid path is a separate build with its own package suffix rather than the same artifact renamed.

Which means there are three distinct artifacts reachable from one README, built and signed separately, with only the releases page guaranteed to hold whatever was actually published.

Releases come from a manual workflow and the version numbers skip

The badge at the top of the README points at a workflow file named `manual-release.yml`, and the tag history is consistent with releases being cut by hand.

Three recent tags are visible. v4.3.4 on 2026-01-25, v4.3.6 on 2026-04-19, and v4.3.7 on 2026-09-23. The 4.3.5 tag is not among them, so the numbering has a gap, and the intervals are three months and then five. The last push carries the same timestamp as the v4.3.7 tag, to the minute, which is what a release commit looks like from the outside.

None of that makes the project stale. The most recent push is 2026-09-23, well inside the last six months, and there is no archive marker on the repository. But a manual workflow plus a five month gap is a different maintenance shape from a project that publishes on every merge, and it is worth knowing before you pin a version or plan around a cadence.

The practical consequence for an Android user is about update discovery rather than code quality. F-Droid, Obtainium and the releases page each poll on their own schedule, so with a hand triggered release the gap between a tag existing and an update appearing in your app list is a function of someone remembering to press the button.

android-smsmms is vendored at the top level and thanked by name

The MMS support is not a dependency, and the README says so in unusually direct terms.

The thank you section names Jake, linked as `klinker41`, and Luke Klinker, linked as `klinker24`, for their work on android-smsmms, described as an unspeakably large help in implementing MMS into QUIK. A second thank you goes to Moez, linked as `moezbhatti`, for creating and maintaining QKSMS, of which the project says it would not exist without.

Both of those attributions show up in the tree rather than only in the prose. `android-smsmms/` is a top level directory next to `build.gradle`, `settings.gradle` and the Gradle wrapper, which means the messaging library the MMS work came from is checked in here rather than resolved from a package registry. `QKSMS` is named as the project's continuation, so the lineage is two forks deep by its own account.

What the entry listing does not give is any file inside either directory, so the boundary between upstream code and QUIK's own changes cannot be read from what is available here. For a GPL-3.0 project that is a reasonable arrangement, and for anyone auditing it, it is also the reason the build is a large one: a substantial piece of a separate codebase is compiled in every time you build.

A layered tree that also carries secrets.tar.enc and a tmp directory

The top level looks like an Android project that has been worked in for a while, and two entries in it deserve an explanation before you build.

The Gradle scaffolding is conventional: `build.gradle`, `settings.gradle`, `gradle.properties`, a `gradle/` directory and both wrappers, `gradlew` and `gradlew.bat`. Alongside it sit directories whose names suggest a layered architecture, `common/`, `data/`, `domain/`, `presentation/` and `repo/`, plus `metadata/` and `fdroid/` for packaging, and `src/` is not among them at all. Nothing available here states the dependency rules between those layers, so the names are all the guidance there is.

Then there is `secrets.tar.enc`, an encrypted archive committed at the top level, and a `tmp/` directory that is also committed rather than ignored. The documentation never mentions either one. An encrypted file in a public tree is not automatically a problem, since it may hold signing material that a build decrypts with something you supply, but nothing in the README, the contributing guide reference or the license section says what it contains or what reads it, and that is exactly the question to answer before running a build from this source.

One smaller inconsistency: the privacy document is a file named `PRIVACY` with no extension, while its neighbours are `README.md` and `CONTRIBUTING.md`.

Scheduled messages and delayed sending are two entries in one list

The feature list runs to twelve bullets and then opens its final one, so the inventory is a marketing list rather than a specification.

What is named: scheduled messages, message backup, speech to text and text to speech integrated within the app, message blocking and archiving, voice messages, attachments of any type of file, message sorting, message pinning, delayed sending, quick reply from notifications, swipe actions, and emoji reaction handling.

Read down the list and three pairs sit next to each other without any note about how they differ. Scheduled messages and delayed sending are two entries for what sounds like one capability. Blocking and archiving are two more, and the difference matters, since one hides a conversation and the other moves it out of the main list. Quick reply from notifications overlaps with the general claim about notification handling that the stock app already provides.

The list also mixes a UI gesture with a capability and a data operation in the same breath, which is fine as a summary and unhelpful as a compatibility statement. What is absent is as telling: nothing here says what happens to scheduled messages when the device reboots, nothing describes the backup format or where backups are written, and nothing states which of these features work on which Android versions. For a client replacing the system messenger, those are the details that decide whether a migration is safe.

Translations must go through Weblate and bug reports need three facts

The two contributor workflows are the most precisely specified part of the documentation.

Translations are handled on Weblate, and the rule is stated as a prohibition rather than a preference: translations committed directly to the source files will not be accepted. The guidelines sit in `CONTRIBUTING.md` under a translate anchor, and the project asks people to join the Weblate project rather than edit strings in a pull request. For a Java application with a Weblate hosted project, that keeps the translation files out of the main history and out of review.

Bug reports have a three item checklist: steps to reproduce the issue, the QUIK version, and device or OS information. The framing above it says a great report contains a description of the problem and steps to reproduce it, and that the maintainers need to know what they are looking at and where to look for it.

Contributions are welcomed with a pointer to the same guidelines file, and the community chat is a Matrix room. So the whole contributor surface is one Markdown file, one translation platform, one issue template in prose, and one chat room, which is a small footprint for a project of this size and also a small amount of guidance for a first time contributor.

Editorial conclusion

This is a full replacement for the stock Android messaging app rather than a companion, so adopting it means moving your message history, your ringtone and your habits into a third party client, and the licence is GPL-3.0 with the text in the LICENSE file at the root. Its feature list covers the ground people actually migrate for: scheduled sending, backup, blocking and archiving, pinning, voice messages, attachments of any file type, quick reply from notifications, swipe actions and in app speech to text and text to speech. Three things to settle before you install anything. Which repository you are actually installing, because the README in this one sends you to octoshrimpy/quik for the releases page, the workflow badge, the F-Droid listing and the Obtainium configuration, and the Play Store entry is commented out rather than removed. What `secrets.tar.enc` at the top of the tree contains and what consumes it, since nothing in the documentation mentions it and you will be building from this source. And whether the QKSMS lineage matters to you, because the project describes itself as a continuation and the MMS work it credits came from the in tree android-smsmms directory rather than a dependency.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. quik-sms/quik on GitHub
4. README
5. Releases