CatchUp: a concierge for eight front pages built on Dagger plugins

Eight front pages flattened into one skimming screen

CatchUp exists because its author reads a lot of services through the day and mostly wants the top of each one. The README frames that as a concierge job, at-a-glance details plus a route onward rather than a full client. Scope follows directly from the framing: there is no login for any service and no customization or filtering of anyone's feed, so nothing in the app depends on an account or on a ranking you control.

The eight sources are enumerated as a flat list, one per line:

- Hacker News
- Reddit
- Medium
- Product Hunt
- Slashdot
- Designer News
- Dribbble
- GitHub

Tapping an item is meant to hand off to the dedicated app through smart deeplinking instead of opening a detail screen inside CatchUp. Infinite scrolling exists only on the services that support it, and one visual language plus night mode is the consistency promise. Read this as a reading surface rather than a data source, since nothing described here exposes an API, an export, or somewhere to keep what you have already seen.

A Dagger plugin contract sits behind every source

The repository keeps the service contract and its implementations apart. `service-api/` holds the surface a source has to satisfy, `services/` holds one implementation per service, and `service-db/` sits on the SqlDelight side for storage. Above them sit `app/` and `app-scaffold/`, with `platform/` and `libraries/` carrying shared code.

The README is direct about why that split exists. The Dagger-powered plugin system is singled out as one of the more interesting parts of CatchUp, and Metro appears in the technology list. What the arrangement buys is symmetry: adding a source means writing a module against the contract rather than teaching a new screen about a new API. What it does not buy is an extension point for outsiders, since nothing described makes a plugin loadable that you did not compile in, and the README asks that new features or significant work be discussed in an issue first. The seam is an authoring convenience for one maintainer, not a platform promise.

Apollo GraphQL, Retrofit and SqlDelight under one screen

Two API styles sit under the same list. Apollo GraphQL covers the services that publish a GraphQL API, while the Square lineup of Okio/OkHttp 3/Retrofit 2/Moshi covers the REST ones, with Moshi doing the JSON binding. Coil handles image loading, and Inspector is listed alongside the rest for working on layout in a debug build. KSP handles annotation processing for the generated code.

Two entries in the technology list carry no stated role. Firebase is listed with no sentence saying what it is used for, so whether a feature depends on it is something only the source answers. The DI story is also stated in two different generations: the list names Metro, while the repository topics still carry `anvil` and `dagger`. That mismatch is small but real, because it says the topic metadata was never updated after the DI layer moved, and anyone finding the project by topic lands on an older answer than the one the README gives.

A canary Android Studio and version catalog keys to build

There is no command to copy here, and the README does not give one. For building, it says you should be able to just clone and build with no issues, then names the one hard requirement: whatever JDK version is currently defined in `libs.versions.toml`. A second constraint comes from the author's habit of keeping up with Android Studio canaries, so a canary version may be needed and the AGP version to match is also in that file. `gradlew` and `gradlew.bat` sit at the repository root beside `build.gradle.kts`, `settings.gradle.kts` and `gradle.properties`, and `renovate.json` plus `.kempt.toml` indicate that dependency updates are automated rather than done by hand.

For a first run, the build matters more than the first screen. Some services need API keys to return data at all, and the README keeps the list of those services in the wiki Authentication-information page instead of the repository, so a fresh clone can produce an app that builds cleanly and a feed that comes back empty. No onboarding, sign-in or feed-configuration step is documented anywhere, which is consistent with a design that refuses to hold credentials.

No login, no filters, and the ceiling that puts on it

The two omissions the README states outright are load bearing. No login means no private content, no personalized ranking and no saved credentials, because every request has to work for an anonymous caller. No customization or filtering means the order on screen is whatever each service's public front page returned today, with no way to pin a community, hide a source or reorder the list. The author calls CatchUp dumb in the README and means it as a boundary, since the same paragraph sends you to a dedicated app for anything deeper.

That boundary produces concrete failure cases. Services that gate meaningful content behind an account will only ever show their anonymous slice. Requests go out unauthenticated, so the API keys documented in the wiki are the only lever you have over access. And the platform story is Android only: Kotlin, AndroidX/Jetpack, AGP from a version catalog, plus an expectation that you are running a canary Android Studio. If your reading needs a synced archive, a custom column or a desktop client, this app answers none of that.

Debug tooling first, tests by video link

Debugging tooling is listed as a first class citizen in the debug build, which is an unusual line to find in a personal project's technology list. The named pieces are Leak Canary, Scalpel, a debug drawer and bug reporting, with Inspector next to them. For an app that talks to eight third-party APIs, memory and layout diagnostics are the practical difference between a usable bug report and a guess.

The testing story is where a close read gets strange. The README says extensive tests can be found at a link, and that link resolves to https://youtu.be/oHg5SJYRHA0, a video rather than a test report, a coverage table or a list of test names. The same paragraph welcomes tests while making clear the author is not trying to turn the project into a shining icon of TDD. Meanwhile the repository root holds a `benchmark/` module that the README never mentions, so there is a benchmark target in the tree with no documented output, and the evidence for the test suite is a recorded run rather than a number you can check.

Commits in 2026 against a tagged build from 2018

The newest tagged build in the repository record is 0.3.2, dated 2018-03-25, preceded by 0.3.0 on 2018-03-19 and 0.2.2 on 2017-12-18, while the last push on record is 2026-10-05.

Two consequences follow from that eight year gap. First, anyone evaluating this is evaluating a moving `main` branch rather than a versioned artifact, so anything you build has to be pinned to the commit you cloned. Second, the machinery for shipping was configured and then left in place: `createRelease.sh`, a `signing/` directory and a `CHANGELOG.md` all sit at the repository root, which describes a shipping process that stopped being exercised rather than one that was removed. The gap also leaves upgrade cost unmeasurable from outside, because there is no published sequence of changes to diff a new build against an old one.

Where the concierge loses to a dedicated client

Comparison is where the README is unusually direct, sending you to one of the many dedicated apps whenever you want more integration features. That is the real alternative, and the difference in approach is breadth against depth. CatchUp holds eight front pages behind one visual language, one scrolling list and a deeplink handoff, which suits a fast scan across sources. A dedicated app holds one source properly, with a signed-in session, filters and local storage you own.

The two named inspirations, Plaid by Nick Butcher and u2020 by Jake Wharton, belong in a different category. The README credits them with inspiration, implementation details and general inner workings, so they are lineage rather than competitors, and no feature by feature difference is drawn. One more silence is worth naming: neither the README nor the visible repository entries mention sync, backup or any way to export what you have read, which is another way of saying CatchUp cannot become the system of record for your reading.

Editorial conclusion

Read CatchUp as a reference implementation of a Dagger plugin architecture and a deeplink router, not as a feed reader to install today. Android developers who want a readable example of the service-contract pattern will get value from the source; anyone who needs sign-in, custom filters or a synced reading history will not, because the README rules all three out on purpose. Before adopting any part of it, confirm that the eight services you actually read still answer anonymous requests, then pin the commit you build from, because the newest published build dates from March 2018.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ZacSweers/CatchUp on GitHub