ChangeDetection: watching web pages for changes on your own Android phone

What the app watches and what it reports

The pitch is a single line in the README: stop refreshing, see what changed. You watch prices, restocks, job listings, application deadlines, or any page you keep coming back to, and you get an alert, open the comparison, and see exactly what moved.

The important framing is in the section heading about the notification. A page changed, and the question is whether it was the price, an application deadline, or just a rotating banner. Opening the saved versions and finding out is the actual product, so the diff is the feature and the notification is only the trigger.

There are three comparison modes. You can see screenshots side by side, read the text changes, or compare the page source. The screenshots in the README show a text comparison highlighting a changed fellowship deadline and funding amount, a history view of saved versions available for comparison, and the Turbo setup screen with pages, checking interval and session duration.

Two supporting capabilities sit on top. Focus on one part lets you pick the section that matters and exclude noisy areas such as ads or timestamps, which is the difference between a useful diff and a wall of noise on a page that regenerates a timestamp on every load. And keep the history lets you revisit saved versions and compare an earlier change, so a notification two weeks ago can be compared against the version before it.

The pace is a choice rather than a setting. You can check now, schedule regular checks, or run a short Turbo session when timing matters.

Setting up your first watch and the cookie limitation

The four steps for a first watch are deliberately concrete.

Tap Watch a page and open a page address. Move to the content you care about and choose the whole page or a selected part. Review the capture, choose a comparison mode, and save it. Then check manually or set up automatic checks, and open a change to compare it with the previous version.

Step two is the one that matters, because the selector is what determines whether the diff is useful. Choosing a specific part of a page and excluding the noisy regions is what makes the text comparison readable.

Then there is a limitation stated plainly in the README. On Android, text and screenshot checks can reuse sign-in cookies saved in the in-app browser. Source checks do not use those cookies. Some sites require you to sign in again, and pages with extra verification may not work reliably.

That is a real constraint and it splits the feature set in two. The common case, a price or a listing page behind a login, works with the in-app browser cookies for text and screenshot modes. The source comparison mode, which is the most precise diff, cannot see behind a login at all, so on a signed-in page you are limited to text and screenshots.

The Turbo mode checks selected pages every 5, 15, 30 or 60 seconds for up to three hours, aimed at a ticket release, a restock or an approaching deadline. The README notes that frequent checks use more battery and data, and advises using the interval you actually need.

Local-first operation and what the platforms support

The data model is the part that distinguishes this from a hosted service. Monitored pages, settings and saved history stay on your device. There is no ChangeDetection account and no hosted monitoring service, and the app has no first-party analytics. Websites still receive the requests your device makes to check them, which is the honest caveat: the requests still come from your IP, so a site sees a client polling it on a schedule.

The platform table says where the thing actually runs.

Android 8 and later is available on Google Play. Desktop is a development build, where text checks run while the app is open and screenshot capture is not supported. iOS is in development. And there is a browser demo that explores the shared interface with sample data but does not monitor live websites.

That table is worth reading carefully, because it describes a project where the Android target is the product and the others are demonstrations of the shared code. The Kotlin Multiplatform structure with a shared Compose UI is what makes that possible, and the browser demo and the desktop build are effectively the same shared code running elsewhere, which is also why the desktop target has no screenshot capture.

The app is available in English, Spanish, Italian, Portuguese, German, Hindi, Bengali and Simplified Chinese, which is an unusual spread for a small utility and reflects the community around it.

One note about the screenshots: the README says they are captured from the app rather than being mockups, and that they show the current source build, so features may be ahead of the published Android app. That is an honest caveat about reading a development branch's documentation.

Building the shared code and the Android app

This is a Kotlin Multiplatform project with a shared Compose UI, and the build uses the checked-in Gradle wrapper.

You need an Android SDK with platform 37.2, and then either set ANDROID_HOME or add sdk.dir to local.properties. The README is explicit that the SDK is needed during Gradle configuration even for Desktop tasks, which catches people out who assume a desktop-only build needs no Android tooling. CI starts with Java 21 and Gradle can provision the toolchains the project configures, while desktop tasks request JetBrains JDK 25.

The three main build commands cover the three targets.

./gradlew :androidApp:assembleDebug
./gradlew :shared:run
./gradlew :webDemo:wasmJsBrowserDevelopmentRun

The first produces the Android debug APK under androidApp/build/outputs/apk/debug/. The second runs the desktop app from the shared module. The third runs the browser demo, which is a WebAssembly build, hence the wasmJs target in the task name.

