QuaX is a local-first X client that keeps its state on the device

What QuaX is and where it came from

QuaX is described as a free, open-source, privacy-focused client for X, formerly Twitter. The lineage is stated in the README, which is unusual and useful. It is forked from Quacker and Fritter, and it serves as an alternative to Squawker. That means it inherits two established Flutter codebases rather than starting from a blank project, and that it positions itself against a third in the same family. The repository is written in Dart with Flutter, the licence is MIT, the default branch is master, and the releases are frequent, with v4.19.1 published on 2026-10-18, v4.19.0 the same morning and v4.18.1 on 2026-10-13. The last push was on 2026-10-19. The badges give the platform floor, Android 7.0 and above, the pinned Flutter version 3.47.7, and a target SDK of 37.

The privacy claim, and what it actually means

The README carries an important note above the feature list. An X account is needed to use QuaX, and subscriptions, saved posts and all other QuaX settings are independent from the account you are logged into, with everything local to the app. That distinction is the whole privacy story and it is easy to misread. The app still talks to X with your credentials, so it is not anonymous and it does not shield you from X seeing what you do. What it changes is where your own organisational state lives. Your feed grouping, your saved posts and your preferences are not server-side properties of an X account, so there is no account-side copy for anyone to read, and the app carries them with you rather than syncing them. The feature list ends with a no trackers entry, which is a claim about the app's own behaviour rather than about X. The README also points to a FAQ document, docs/QuaX.md, and a specific section of it for why QuaX is not available on F-Droid, which is the kind of question that deserves a written answer rather than a guess.

The feature list

What the app does is a familiar list of X client features, and reading it tells you what kind of client this is. You can follow anybody. You can group your subscriptions in feeds to organise your timeline. You get trending topics from anywhere in the world. You can search anything on X. You can save posts offline. You can download any media, image, gif or video. You can read X articles. The design is Modern Material 3, and there are no trackers. What is absent from the list is as informative as what is present. There is no mention of scheduling, no analytics dashboard, no third-party service integrations, no custom themes beyond Material 3, and nothing about multiple accounts. This is a client that does the reading and the saving and leaves the rest alone. The offline saving and the media download are the two features that make it a different client rather than a skin, since they are the cases where a local-first design has an obvious payoff.

Distribution: GitHub releases, Obtainium, and fingerprint verification

Installation happens outside the app stores, and the README gives you the tooling for it. There is a Get it on GitHub link pointing at the releases page, and a Get it on Obtainium link, which is an app that pulls and updates releases from a GitHub repository automatically, so you get updates without a store. To verify the downloaded APK, the README tells you to use the signing certificate fingerprints in certificate-fingerprints.txt, a file at the repository root. That file matters more than it looks. Because the app is distributed as a signed APK outside a store, there is no store review standing between you and the build, so checking the fingerprint against the published one is the step that tells you the APK came from the project's build and not from someone who repackaged it. The repository also carries a fastlane directory with the store listing metadata and phone screenshots, a changelog.md, release-notes.md, and scripts for generating release notes and a changelog, including generate-release-notes.sh and generate_changelog_and_release_notes.py, which suggests releases are produced by tooling rather than by hand.

Building it locally with a pinned Flutter SDK

The build instructions exist in the README, and the toolchain is pinned rather than whatever happens to be installed. The prerequisites are Python and FVM, Flutter Version Management, and the Flutter SDK version is pinned in .fvmrc and provisioned by FVM so every build uses the exact same toolchain. The first steps install and activate the pinned SDK and then generate the launcher icon assets, which needs a Python virtual environment with the contents of requirements.txt, namely cairosvg, pillow and requests, and a run of generate_icons.py.

# Install the pinned Flutter SDK and activate it for this project
fvm install
fvm use

The asset generation step runs inside a temporary virtual environment.

python -mvenv .venv
bash -c '
  source ./.venv/bin/activate
  pip install -r requirements.txt
  python generate_icons.py
'

The remaining steps all go through fvm so the pinned SDK is used, covering dependency resolution, launcher icons, license generation, localisation and the Material icon pack before the debug APK build. The presence of a .maestro directory, an analysis_options.yaml, a test directory and a CLAUDE.md file at the root indicates a project with automated UI testing and analysis tooling in place, and the README notes that of course you can work with this app on Android Studio.

Where QuaX is the wrong choice

Three limits, and the first is the account boundary. Because QuaX is explicitly an X client rather than a replacement for the service, it depends on X's own API access, and the official clients hold privileged positions that third-party clients do not have. That constraint shows up in what the feature list omits. If you rely on anything that only the official client exposes, or on the account-level sync the official client provides, this fork is not going to give it to you. The second limit is distribution. Being outside F-Droid and the stores means you own the update path. Obtainium handles that well for people who use it, and for everyone else the flow is download an APK, verify the fingerprint, enable installation from unknown sources. For a user who wants the app to just appear in the store and update itself, that is friction, and the README's own link to a section explaining the F-Droid situation suggests the reasoning was not simply overlooked. The third limit is the fork model itself. QuaX inherits from Quacker and Fritter and competes with Squawker, and a fork that diverges from its upstream carries the usual cost of re-merging upstream fixes, which shows up as intermittent breakage when an X API change lands in one codebase and not the others. For a user who simply wants an X client that is private by default and locally organised, that cost is worth paying. For someone who wants a long-term stable daily driver, the version churn, at v4.19.1 in October 2026, suggests you should expect churn.

Editorial conclusion

Adopt QuaX if you want an X client on Android where subscriptions, saved posts and settings are stored locally rather than tied to a vendor account, and you are willing to install from outside an app store. Skip it if you need the official client's account sync or store updates, since those are precisely what this fork does not do. Before you install, verify the APK against the signing certificate fingerprints in certificate-fingerprints.txt, and read docs/QuaX.md for the answer on F-Droid availability.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Teskann/QuaX on GitHub