Privacy. Clearly explained.

Reach (the "App") is a remote desktop tool made of two parts: Reach Viewer for iPhone and iPad, listed on the App Store as "Reach Remote", and Reach Host for Mac. Reach is published by KMWORKS, INC. ("we", "us"), which is responsible for this policy. It explains what the apps, and the optional backend behind them, do with your data.

Two routes are available signed out. Neither sends your screen, audio, input, or connection candidates through our infrastructure.

• Nearby / LAN — Reach Viewer finds your Mac over Bonjour/mDNS on the same network and opens a direct, encrypted QUIC connection. By default the first connection confirms a pairing code shown on the Mac. No session data leaves your network.
• Manual Direct IP — you enter the host address and port yourself (UDP 8443 by default, which usually needs a port-forwarding rule on your router), and the App connects straight to it. No signaling service, no relay.

Separately from those routes: when host pairing is active and remote access is enabled on the Mac, Reach Host publishes a small record of host connection metadata into Apple's CloudKit so your own devices can recognize each other, and Reach Viewer can publish a matching trust record. Both are described in full just below.

Reach Host writes a CKRecord into the public CloudKit database of the Reach iCloud container. The App looks up the record using your pairing code as its identifier. This does not make it private storage or guarantee that only someone holding the code can read it; the database scope is public rather than your private container. We treat this as data that leaves your device, even though Apple operates the storage.

The record contains:

• Your host name — the device name macOS uses on the network
• The host's public identity key and its TLS certificate fingerprint
• The host's external IP address and port, when configured
• Direct connection candidates — the LAN and WAN endpoints used to set up QUIC
• The publication timestamp and the CloudKit record's schema version
• Pre-connect capability metadata — supported codecs, whether system audio is supported, the advertised default resolution, and the capability-payload version
• Your iCloud user record name — a stable identifier scoped to the Reach iCloud container. It is not always present: it is written only when iCloud Auto-Trust is enabled and the iCloud account has been confirmed, so the viewer can recognize hosts that belong to the same iCloud account

When you are signed in to iCloud, Reach Viewer can publish a matching trust record into the same public database on a connection attempt: your viewer's public-key fingerprint, a timestamp, and the iCloud user record name CloudKit stamps on it. Only when iCloud Auto-Trust is explicitly enabled on the Mac does this record let an otherwise-untrusted viewer verified as using the same Apple ID establish trust on its first connection without a pairing code. An already-trusted viewer reconnects through its stored fingerprint and does not need this CloudKit trust record. Manual removal takes precedence over automatic trust: that fingerprint needs a new explicit pairing code before it can be trusted again. After validation and successful local trust persistence, the Mac requests deletion of the record. A failed CloudKit deletion can be retried after a later successfully established connection for that trust entry; immediate or eventual physical deletion is not guaranteed. Removing that viewer from the Mac’s trusted devices revokes local trust on the Mac. That is separate from deleting the CloudKit record.

The App uses this metadata for device discovery and trust verification. Reach Host requests deletion of the relevant host record when you stop pairing or remote publication, or reset the pairing code. Network or CloudKit errors can delay or prevent that operation. “Forget Mac” in Reach Viewer removes the saved connection details and local trust on that device; it does not delete the Mac's CloudKit record. Deleting the App or changing iCloud settings does not guarantee deletion of every record in this public database.

A Reach Account unlocks the two internet routes — Internet Direct, which performs NAT traversal through a saved connection profile, and Relay — and lets devices on the same account trust each other without a pairing code. An account does not by itself create a path: connectivity still requires a dialable direct candidate or a configured relay.

Sign-in is by email. We send a one-time magic link or code; there are no passwords. If you sign in, our backend stores the following, tied to your account:

