Last Updated: September 25, 2026
Canter, formerly RunWalk ("the App"), is a run-walk interval timer available for iOS, watchOS, and Android. Your privacy is important to us, and we want to be transparent about our data practices.
The App uses your device's GPS location only while a workout is running to:
With your explicit permission, the App may:
With your explicit permission, the App may:
The App:
The App stores on your device:
On iOS, your workout history also syncs between your own devices through your iCloud account (Apple CloudKit), if iCloud is enabled for the App. Apple stores that copy under your Apple Account, protected by Apple's iCloud data protection under your own account settings, and handles it under Apple's privacy policy. Separately, the App's local history and settings are eligible for your device's own backups (iCloud Backup, or a backup to a computer), because the App does not exclude its data from them; whether a copy exists depends on your backup settings, including whether Canter is switched on within them. A restore from a completed backup brings back the history it contained.
On Android, your workout history, settings and plan progress are eligible for Android's app backup when you have Google backup enabled, within Android's limits on backup size, and in a direct device-to-device transfer when you choose one during setup, which works whether or not cloud backup is on. Google stores the backup under your Google Account, encrypted in transit and at rest; on supported Android versions with a PIN, pattern or password set, it is additionally encrypted with your lock-screen secret. Google handles it under Google's privacy policy. A reinstall with backup on can restore what a completed backup contained.
We have no access to your device, your iCloud account or your Google account, so we cannot see any of these copies.
The App uses these platform services, each under its own privacy policy:
Map tiles. While a route map is on screen, the tiles are requested from Apple Maps (iOS) or Google Maps (Android). Those requests carry the map area being displayed and your device's IP address, and are handled under Apple's or Google's privacy policy.
Google Maps SDK. On Android, the Maps SDK that draws the map also collects, for Google, technical information about its use: device model and operating system version, the SDK version, a pseudonymous identifier for the SDK installation, diagnostics if the SDK crashes, and events when the map is panned or zoomed. Google uses this to measure the use of and improve its services, as described in its Maps SDK data disclosure. The App creates the map only when a route is shown.
The iPhone and Android apps send anonymous usage events and crash reports to PostHog, Inc., a product analytics service, which holds them for us in its United States cloud, where we can read them. The Apple Watch app sends none of its own; a workout started on the watch can be reported by the iPhone app, marked as started on the watch.
Usage events. A usage event records that something happened in the App: the App was installed, updated, opened (recording whether it was launched fresh or returned from the background) or sent to the background; a screen was shown, by the screen's name; a workout started, was saved or was discarded; a training plan was started, a plan workout was saved or a plan was completed; the store's rating sheet was requested; or one of the main switches in Settings (bells, haptics, voice, GPS, saving to Health, auto-pause, reminders, starting with a walk, and this reporting switch) was turned on or off. Workout events carry coarse facts: the workout mode, the identifier of the built-in preset or plan day (or "custom"), the plan week and day, whether GPS was on, where the workout was started (phone, watch, widget, shortcut or quick start), and, when it ends, its duration in seconds, its distance in whole meters, the number of intervals, whether auto-pause was used, and, for a discarded workout, why it was discarded. They never carry your route, your pace over time, your GPS position or anything from your health store.
Details on every report. Usage events and crash reports include these details where available: the time it happened, a random identifier for the event itself, the random identifier for the installation, a session identifier, the App's name, package identifier, version and build, the name and version of PostHog's library, the device's manufacturer and model, the device category (phone or tablet), the operating system and its version, the screen size, the time zone, and the type of network connection (for example Wi-Fi or cellular). On iOS they also include your language setting (the language only, not the region), whether the App was installed from TestFlight or from outside the App Store, and whether it runs on a simulator or on a Mac. On Android they also include your language and region setting, the screen density, whether it runs on an emulator, the name of the mobile network operator when the phone reports one, and the system's standard user-agent string, which repeats the Android version and device model. The device model is sent as a model name or hardware code, never as the personal name you give your device. Reports never carry your phone number, your Apple Account or Google Account, or your device's advertising identifier. When the App has just been updated, the update event also carries the version and build it was updated from.
Crash reports. A crash report is sent when the App crashes or runs into an error we have chosen to record, such as the iCloud sync store failing to open on iOS. On iOS it carries the kind of error, its message, how it was caught and how severe it was, the number of the thread it happened on, and the stack trace (the list of the App's functions that were running at the time, with their memory addresses). So that the trace can be turned back into readable function names, it also carries a description of each piece of program code involved: its file path on the device, which includes the folder name the system assigns to the App's installation, its build identifier, and where it was loaded in memory. On Android it carries the kind of error, its message, how it was caught and how severe it was, the number of the thread it happened on, and for each step of the stack trace the name of the class and function, and the source file name and line number where available, together with an identifier for the App's build that lets the names be read; it carries no memory addresses or list of loaded code. On both platforms the report also carries the details above.
The installation identifier. The random identifier is created by PostHog's library inside the App the first time it runs with reporting on. It is not taken from your device, your Apple Account or your Google Account. It lives in the App's own storage on the device and is kept out of backups on both platforms: on iOS PostHog's library marks its files as excluded from device backups, and on Android the App's backup leaves them out. Uninstalling the App removes it, and a reinstall, or a restore from a backup, starts a new one. The App never tells PostHog who you are, so PostHog keeps no profile of you, only events under that identifier.
IP address. Every connection to PostHog, like any internet connection, gives PostHog your device's IP address. Our PostHog project is set to discard client IP addresses, so the address is not stored with the reports, and no location is worked out from it or stored. PostHog's library also contacts PostHog to fetch its settings for the App; that request names only our PostHog project, not your installation, and reaches PostHog from your IP address in the same way. When surveys are enabled in a version of the App, the library also asks PostHog whether a survey applies to this installation, whether or not one is then shown; that request carries the installation identifier, the App's version and build, its package identifier, the operating system and its version, the device category, the time zone, and the name and version of PostHog's library.
How long they are kept. PostHog keeps these events available to us for seven years, the retention period of PostHog's paid plans, as its events retention page sets out. PostHog describes that period as the window within which events can be queried, not as a date on which they are erased, so we do not promise that reports are deleted when it ends. We may delete data sooner by deleting it from our PostHog project. PostHog handles them under its privacy policy.
Turning them off. You can turn usage events and crash reports off in the App under Settings > Privacy > Share anonymous usage and crash reports. The switch is on when you install the App. Turning it off sends one last event recording that the switch was turned off, then stops all usage events and crash reports at once; while it stays off, the App does not start PostHog's library at all. Turning it back on resumes them. Reports already sent carry no name or account, only the random installation identifier, which the App never shows you, so we cannot look reports up by name or account, or find the ones that came from your device. The one exception is a survey answer you wrote whose exact text you give us, when that text is distinctive enough to match a single answer, as described under Feedback survey. Email support if you have questions about them.
Feedback survey. The App may show a short, optional survey inside the App, asking what would make Canter better for you and how likely you are to keep using it. Answering is up to you, and you can dismiss it. Your answers are sent to PostHog with the same random installation identifier as the usage events, and we read the written answers ourselves. Showing the survey and dismissing it are recorded as events too, with the survey's identifier, and if you dismiss it after answering part of it, the answers you had given are sent with the dismissal. Please do not put your name, email address, health details or other personal details in your answers; a written answer can identify you if you write something identifying. The survey is shown only while usage and crash reports are switched on. The check for whether a survey applies, described under IP address above, may itself be recorded as an event naming the survey rule and its result, and that result may be attached to later reports from the same installation, even when no survey appears. If you tell support the exact text of an answer you wrote, and that text is distinctive enough to match a single answer, we can find that answer and the other events sent under the same identifier. If other people gave the same answer, for example a short common phrase, we cannot tell which answer is yours and cannot act on it. PostHog's deletion tools work on person profiles, which these anonymous events do not have, so we will remove them as far as those tools allow, and a complete removal before the retention period ends may not be possible.
Earlier versions. Versions of the iOS app that do not have the Share anonymous usage and crash reports switch send crash reports, and short session reports from which crash-free sessions are counted, to Google's Firebase Crashlytics instead of PostHog, as the previous version of this policy describes in full. Those reports carry the crash trace, device details, pseudonymous identifiers that Firebase assigns to the installation and the session, and an installation token that Firebase issues. Every connection to Firebase also gives Google your device's IP address. In those versions crash reporting cannot be switched off inside the App, and uninstalling does not erase reports already sent. Google keeps crash traces and the identifiers attached to them for 90 days, after which it begins removing them. Versions of the Android app without that switch have no usage or crash reporting of their own; the Google Maps SDK's own diagnostics are described above.
Firebase App Check (iOS). Firebase App Check, on iOS, asks Apple's App Attest service to vouch that the request comes from a genuine copy of the App and passes that proof to Firebase; the exchange carries the app's identity, device and operating-system details, a key identifier and Apple's attestation object, but none of your workout, route or health content. Every connection the iOS app makes to Firebase for an app check also gives Google your device's IP address and the usual connection details, which Google uses to operate, secure and improve Firebase under its own privacy policy.
Beyond these platform services and PostHog (and, in the earlier iOS versions described above, Firebase Crashlytics), the App sends nothing to any advertising network, other analytics platform or other third-party data collection service.
The App does not knowingly collect data from children under the age of 13. Health and location access requires explicit user consent.
If we make changes to this privacy policy, we will update the "Last Updated" date above. We encourage you to review this policy periodically.
If you have any questions about this Privacy Policy, please contact us at:
Email: support@freedom-terminal.com