What leaves your phone when you track a run

Local first describes where a run is written. Collected describes whether a copy leaves. They answer different questions, and a running app can be honest about both at once. Worth settling before you compare any two apps, because the two words are routinely used as if they were opposites.

Local first and uploaded are not opposites

Storage architecture is not the test.

The test is whether a copy crosses the network boundary and is retained on the other side. Apple states the rule plainly in its app privacy details documentation, fetched 2 August 2026: collect means transmitting data off the device in a way that allows the developer or its third party partners to access it for longer than is necessary to service the transmitted request in real time.

Google draws the boundary in almost the same place. Its Data safety documentation, fetched 2 August 2026, defines collect as transmitting data from your app off a user's device, including through libraries, SDKs and webviews whose behaviour your app controls.

A run written to an on-device database and then synced to an account is therefore collected precise location under both definitions. Local storage buys you availability, not privacy. Read any local storage claim as a claim about where the first write happens, then go looking separately for the upload.

The categories that leave a running app

Six categories cover nearly everything a running app can send. Their gates differ, and so do their recipients and their consequences. The right hand column uses the data types defined on Google's Data safety form, fetched 2 August 2026, so you can match each one against a store listing.

The last two rows are the ones people miss, and they are the two that can leave with no account attached: in Runflake, diagnostics and map tiles both have a path off the device while signed out. Its own privacy text says so.

Who receives them

Three kinds of recipient. Listed in rough order of how often they are forgotten. The company's own hosting. The identity provider, if you sign in. And any third party the app has embedded for analytics, advertising, crash reporting or maps.

That third group varies enormously, and the policies say so in their own words. From the Strava privacy policy, fetched 2 August 2026:

We collect, use, and disclose information through the use of cookies, tracking pixels, SDKs, Google Analytics, and other third-party tracking technologies for security and authentication, to understand and improve your experience, perform analytics, inform and serve relevant ads, understand how you interact with ads, and allow you to navigate and use our Services.

Strava Privacy Policy, fetched 2 August 2026

ASICS publishes a single policy covering ASICS Move, ASICS Runkeeper and ASICS Studio. From the ASICS privacy policy, fetched 2 August 2026:

We may share limited personal data (such as electronic identification data, contact information, country and conversion status) with our advertising partners, including social media platforms such as Facebook, X, Instagram, Google, Snapchat, Pinterest etc.

ASICS Privacy Policy, fetched 2 August 2026

Neither disclosure is a scandal. Both are ordinary for a consumer app at that scale. Two things are worth taking from them. The recipient list is longer than the company you handed your run to, and the policy is the only place that list appears. And a single policy covering three apps describes what the company does across everything it operates, not what the running app does, which is a limit no amount of careful reading fixes.

Much shorter lists exist. A smaller app can have one, and stating it precisely is what makes the claim worth anything. Runflake ships no advertising SDKs, no third party analytics SDKs and no third party crash reporting service, tracking is declared false for every data type, and the tracking domains list is empty. Only two outside parties can receive anything: the map tile host, and the identity provider you pick if you sign in. What that does not mean is that nothing is measured. Runflake runs its own usage telemetry, into its own database table, with coordinate and heart rate keys stripped before it is sent. Signed out, the identity provider drops off the list, which running without an account works through in full.

Map tiles, and the request you never asked for

A map is a network request.

Drawing it sends the tile coordinates covering your viewport, plus your IP address, to whoever hosts the tiles. No permission dialog appears, because the app is not reading your position sensor: it is asking a server for pictures of a place, and that is why tile traffic slips past most people's mental model. Consent prompts cover sensors. Tile fetches are plain HTTP, and they start the moment a map view appears.

The organisation behind one of the largest tile networks treats those requests as personal data. The OpenStreetMap Foundation privacy policy, fetched 2 August 2026, refers to personal data associated with a tile request. Its examples are IP addresses and request details.

What the host does not get from a tile fetch alone: your exact fix, your identity, or the fact that you are running rather than browsing. What it does get: roughly which part of the world your screen is pointed at, and the address you asked from.

So if an app draws a map on a screen you did not navigate to, that is an outbound request you did not initiate. Open the policy and find the section naming processors, because a well written one names the tile provider outright.

What a privacy label actually declares

A label declares categories and flags. It does not declare volume, frequency, retention, or which company receives what, and knowing the shape of the form is what lets you read one properly.

Apple's label carries three states: data collected, data linked to you, data used to track you. Per the app privacy details documentation, fetched 2 August 2026, data counts as linked unless the developer strips direct identifiers before collection, manipulates the data to break the linkage, does not attempt to link it back afterwards, and does not tie it to other datasets that would allow the link to be rebuilt.

Tracking is narrower than most readers assume. The same page defines it as linking data collected from the app with third party data for targeted advertising or advertising measurement, or sharing that data with a data broker. An app can collect a great deal and truthfully declare no tracking.