• Your email address — used only to sign you in.
• An account record — the account identifier and email, a server-held account signing key pair, and the metadata needed to manage sign-in state: creation and verification times, a session generation counter, and the account role.
• A device registry — for each device you register: its device identifier, name, type (Mac host, or iPhone or iPad viewer), cryptographic identifiers (public key, key fingerprint, TLS certificate fingerprint), and its registration, last-seen, and revocation times. For a Mac host it also holds the reachable address and port plus a list of direct connection candidates, so your other devices can dial it.
• Sign-in state — short-lived session and refresh tokens, stored hashed, with their expiry and rotation times. The high-entropy magic-link token is stored only as a hash. The six-digit cross-device fallback code, however, is stored as the code itself in the same short-lived pending-login row, alongside the email, a context hash, its expiry and consumption times, and an attempt counter that bounds brute force.
• Token-refresh recovery — operation identifiers, token hashes, expiry times, and an encrypted refresh response allow interrupted token rotations to be retried safely. These records do not store plaintext session tokens.
• Purchase entitlements — when you use App Store purchase linking, the account stores the plan, expiry and update times, and Apple’s original transaction identifier.
• Passkeys — if you sign in with a passkey, the WebAuthn challenge and the passkey's public credential (credential ID, public key, signature counter, transports).
• Abuse-prevention counters — short-lived request counters keyed by IP address and normalized email address, kept separately to protect the sign-in surface.
• App Store review accounts — for an account used only during App Store review, the account record also stores a hashed review sign-in code, the failed-attempt count, and the attempt-window start time.

This information supports sign-in, device trust, connection setup, purchase-entitlement verification, and service protection. Screen, audio, and input content are not stored in the account database. Operational telemetry, request logs, and ephemeral signaling data are described separately below. See Third-party services for the infrastructure processing needed to provide these functions.

The backend runs on Cloudflare. This policy does not promise a specific processing region.

For signed-in Internet Direct and Relay attempts, signaling exchanges connection candidates such as IP addresses and ports. It processes candidate payloads, attempt-authentication bindings, a viewer public IP address when present, and rate-limiting state.

Each candidate payload has a validity period of at most 60 seconds from publication. Republishing can update the overall attempt deadline. Cancellation and expiry handling clean up candidates and related state; this does not promise physical deletion immediately after success or at exactly 60 seconds. Authentication state needed by a live Host socket can remain while that socket is active. Brief cancellation markers that prevent reopening an attempt and service-protection counters have separate lifetimes.

The signaling service does not receive or store screen, audio, or input content. Session content travels over a direct connection or the Cloudflare TURN route described below.

When a direct path is difficult to open — for example behind CGNAT, restrictive firewalls, or some mobile networks — Reach can relay the session through Cloudflare TURN. You configure your own Cloudflare account and credentials in Reach Host; your Cloudflare charges and policies apply.

With automatic account-token setup, the Mac requests a TURN key from Cloudflare’s API. This sends the Cloudflare Account ID, token, and a key name that can include the Mac’s name. The generated TURN key, or a key you enter manually, is stored in the Mac Keychain and used to obtain short-lived session credentials. These credential requests go directly from the Mac to Cloudflare, not through the Reach account server.

Video, audio, and input remain encrypted with TLS 1.3 over QUIC while traversing the relay. Cloudflare processes encrypted packets and the network metadata needed to provide its service. Connection latency depends on the network and relay path.

Optional Cloudflare usage reporting

When you enable usage reporting and select Refresh, the Mac calls Cloudflare’s GraphQL API directly. The request includes the Account ID, time range, optional TURN Key ID, and API token; the response provides aggregate ingress and egress bytes. Account-wide results can include TURN usage from services other than Reach. Storing a token alone does not run a usage query.

The reporting token is held in a device-only Keychain entry separate from TURN session credentials. The enable switch, Account ID, and display scope are local preferences; fetched results are held only in memory while the App runs. Turning reporting off or changing Reach accounts clears the previous results without automatically deleting the saved Cloudflare credentials. Removing credentials in Host does not revoke keys or tokens already issued by your Cloudflare account; manage revocation in Cloudflare.

You can delete your Reach Account in the App. The account database deletes the account record, registered devices, sessions and token-refresh recovery records, pending login codes, passkeys, and associated WebAuthn challenges together. Pre-account WebAuthn challenges with the same email address are also included.

