Catima: an offline loyalty card wallet with thirteen barcode formats and a Wear OS twin

Cards stored on the device, with no account in the middle

Catima does one thing: it holds your store loyalty and membership cards on your phone so you are not carrying a physical wallet. The README's phrasing is that the app stores those cards on your device, instead of having to carry them around.

That framing has an architectural consequence. The app is fully offline, and there is no account, server or sync service in the path between you and your barcode. For a category of data that is a list of membership numbers and expiry dates, this is the correct default, and it is also what distinguishes the app from a retailer loyalty programme that lives in the retailer's own app.

It is a GPLv3+ copyleft application for Android 6.0 and up, written in Java, and the repository is not archived with the last push on 2026-10-15. The current phone release is 2.45.1 from 2026-09-27, following 2.45.0 on 2026-08-12, and the Wear OS line is versioned separately with 1.0.1 released on 2026-08-28.

Thirteen symbologies, and the reason the list is the feature

The supported barcode list is the most concrete statement of what the app does, and it reads:

AZTEC, CODABAR, CODE_39, CODE_93, CODE_128, DATA_MATRIX, EAN_8, EAN_13, ITF, PDF_417, QR_CODE, UPC_A and UPC_E.

Thirteen formats is more than a retail loyalty card ever needs, since most are Code 128 or QR. The extra coverage is what makes imported cards work: a pkpass file from a train operator, a gym or a municipal library may use PDF417 or DataMatrix, and an app that reads only the two common formats renders that card as an unopenable blank square.

The failure mode to know about is not the format but the input. A card has to be added either by typing the number or by scanning the printed barcode, and if the physical barcode is faded or printed at low contrast the scanner may not lock on regardless of which symbologies are compiled in. Card scanning is an engineering decision made once, at add time, and getting a wrong read means redoing the card by hand.

pkpass import, Gadgetbridge, and a Wear OS app that ships separately

Import path one is pkpass files, described in the README as the Apple Wallet format. Importing is not the same as integrating: a pkpass brings fields and a barcode image into Catima, and the resulting card is a Catima card thereafter, stored on the device.

The wearable story has two halves and they are different projects. One is the Gadgetbridge integration, which pushes cards to selected smartwatches through Gadgetbridge's card support. The other is Catima's own Wear OS companion, released under its own version line, visible in the README's separate Wear OS version badge and its filtered release tags.

That version split is visible in how releases are tagged. The phone badge filters out `*-wearos` tags and the Wear OS badge filters for them, so a `1.0.1 (Wear OS)` tag and a `2.45.1` tag are different products from the same repository. Anyone automating updates should filter by tag the way the badges do, or a Wear OS user will be handed a phone release.

The repository layout explains the split in code: `app/` for the phone application, `wear/` for the companion, and `shared/` for whatever both use.

Four distribution channels, and why the reproducibility badge exists

There is no build section in the README and no instruction to compile the app. Distribution happens through ready-made artifacts.

The package identifier is `me.hackerchick.catima`, and it appears in every listing. F-Droid hosts it at f-droid.org/packages/me.hackerchick.catima/, IzzyOnDroid at apt.izzysoft.de, Obtainium is linked from the README with a configuration that tracks the GitHub releases directly, and Google Play is at play.google.com/store/apps/details?id=me.hackerchick.catima.

Obtainium deserves a note because its link encodes the whole update policy in one URL. It filters release titles with a regular expression that excludes anything containing Wear, enables prereleases off, falls back to older releases, uses the release title as the version, and verifies the latest tag as false. In practice that means Obtainium users get phone releases only, without manual tag filtering.

The README also carries a reproducibility status badge from shields.rbtlog.dev. For a card wallet that stores your membership numbers, a reproducible build claim is not decoration: it is the difference between trusting the APK and trusting the app store's account of it.

Building from source is a Gradle Kotlin DSL project, but the README does not document it

The repository is a Gradle project using the Kotlin DSL, with `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties` and the `gradlew` wrapper checked in, plus `build.sh` at the top level and a `.scripts/` directory. There is a `.idea/` directory, a `.design/` directory for design assets, and a `fastlane/` directory holding the store metadata and the English screenshots the README embeds.

What is absent matters more than what is present. The README gives no command for building the APK, no Gradle task name, no signing configuration and no debug keystore instructions. If you want to produce a build yourself, that has to be read out of `build.sh`, `CONTRIBUTING.md` and the workflow files under `.github/`; it is not something the README hands you. The alternative the project does document is obtaining a published build from one of the four channels above, which is also the only path with a signed artifact.

Where Catima sits against the alternatives

The obvious alternative is the retailer's own loyalty app, and the comparison is not close on data ownership. A retailer app can show your points balance, your personalised offers and your card in the wallet, but the card number lives on the retailer's infrastructure and the app is deletable by the retailer at any time. Catima holds the same number locally under a GPLv3+ licence with no account.

The other alternative is a general note or wallet app. Those often handle pkpass files and generic barcodes, but they treat a card as a note with a barcode image, and the scheduling of when you need a given card is left to you. Catima's category is narrower and its list of cards is the interface.

The cost of the narrower scope is the reverse: nothing in the app ties a purchase to a card, so it will not tell you what you spent last year or notify you of a loyalty programme's terms change. It is a wallet, not a rewards tracker.

Editorial conclusion

Catima suits someone who wants their store cards on a phone with no account, no network calls and no vendor in the middle, and who values the freedom to install from F-Droid, IzzyOnDroid or Obtainium rather than only Google Play. It does not suit a workflow that depends on syncing cards across devices or on Android Auto or Apple Wallet integration beyond importing pkpass files. Verify first that the barcode on your most-used card scans in the app's own reader, since symbology support and real-world print quality both decide whether a card is usable, then check that pkpass imports from your retailers render correctly before you delete anything.

Frequently asked questions

Official sources

1. CatimaLoyalty/Android on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases