Running apps that work without an account

A phone can record a run alone. The satellite receiver is in your phone, the clock is in your phone, and a database file on your phone holds the result. None of those three needs a server. Recording a run therefore needs no account. Almost every running app still asks you to sign in, because the layer above the recording does need one: syncing, ranking, sharing, restoring.

Signing in and recording are two decisions, usually sold as one. Three facts separate them. What genuinely needs a server, and what leaves the phone whether or not you have an account. Then what a given app means by the word guest.

What actually requires an account

Only the parts that touch a server. Everything a single phone can do alone is a product decision.

• Needs an account: syncing to a second device, restoring after you lose the phone, leaderboards and clubs, comments and posts, anything another person can see.
• Does not need one: distance, pace, splits, laps, a map drawn from your own track, the history list, personal records, an export file.
• In between: a training plan meant to follow you across devices, and paid features, since a purchase must attach to something that survives a reinstall.

Apple has put the principle in writing. App Store Review Guideline 5.1.1(v) reads If your app doesn't include significant account-based features, let people use it without a login, and adds that apps may not require users to enter personal information to function except where directly relevant to core functionality or required by law (App Store Review Guidelines, fetched 2 August 2026).

That rule is applied unevenly.

A run tracker can argue its core functionality is account based the moment it ships a feed. Treat the guideline as an argument, not a guarantee.

Google Play attaches the matching obligation at the other end. Apps that allow account creation must provide users with an in-app path to delete their app accounts and associated data, plus a web link where the same request can be made (Play account deletion requirements, fetched 2 August 2026).

Sign in is also where pricing usually begins, and the two questions get confused: what free means in running apps.

Signed out is not the same as offline

The phone is not quiet. Signed out means your runs are not sitting on somebody's server under your name.

Google Play defines the word precisely. In the Data safety guidance, Collect means transmitting data from your app off a user's device, including data sent by libraries and SDKs under the developer's control, and the same page states that user data accessed by your app that is only processed locally on the user's device and not sent off device does not need to be disclosed (Data safety in Play Console Help, fetched 2 August 2026).

Read that backwards and the card becomes an instrument. Anything listed there is leaving the device by the platform's own definition, and anything genuinely local may be absent. An app listing location under collected data is telling you the track goes somewhere, account or no account.

Map tiles, telemetry and crash reports

Different recipients, different gates.

A worked example. Runflake keeps one written ledger of every path out of the phone, stored next to the code, with an automated test that fails when a new path appears or a listed one disappears. In that ledger, usage telemetry is collected under a random device-scoped id, sent only to the project's own database table, with coordinates and heart-rate keys actively stripped before it is sent. Crash reports ride inside that same stream and carry only the phase, a hash of the message, and a frame count. The app registers no push notification token, so nothing goes to Apple's or Expo's push services, and notifications are local only.

The map is the awkward entry. Map tiles are the one thing that leaves to a third party with no consent gate: drawing the map sends viewport tile coordinates and your IP to an outside map host, with no account identifier attached. Only two third parties can receive anything at all: that tile host and the identity provider you pick if you sign in. A privacy page with no awkward entry is usually incomplete.

What a leaderboard needs from you

A board needs a stable id.

It is a sorted list, and the server has to know that this week's total and last week's total belong to the same runner. That is why a leaderboard implies an account.

What it does not need is a legal name, an email address or a photograph. It needs an id, a value and a time window. Everything past those three is a product choice, and each is a fact strangers can read about you.

So look at a single row before you join. A row carrying the location or time of day of a run is a different disclosure from one carrying a number. Three questions settle it:

1. What is on the row?
2. Who can read the board: anyone with the app, anyone with a link, or only members?
3. Can you leave: is hiding yourself one switch, and does it take effect at once?

If the answer to the third is a support ticket, treat the board as permanent.

Boards also decide what they reward. One that sorts on data from hardware you have to buy ranks equipment alongside effort, which is why some apps keep sensor data out of the sort: keeping heart rate out of the rankings.

Guest identities, and what they really are

Guest means two different things. The interface calls both the same word. In one, guest is a local id in the phone's own database, with no matching row on any server. In the other, it is a server side anonymous account made quietly on first launch, a real row you never chose.

Behaviour tells them apart, no policy reading required. If runs recorded before you signed in reappear on a second device, there was a server account. If nothing was recoverable off the phone, the id was local.

Runflake takes the first route, and the reasoning sits in the code: a signed-out runner is not given a hidden server account, and guest is purely a random id stored in the phone's own database, with no row in the server's user table. While signed out, the sync engine stops before sending anything, so nothing about your runs reaches the server. Signed-out visitors cannot even read a board, because the ranking queries are granted only to signed-in accounts. Joining is a deliberate one tap that creates an account with no username and no password and uploads that period's runs, the app assigns an automatic running name so you never pick one, and signing in later with an identity provider keeps the same identity, so rank and history carry over. A runner whose recorded birth year puts them under 14 is blocked from joining a board, and no server account is created for them.

Signing in changes what leaves, in Runflake as in any app that syncs. Once there is an account and location consent is on record, an outdoor run's GPS track and its summary are uploaded, and that upload is what the boards are built on. Withdrawing location consent stops further uploads, while runs already on the phone stay where they are. That is the actual trade, and an app's version of it is worth reading before the first sign in.

The point generalises. An account should be created by an action you took, not by opening the app. Ask whether you can point at the moment you said yes.

How to check any app in three minutes

1. Read the privacy card before the descriptionOn the App Store open App Privacy, on Google Play open Data safety. Both are the developer's own declaration filed under platform rules, so both are more specific than the marketing page. Apple's guidance says you must identify whether each type is linked to the user's identity by you and/or your third-party partners (App privacy details, fetched 2 August 2026), so a label covers the app's vendors too.
2. Start with Data Used to Track YouApple defines tracking as linking your app data with third-party data for targeted advertising or measurement, or sharing it with a data broker (App privacy details, fetched 2 August 2026). Both listings below were read on 2 August 2026. The Strava listing declares Purchases and Identifiers there, and the Nike Run Club listing declares Identifiers. Neither is a verdict. It is a checkable statement of what you agree to.
3. Expect the listing to say nothing about sign inNeither listing, read on 2 August 2026, states whether an account is required to record a run. A listing is sales copy plus a privacy declaration. You answer the sign-in question at first launch, or in the help centre.
4. Find the exit before the entranceIf you decide to create an account, locate the deletion path first. Google Play requires both an in-app path and a web link for the same request. If you cannot find either, you have learned something before handing over an email address.
5. Record one run signed outRecord a short run without signing in, then check what survived. Did it save, did the map draw, is it in the history list after a restart, can you export it? That answers more than any policy page.

None of this is about hiding. The question is which decisions are reversible. Deleting an app removes what was on the phone. It does not remove what already left, which is why the moment to decide is before the first sign in, not after. Where a privacy page exists, read the part about what is uploaded and when: for this site, the privacy policy.