Abuse-prevention counters and operational logs are outside this account-deletion request. Counters follow their configured rate-limit windows and cleanup procedures; operational logs are retained separately in Cloudflare. This policy does not promise a fixed retention period for operational logs.

Expired or consumed login links and codes cannot be reused for authentication. Expired login, WebAuthn, and refresh-recovery records, and sessions whose refresh lifetime has ended, are eligible for scheduled cleanup. The cleanup schedule or a failed operation can make physical deletion occur after expiry.

You can remove individual devices separately. Signing out is not account deletion. Local connection preferences, presets, trust records, and Cloudflare credentials have separate cleanup controls. Deleting a Reach account does not delete Apple’s public CloudKit records or keys in your own Cloudflare account.

Reach Host requests macOS Screen Recording permission to capture the display you select, and Accessibility permission to deliver the input you send from the viewer. Optional window restoration also uses this permission to read and change the position and size of supported app windows.

System audio is captured through ScreenCaptureKit. Reach Host does not request Microphone permission and ignores microphone samples; what it needs is Screen Recording / system-audio access. Capture happens on the Mac and is streamed only to viewers authenticated for that session.

In Direct Touch mode the viewer shows a cursor handle for pixel-precise pointer movement. To drive it, Reach Host sends the position of the Mac's cursor — a normalized coordinate, the display it belongs to, and a timestamp — to the connected, authenticated viewer, over the same encrypted QUIC session as video and input. It is not sent to a separate analytics service or stored as a cursor-movement history. With Relay, encrypted session packets pass through Cloudflare.

You can turn it off in Reach Host → Devices & Trust → Advanced → Cursor Telemetry. The host then stops sending cursor position and tells supported viewers to clear any handle left on screen.

Reach Viewer uses Local Network permission to discover nearby Macs over Bonjour/mDNS and to communicate directly with a Mac on the local network. Entering that Mac's IP address manually does not replace this permission. Manual Direct IP to an address outside the local network is a separate case and requires a reachable address and port.

Reach Host checks for new versions on launch and periodically while running, using the Sparkle update framework. An update check is a standard HTTPS request to our update feed, which is hosted on GitHub Pages; as with any HTTPS request, your IP address and a User-Agent header are visible to that endpoint, but no account identifier, telemetry, or other identifying payload is sent. Reach Viewer updates through the App Store, governed by Apple's standard App Store policies.

Reach does not use advertising identifiers (IDFA) or advertising and profiling SDKs. The apps do not include Crashlytics, Sentry, or Google Analytics. Local diagnostics can be provided when you choose to share a report. Optional Cloudflare usage reporting, described above, and backend operational records, below, are separate functions.

To operate and protect the service, the backend records operational events and request logs in Cloudflare and, when configured, sends metrics to Analytics Engine. Principal categories include:

• Connection-lifecycle event names and times, attempt identifiers, region labels, role (host or viewer), outcome, and latency
• App version and build, socket kind, reconnect path, and a stable SHA-256-derived host pseudonym on host socket registration and blocked-registration events. Related kill-switch events also include the Worker request endpoint. These extra fields are not attached to every invite or socket-close event.
• Group and cleanup counts, socket-lease release reasons and status, error classes, and short correlation prefixes. Device-restoration logs include the first eight characters of account and device identifiers.
• When purchase linking is used, operational purchase-verification records such as the first eight characters of the account identifier, product identifier, verification environment, and application result

A pseudonym does not contain the device name or account email itself, but can link events from the same host. Rate-limiting state is also kept for service protection. Local diagnostics can include the selected connection route. The current code forwarding connection-lifecycle events to Analytics Engine does not populate a separate route-kind field.

These records support connection reliability, fault diagnosis, service protection, and purchase verification. They exclude screen, audio, and input content. We do not sell them or use them for advertising or user profiling. Cloudflare processes this operational data as a service provider.