For iOS you open iosApp/iosApp.xcodeproj in Xcode. The marketing site lives in website/ and uses pnpm, with its own package scripts for development and builds, and the root package.json is a minimal stub that only pins yarn as the package manager at version 1.22.22.

Running the checks, including the README screenshot tour

The test commands are organised by what they check, and the README groups them so a contributor knows which to run.

./gradlew :shared:testAndroidHostTest :androidApp:lintDebug
./gradlew :shared:spotlessCheck :shared:desktopTest

The first runs the shared host tests alongside the Android lint. The second runs the formatting check, which is spotless, and the desktop test suite. Tests that need a real device or emulator are separate.

./gradlew :shared:connectedAndroidDeviceTest

And there is one command that is unusual and worth knowing about, the UI tour used to produce the README screenshots.

./gradlew :shared:desktopTest --tests '*DesignReviewTest.readmeTour'

It captures the real shared app UI at phone dimensions with local fixture content, and the README links a screenshot provenance document for the source images and their composition. That is a good practice and a rare one: a project where the images in the documentation are generated by a test rather than photographed, so they cannot drift from the interface.

The top-level repository layout matches the multiplatform structure, with androidApp/, iosApp/, shared/, webDemo/ and website/ as the main directories, plus kotlin-js-store/, sqliteWasmWorker/, third_party/, tools/, artwork/ and docs/.

Where ChangeDetection is the wrong choice

The first limitation is that the desktop target is a development build, and text checks only run while the app is open. Screenshot capture is not supported there at all. So the version that would suit watching pages all day is the Android one, on a phone, and a team that wants server-side monitoring has to look elsewhere.

The second is the cookie limitation, and it is not a small one. Source checks do not use the in-app browser cookies, so on a signed-in page the most precise comparison mode is unavailable. And pages with extra verification, which in 2026 includes a lot of what people want to watch, may not work reliably at all.

The third is Turbo's cost. Checking every 5 seconds for up to three hours is a lot of requests to a site you do not own, and the README's own advice is to use the interval you actually need. A restock page checked every five seconds for three hours is 2,160 requests, and the people running that page are not necessarily happy about it.

The fourth is the privacy model, which is local-first but not invisible. The app has no account and no analytics, which is genuinely better than most, but the requests still come from your own address, so the site sees a polling client on a regular schedule and can fingerprint it.

The fifth is the platform state. iOS is in development, the browser demo does not monitor live websites, and the README warns that the screenshots show the current source build, so features may be ahead of the published Android app. Anyone deciding on this for a daily workflow should install the Play version and check that it has the feature they need, rather than reading the main branch's README and assuming.

Licence, maintenance and the cost of a local-first watcher

The project is under the Apache-2.0 licence, with the LICENSE file at the root of the repository, and the README states the app is free and open source with no account and no server to run.

The repository is not archived and the last push was on 2026-10-20, the day before the current date, so the work is very active. There are no GitHub releases, so the Play Store build is the distributed artefact and the repository history is the development record.

The cost of adopting it is zero in the monetary sense, which is the point of the model. There is no account, no subscription and no server. The cost is in the phone. A background checker that wakes the device, loads pages over the network and compares them is a battery and data cost, and Turbo multiplies it. The README is upfront about that, and the practical advice is to keep the interval at the slowest value that still catches the change you are waiting for.

The cost of contributing is the multiplatform setup, which is more than an Android project would be. The toolchain asks for an Android SDK even for desktop tasks, and for a JetBrains JDK 25 on desktop, so the environment is not trivial to bring up. In exchange, the shared Compose UI means a change to the interface lands on Android, on desktop and in the browser demo at once, and the same applies to the tests, since the shared module holds the test suites that both platforms run.

The privacy policy has its own file at the root, PRIVACY.md, which the README links directly. For an app that stores snapshots of pages you were logged in to, that document matters more than the marketing line, and having it in the repository rather than only on a website is the right call.

Editorial conclusion

ChangeDetection suits someone who keeps returning to a price, a restock page, a job listing or a deadline and wants a notification when it moves, with no account, no server and no monthly subscription. It does not suit a desktop monitoring setup, because the desktop build is a development build without screenshot capture. Check whether your pages need a sign-in, since the cookie reuse works for text and screenshot checks but not for source checks.

Frequently asked questions

Official sources

1. bernaferrari/ChangeDetection on GitHub
2. Issues
3. License: Apache-2.0
4. README