Google splits the same ground into data collected and data shared, then carves out an exception: its Data safety documentation, fetched 2 August 2026, exempts data processed ephemerally, accessed and used only in memory and kept no longer than needed to service a specific real time request. It also states that data used to build an advertising profile or to profile a user cannot be treated that way. So a transmission can be genuinely absent from the form and the form still be accurate.

Both location categories have a numeric definition on the same Data safety page, fetched 2 August 2026. Precise location is physical location within an area less than 3 square kilometres, and approximate location is an area greater than or equal to that.

A worked example. Runflake declares precise location as collected and linked to your account, and declares map tile traffic separately as coarse location that is not linked. The second row exists so the label cannot be read as claiming the map sends no location anywhere.

Withdrawing consent, and what it does not undo

Withdrawal is forward looking.

It stops future uploads. It does not recall copies already sent. It does not remove the runs sitting on your phone.

That is what Runflake's published privacy policy already tells runners: withdrawing location consent stops uploads, and runs already on the phone stay where they are. Two sentences, because they are two outcomes. Deletion is a separate mechanism with a separate scope, and Google Play requires developers to state whether the app provides a way to request it, per the Data safety documentation fetched 2 August 2026.

Runflake's server refuses a run upload from anyone who is not signed in, and the database itself refuses to store an outdoor run unless location consent is on record. On the phone side, the app blocks outdoor uploads in two independent places when location consent is withdrawn, so that deleting either one would still not leak coordinates.

The candid part is what a consent gate does not cover. Publishing a saved run as a public course is treated as an explicit act taken at that moment, and it does not consult the location consent record, so a run recorded before withdrawal can still be published after it. That carve-out is written into the code and disclosed to users, and a real limitation takes that shape when someone is being straight with you.

Keeping a ledger of exits, and why that is unusual

Runflake keeps a single written ledger of everything that leaves the phone, stored next to the code, with an automated test that fails if a new exit path appears or a listed one disappears.

It exists because of a mistake. Someone opened one contract file, found no field named latitude or longitude, and concluded the route did not leave the device. The line was there all along under a different field name. Coordinates were leaving by five separate paths: the raw track uploaded to storage, a display polyline inside the sync payload, published course geometry, a bounding box on the nearby course query, and the map tiles above. One file checked, the building declared sealed. The retraction is dated and written into the launch plan, but by then the sentence had been copied into other documents, which is the second half of the lesson: a correction lands on one copy at a time.

A ledger fixes the class of error, not the one instance. It counts doors in one place, and a test compares that list against the code in both directions. Entries it makes checkable:

• Heart-rate samples are not part of the run upload. They live in a local-only table, which is also why they cannot reach a board. Why heart rate stays out of the rankings covers the reasoning.
• Usage telemetry goes to one table. It is collected under a random device scoped id and sent only to the project's own database, with coordinate and heart-rate keys stripped before it goes.
• Crash reports ride inside that same telemetry stream and carry only the phase, a hash of the message and a frame count. The original text, coordinates and heart-rate data stay on the phone.
• No push notification token is registered. Apple's and Expo's push services get nothing, and notifications are generated locally.

The more useful half of any such list is the part that says what it cannot see. A list built by reading source code answers one question, which is what in this code base opens a connection, and it cannot see inside a third party binary that opens its own.

And it says nothing about what happens once the data arrives. Where the server forwards data next is marked out of scope in the ledger itself, and how long the raw track is kept there is not stated anywhere in the code. Writing the blind spots next to the list is the step most audits skip, and it is the step that tells you what the list is worth.

How to audit any running app yourself

All of this works before you install anything. A store listing and a policy page are enough.

1. Read the label before you installBoth stores publish the declaration on the product page. Open it first, because the marketing copy above it is written by a different team with different incentives.
2. Separate collected from linkedWork through the collected list first and ignore the linked flag. Then go back and check which rows the developer claims were de-identified before collection.
3. Check the tracking flag against the SDK storyTracking has a narrow definition, so an app can declare none and still send diagnostics to an outside vendor. Read the processor list, not the flag alone.
4. Find the section naming processorsA good policy names the hosting provider, the tile host and the sign in providers by company. A policy that only says trusted partners is telling you it would rather not.
5. Check whether the policy is about this appOne policy covering a whole brand describes the shops, the site and every app at once. If that is what you are reading, nothing in it is evidence about the running app specifically.
6. Separate withdrawal from deletionLook for two distinct statements: what stops when you withdraw consent, and how you request removal of what was already sent. If only one appears, assume the other does not exist.
7. Count the location rowsAn app that records routes and renders maps has reason to declare precise and approximate location separately. A single row usually means one of the two paths went undeclared.
8. Ask what happens signed outNot whether the app works without an account. Which of the six categories still leaves when no account is attached to them.