• Connection preferences — selected display, resolution, codec, frame rate, bitrate, scroll-direction toggles, cursor telemetry on or off, and the route last chosen for each Mac
• Workspace presets — names, layout and per-screen Mac and display identifiers, route, sizing and resolution choices, window-restoration preference, and creation and update times are stored in the Viewer’s local settings.
• Saved connection details — the address and port you entered for a Direct IP host, and the pairing code for a Mac you have paired with
• Trust records — cryptographic fingerprints of hosts you have paired with, and of viewers your host has trusted
• Account session tokens, if you are signed in — in the device's secure keychain
• Cloudflare credentials, if configured — relay keys and optional reporting tokens are stored in the Mac Keychain. Key creation, session-credential generation, and usage reporting call Cloudflare directly as described above.
• Diagnostic logs — kept temporarily for troubleshooting, never uploaded unless you choose to share a report

Optional remembering of app window positions

With Remember app window positions enabled in a preset and Accessibility permission on the Mac, Reach keeps references to supported, open windows, their normalized position and size, and whether they can be resized in Mac process memory before removing a Reach virtual display. It uses this snapshot to restore still-open windows when that display is recreated. Window titles and document identifiers are not saved as snapshot fields, and the snapshot is not written to disk or a Reach server. It disappears when the Host process exits; disabling restoration for the display clears its snapshot. The preset’s on/off choice remains in Viewer settings.

Deleting the iPhone or iPad app removes its app-container data. Keychain items are managed separately, so uninstalling alone does not guarantee removal of all credentials. On the Mac, deleting the Reach Host app bundle does not automatically remove its settings, Application Support files, or Keychain items; remove those by hand if you want a clean slate.

reachremote.app is a static site hosted on Cloudflare Pages. The site's own styles, scripts, and images are served from this site. Cloudflare adds email address obfuscation and browser verification scripts on the public domain. Public pages also include the Cloudflare Web Analytics beacon for page-view and performance metrics. Cloudflare security features may use necessary cookies. We do not use advertising trackers. Cloudflare also processes ordinary request metadata, such as IP address and User-Agent, when serving web requests.

Website language is specified in the URL path. Old ?lang=en links move to the matching English page. The Cloudflare setup choice is stored in the setup query parameter. This website does not collect API tokens or pairing codes. Selecting the Mac download queries the GitHub Releases API for the latest DMG, then opens GitHub’s download. External destinations, including GitHub and the App Store, have their own privacy policies.

• Cloudflare — serves the website and processes optional account, sign-in email, signaling, and operational data. It also provides TURN relay, key creation, and optional usage APIs under your own account. Session content in relayed packets is encrypted between your devices.
• Apple (CloudKit) — stores the pairing metadata described above so your own devices can discover each other.
• Apple (App Store) — distributes Reach Viewer and processes applicable purchases, subscriptions, and purchase verification under Apple's standard App Store policies.
• GitHub — hosts the Reach Host update feed (appcast) on GitHub Pages and distributes the Host installer through GitHub Releases. GitHub processes standard HTTPS request metadata such as your IP address and User-Agent when you check for or download an update.

These services process data needed for their respective roles. Reach does not sell data to advertising networks or data brokers.

Every route — Nearby / LAN, Manual Direct IP, Internet Direct, and Relay — is encrypted with TLS 1.3 over QUIC and protected by certificate pinning. A viewer connects only to a host whose certificate fingerprint it already trusts — recorded when you paired, held for that device in your Reach Account's device registry, or pinned on an explicitly authorized first direct connection (trust on first use). A later mismatch is rejected. We cannot decrypt this traffic on any route.

Reach is not directed at children under 13, and we do not knowingly collect information from children. Pairing and account metadata supports the service functions described above and is not used for advertising or user profiling.

We may update this policy from time to time. Changes are posted on this page and the date at the top is updated. We revise it whenever the trust model or the data flow changes.

Questions about this privacy policy: support@reachremote.app. Bug reports and public questions: github.com/SGT-Cho/Reach.