Tapmerge Privacy Policy

Draft. This policy is shown early for testers. Its wording may change before Tapmerge is offered on the App Store.

Draft for testers. On 12 November 2026 the owner approved showing this text, marked as a draft, at tapmerge.thoughtfulsteward.org/privacy. The wording may change, and it still needs the owner's approval before it is used for the App Store listing. Prepared for read-only TestFlight 1.0 (19) and the clearly identified practice features below; reviewed 6 November 2026.

Tapmerge is built so that your code and your sign-in stay between your watch and the service that hosts your repositories.

What Tapmerge collects

Tapmerge does not create a separate account for you or include advertising, tracking, analytics or crash-reporting SDKs. You sign in directly with your code-hosting account. In read-only build 19, repository and PR reads go between that service and your watch; production alert enrollment is unavailable.

Apple's TestFlight is a separate beta-testing service. Apple automatically shares crash and usage information with the developer, and also shares feedback you submit; this can include your name, email address and screenshots. See Apple's TestFlight privacy notice. Tapmerge reviews these records only inside Apple's systems, to improve Tapmerge, and does not download, export or copy them anywhere else. Apple's own retention remains governed by its notice.

What stays on your watch

• Your sign-in. The keys that let the watch read your repositories, and act on them when you tap, are kept in the watch's own Keychain, marked "this device only": not synced to iCloud, never moved to another device. No server of ours receives them.
• What you've asked the watch to remember, such as snoozed cards, the agent name you chose for "send back", requests to merge when ready, and the outcome of recent actions. This is one file per signed-in account. It is encrypted while the watch is locked, readable only by the app, and left out of backups. Only practice builds, where actions work, create this file; read-only build 19 does not.
• The queue itself is held in memory while the app runs and is not saved.
• Queue display choices are saved on this watch separately for each account and connection, outside backups and protected while locked. They select which repositories appear in the queue, not which the app can access. These choices remain after sign-out for the same account's next sign-in; choosing Show all clears the saved selection. Queue display choices are included in internal read-only build 19.
• If you turn on alerts, the watch also keeps, in its Keychain, its registration with our alert relay and a signing key that proves alert requests come from this watch.

What leaves your watch

• To the code-hosting service (GitHub). The watch talks to it directly, with your sign-in. For your own accounts it currently only reads your repositories and pull requests. Merging, commenting and "send back" work only on the two practice repositories used to test Tapmerge. Everything there is the service's own data about you, under its own privacy policy.
• To your iPhone, through Apple's Handoff, if you hand something over. A pull request's web address and a short title such as "Review PR #12", the address of the page where you install Tapmerge on an account, or, during sign-in, the fixed address of the sign-in page (never the code).
• To our alert relay, only if you turn alerts on. See the next section.

The practice alert relay

This section describes the separate practice builds. Production read-only build 19 cannot turn these alerts on. When a practice repository changes, the code-hosting service sends a webhook to our relay on Cloudflare, and the relay asks Apple to tap your watch so it can refresh.

What an alert says: always the same words, "Repository activity changed. Open Tapmerge to refresh." No repository names, no titles, no people, no code.

Turning alerts on: today the project owner approves each watch by hand. The watch shows a six-digit pairing code and a fingerprint of its key, and the owner checks them before approving. The pairing request is kept for 10 minutes.

What the relay keeps about your watch:

• the Apple push address Apple gives your watch, so the alert can reach it;
• the watch's public signing key and a fingerprint of it;
• identifiers (not names) for your account, the installation and the repositories you get alerts for;
• a scrambled (hashed) copy of the one-time enrollment secret;
• when the registration expires.

What it keeps about events: the service sends the full event, which can include repository and pull request names. The relay reads only the identifiers and the kind of event from it. It keeps the event's delivery number and a fingerprint of the message for 24 hours, to reject repeats, and does not persist the content. An alert waiting to be sent holds your registration and repository identifiers with a 30-minute delivery deadline. The incoming webhook can include repository and PR names even though the alert itself has no content; this is distinct from the direct read-only flow.

Other short-lived records: to limit abuse, the connecting address is represented by a keyed hash for a one-minute rate-limit window, rather than stored as a raw address. Error records hold only a random number, a fixed reason and a time, for at most 7 days.

How long: a registration lasts 24 hours. After that, alerts stop and the watch says so; today only a new pairing, approved by hand, turns them back on. When you sign out, turn alerts off, or Apple reports that the push address no longer works (for example after deleting the app), the push address and waiting work are cleared when the relay confirms the revocation. An unconfirmed cleanup stays visible on the watch. The same clearing happens when Tapmerge is uninstalled or suspended on the account, or loses access to every repository you get alerts for; losing some of them just removes those. When a registration simply expires, it can no longer be used, and the push address is cleared on the next relay cleanup. Cleanup of an expired registration is scheduled one day after expiry. Other expiring records are removed when the scheduled cleanup or next operation processes them; delivery authority does not extend while cleanup is delayed. Tapmerge's own relay is set up to keep no logs at Cloudflare. That setting has not yet been confirmed on the running service.

Today alerts work only for the two practice repositories. Alerts for your own repositories are not available yet; they wait on an independent security review.

Signing out

Signing out removes the sign-in keys and clears ordinary action preferences from the watch, while trying to cancel any practice alert registration. Queue display choices are separate and remain locally for the same account's next sign-in until you choose Show all. If cancelling fails, the watch tells you so. If an action's result is still uncertain, the watch first asks you to check it; signing out anyway keeps that one record.

If you have used alerts, the watch's own signing key also stays in its Keychain after sign-out, so the watch can still prove it is the one cancelling its alert registration if that couldn't be confirmed at once. It identifies only this watch, not you or your account.

Deleting the watch app is not a promise that all protected Keychain items have been erased; that platform behavior has not been physically verified. Use the service's account settings to revoke authorization when you want to invalidate access.

Signing out does not withdraw the app's permission at the code-hosting service. To do that, remove Tapmerge from the authorized apps in your account settings there, and uninstall it from the account or organization to remove its access to repositories.

Other companies involved

• GitHub hosts your repositories and handles sign-in.
• Apple delivers alerts and distributes the app.
• Cloudflare runs the alert relay and, like any host, sees the connecting address of each request.

Each sees only what its part needs, under its own privacy policy.

Contact

Questions or concerns: tapmerge@thoughtfulsteward.org.