Atomatic, auto replies for WhatsApp and other messengers from a notification

A migration aid rather than a chatbot

Atomatic sends an automated reply to everyone contacting you on messaging apps, and the README is clear about the two situations it is for: you are planning to migrate away from messaging apps, or you want to use it as a vacation responder.

The migration framing is the interesting one, and it comes with a specific explanation. WhatsApp's privacy policy changes triggered a large migration to more privacy-friendly apps such as Signal, but most people find it difficult to delete WhatsApp because everyone else uses it. Atomatic tries to make that migration easier by letting your friends automatically know that you have moved, so you set an auto reply message along the lines of I am not using WhatsApp anymore, please use Signal, and the app sends it for you.

That framing sets the scope precisely. The feature list is four items: auto reply to every message on supported messaging apps, set your own auto reply message, auto reply to group chats, and respects your privacy, with the privacy note spelled out as no analytics or tracking. It is free and open source.

So this is not a bot platform. There is no conversation logic, no keyword matching, no integration with a language model, and no way to have a different answer depending on who is writing. There is one message you write and it goes out.

The naming is a bit tangled, and the repository reflects it. The repository is called watomatic, the README heading says Atomatic, the Play Store listing is under the package id `com.parishod.watomatic`, and the F-Droid package is `com.parishod.watomatic` as well. The top-level tree has both an `app/` directory and an `atomatic/` directory, which suggests the project directory was renamed at some point and the package identity was kept for continuity, since the store listings depend on the package id staying stable.

The primary language is Kotlin, the licence is GPL-3.0, and the homepage is watomatic.app.

How the reply is sent, through notification quick replies

The mechanism is the part of the project that explains both its simplicity and its limits, and it comes out of the troubleshooting section rather than a feature description.

Atomatic relies on notifications for auto reply to work. Most users have notifications enabled, so it should work out of the box, but otherwise you need to make sure notifications are enabled and that app-specific fingerprint lock is disabled for Atomatic to work.

That is the whole trick. The app does not automate WhatsApp, does not use Accessibility services to type into it, and does not run a screen reader over it. It listens for the incoming message notification and issues the platform's own quick reply, which is the action that appears when you swipe down a notification in a messaging app. The reply goes out through the messaging app's own notification handler, so the message is sent by the messaging app itself.

This has three consequences that follow directly from the design.

First, the app needs the messaging app to support notification quick replies at all. The FAQ explains why there is no iOS version: the app relies on the Android-specific notification quick replies feature to function, and this may not be possible on iOS. That is a platform statement, not a scheduling decision.

Second, the app needs notification access, and the user's device settings can withhold it. The troubleshooting entry is not a formality, it is the most likely failure mode, and both conditions in it have to hold: notifications enabled, and app-specific fingerprint lock disabled for Atomatic.

Third, the app has no visibility into the message content in the way a bot would. It reacts to the notification. That is also where the privacy claim comes from, because the mechanism only needs to know that a message arrived, not what it said.

The FAQ also explains why the obvious alternative is rejected. Asked why not use a WhatsApp business account for auto replies, the answer is that you cannot use a business account without accepting the new privacy policy that everyone is trying to avoid. That is a direct answer, and it places the project squarely in the migration scenario its author described.

Privacy as a stated design constraint

The privacy claim is short in the feature list and longer in the repository.

The feature list says the app respects your privacy, with the specific note that there is no analytics or tracking, and the project describes itself as free and open source. The README says the author's generosity is the only source of income, free, no ads, no tracking, and that the project is funded with personal savings and free time.

There is a `PRIVACY.md` at the root of the repository, which is the document to read for the detailed claim,

The repository tree shows the infrastructure behind the app, and it is worth reading carefully because it is more than a local notification listener. There is a `firebase.json`, a `firestore.rules` file, a `firebase-domain/` directory, a `functions/` directory, an `aws/` directory, `crowdin.yml`, and `fastlane/` for release automation. So the project does have server-side components: Firebase configuration for something, a functions directory for a serverless backend, an AWS directory for something else, and Firestore rules that define what a client is allowed to do with the database.

That is consistent with a phone-home component for things other than message content. A public key backend for delivering messages, or a configuration service, or release and translation pipelines, would all explain the presence of those directories without contradicting the no-analytics claim, which is specifically about analytics and tracking rather than about the app making no network requests at all.

The distinction is worth keeping straight when evaluating the claim. No analytics and no tracking means the app is not building a profile of you from your messages. It does not mean the app never talks to a server, and a reader who wants to know exactly what leaves the device should read `PRIVACY.md` and the Firestore rules rather than assume either way.

The licence is GPL-3.0, which means anyone can read the code that implements the behaviour, and that is the more substantive part of a privacy claim for an app that handles your notifications.

Distribution, translations and the funding model

The distribution story is the part of this project that has been thought about most carefully, and it is unusual in a good way.

There are three routes. The Google Play listing is the main one, under the package id `com.parishod.watomatic`. F-Droid carries it as `com.parishod.watomatic`. And there is a third route through IzzyOnDroid, an alternative F-Droid repository, at apt.izzysoft.de, which exists to serve builds that the main F-Droid catalogue cannot ship.

That last one tells you something about the project. Shipping through F-Droid is a commitment to reproducible builds and to a specific set of acceptable dependencies, and an app that uses a Firebase backend with proprietary SDKs can hit friction there. The IzzyOnDroid repository is the standard answer when a project wants a F-Droid-style distribution without giving up those dependencies.

The translations story is similar. There is a `crowdin.yml` at the root and a translation site at translate.watomatic.app, and the contribute section asks people to improve translations by joining that site. Crowdin is a hosted translation platform, so a project with no money uses a free tier rather than running its own translation workflow.

The funding model is stated plainly in the README and it is unusual for an app store release. The author asks for moral support, which he defines as reviewing the app on Google Play, following the accounts, joining the Reddit or Telegram communities, and sharing the app, and separately asks for money, with a Liberapay link showing a financial goal and a donation wallet in a link and a plain-text Bitcoin address.

The README is candid about why: the author is funding this with personal savings and free time and cannot do it alone for a long time. The build tooling in the repository matches that story. There is a `fastlane/` directory for automated store releases, a `firebase.json` for the backend, and `build.gradle.kts` with `settings.gradle.kts` and a Gradle wrapper, which is the standard modern Android setup and is what makes the F-Droid-style builds possible.

The primary code lives in the `app/` and `atomatic/` directories, and there is a `TESTING.md` at the root plus a `CLAUDE.md`, which suggests the project has moved to writing some of its working notes in a form that tooling can read.

What state the project is in

The release history is where the picture gets mixed, and it deserves a straight reading.

The recorded releases are v1.29 from 2024-09-25, v1.21 from 2022-09-22 and v1.20 from 2021-06-23. The last push to the repository was on 2026-07-22. So the branch has moved within the last three months, but the last tagged release is nearly two years old and the gap between v1.21 and v1.29 suggests a period of quiet releases with work continuing on the branch.

For an app, that distinction matters more than it would for a library, because a tagged release is what most people install. The Play Store and F-Droid listings would be serving whatever was last published, and whether the branch since then contains fixes depends on whether the maintainer has pushed a new release. The README's contribute section asking for Play Store reviews and sharing suggests the app is still in active use, and the issue tracker is where feature requests go.

The version numbers themselves are worth noting. The tags are `v1.29`, `v1.21`, `v1.20`, and the release titles in the history are given as Watomatic 1.29 and similar, so the project version and the store identity share the same number even though the names differ between repository and app.

And the README points people at the issue tracker for bugs and feature requests, with Telegram, Mastodon, Twitter, Reddit and an email address as the other contact routes. That is a well-run contact page for a one-person project.

The repository licence is GPL-3.0, with a LICENSE file at the root. For an Android app distributed through stores rather than as a binary you compile yourself, the practical effect of GPL-3.0 is on anyone who wants to fork and redistribute the app rather than on ordinary users.

The limits, and the honest comparison

Three limitations are worth stating plainly.

The first is that this is a one-message tool, and anything that needs a decision per conversation is out of scope. There is no per-contact message, no schedule, no out-of-office range and no branching. The README describes the vacation responder use as a secondary application of the same fixed message, which makes it clear that the message is global rather than contextual.

The second is the dependency on the messaging apps continuing to support notification quick replies, and on the user leaving the relevant notifications enabled. That is a dependency on two other parties, one of them a company with its own reasons to change behaviour, and it is the kind of dependency that breaks without warning and without an error message on your side.

The third is platform coverage. Android only, and the README says the iOS version may not be possible because of the notification quick replies feature. There is also a question mark over how well the app tracks newer messaging apps, since the README talks about supported messaging apps without enumerating them beyond the topics list, which names android, automation, autoreply, chatbot, facebook, facebook-bot, messengers, privacy, privacy-tools, signal, telegram, whatsapp and whatsapp-bot.

The alternative to consider is not another auto-reply app, it is a different approach to the same problem. A WhatsApp business account gives you an away message with a schedule, but as the FAQ says it requires accepting the privacy policy the user is trying to avoid, so it answers a different question. A full chatbot framework gives you branching and per-contact logic but requires reading message content, which is exactly the privacy trade this app avoids, and it usually needs an unofficial client or an account you have tied to a third-party service. And the manual option, replying once to each person yourself, avoids all of the machinery but does not scale to the hundreds of contacts a migration actually involves.

So the honest framing is that Atomatic occupies a narrow slot: a single message, sent automatically, without reading what is written to you, on Android, through the notification system rather than through any app's internals. If that is your problem, it solves it in a way nothing else does. If you need more than one message, it is the wrong tool and no setting will change that.

Editorial conclusion

Atomatic suits an Android user who wants to tell contacts on WhatsApp, Facebook Messenger, Telegram or Signal that they have moved to a different app, and who wants that to happen without handing message content to a server. It does not suit anyone who wants a full chatbot, a business account or an iOS version. Verify first that quick replies are enabled on your messaging apps, since the app depends on them, that app-specific fingerprint lock is disabled for Atomatic, since that blocks it, and that the version you install is one you trust, given the last tagged release is v1.29 from 2024-09-25.

Frequently asked questions

Official sources

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