Privacy first: what Will U Be There can and cannot know about you
Will U Be There cannot show anyone where you are, because it never receives that. The Android build declares two permissions, INTERNET and POST_NOTIFICATIONS. No location permission of any kind, coarse or fine. The iOS build has no NSLocation key in its Info.plist, so an iPhone never shows a location prompt for it. What the app knows about your movements is whatever you typed into a form, meaning a city name and the two dates that bracket the stay.
The objection this answers has been on Reddit for years. From r/apps in October 2019: "Some of the 'Find a Friend' mobile phone apps seem to be data mining in disguise", and then the list, "they want name, email, location, pictures, etc." A commenter in r/socialskills put it shorter in March 2018. "Not a lot of people are too keen on apps where they're being tracked". Both posts describe apps that ask for a location permission on install, which is the one permission this app never declares.
Check the claim before you read the rest
On an iPhone, open Settings and scroll down to Will U Be There. Settings shows no Location row. iOS builds that screen from the usage-description keys inside the app bundle, and mine holds exactly two: NSCameraUsageDescription and NSPhotoLibraryUsageDescription, both worded for a profile photo. The App Tracking Transparency prompt never appears either, because the key that triggers it is absent from the bundle.
The two store labels are the other ten-second check. Google Play's Data safety panel carries the line "No data shared with third parties", which Play prints as my declaration rather than as its own finding. It does list "Approximate location". That is the city coordinate you picked yourself off a map, and it is as precise as the app ever gets, because nothing in it can take a GPS fix. On the App Store side, the App Privacy section has no "Data Used to Track You" block at all. Apple defines tracking as linking data from the app with third-party data for targeted advertising or advertising measurement, or handing it to a data broker. Neither happens here. Apple prints its own caveat underneath, that it has not verified any of this.
Everything the app stores about you
Eight fields hang off your account.
| Stored | What it is for | Who else can see it |
|---|---|---|
| Email address | Signing in | Nobody. It is never shown on your profile |
| Display name and username | Friend search, and your profile link at willubethere.app/u/username | Anyone you give the link to |
| Home city and its coordinates | Matching a friend who travels to where you live | A friend whose trip lands on your city, and only when you are actually home |
| Each trip: a city, a start date, an end date, optional notes | The overlap match, and the events within 15 km of where you are staying | Only as an overlap, meaning that one city and those dates |
| Avatar, if you upload one | Your profile picture | Friends, and anyone with your profile link |
| Friendships | Working out who a trip is allowed to match against | The people on the other side of them |
| A push token | Delivering the notification | Google, as the delivery route |
| A pseudonymous crash identifier | Grouping crash reports so I can fix a bug | Sentry, in Frankfurt |
Sign in with Apple or Google, or ask for a six-digit code by email that dies after fifteen minutes. The account carries no password, so nothing of that kind can leak or turn up in somebody's credential dump. Use Apple's Hide My Email and the address in that first row becomes a random forwarding address. The real one never reaches the database.
What a friend sees when your trips overlap
Say you are in Lisbon from the 4th to the 9th and a friend's trip covers the 7th to the 12th. Both of you get a push naming Lisbon and those dates, and that is the whole of what crosses between the two accounts. Your own trip list never reaches another account, and there is no setting a friend could talk you into flipping. The trip that starts on the 10th is not in that push.
Miss someone by a few days, up to about a week, and you get a near-miss flag instead, so you can shift a day if you want to. It says nothing about the rest of your calendar, since a trip is stored as one city and two dates and no more. That r/apps thread from March 2022 asking for "Basically a location sharing app, but not constant" describes roughly this shape.
Groups loosen that a little. Up to 200 people can join one on a single link, and nobody inside sends a friend request, which is what makes the app work at all for the friend who refuses to install another app. It is also where a forwarded link costs you something: every member of a group can be matched against any trip you let that group see. Per trip, you pick which groups the trip is exposed to. A switch controls whether new trips opt in by default. Forward the link past the people you meant it for, and whoever joins matches like everyone else.
Where the data sits
Trips, friend lists, groups and home cities sit in one Postgres database on Supabase, in the region labelled eu-west-1, which is Ireland. Supabase's own security page states that projects hosted in EU regions keep primary database data in-region, that all customer data is encrypted at rest with AES-256 and in transit via TLS, and that Supabase is SOC 2 Type 2 compliant.
Crash reports land in Frankfurt, on Sentry's EU data region, and the error events, transactions and debug symbols stay there.
Typing a city name into the search box hits Geoapify, a European company that also serves the maps. Its policy says services are hosted in EU data centres, that every API request retains the request body, headers, IP address and timestamp, and that data for successful requests is generally held no longer than 24 hours. So a third party does see the string "Lisb" while you are typing it. It does not get your account, though. The app attaches no identifier to the request, which leaves those keystrokes tied to an IP address for a day at most and to nothing else. The website and its cached images run through Cloudflare.
What leaves the EU, and why
Push notifications. Firebase Cloud Messaging is classified by Google as a "Global service", and Google's own privacy documentation says such services "could process data at any of the Google Cloud Platform locations or Google data center locations", adding that unless a service offers data location selection, "Firebase may process and store your data anywhere Google or its agents maintain facilities". FCM collects Firebase installation IDs, removed from live and backup systems within 180 days of a delete call.
The legal footing is the EU-U.S. Data Privacy Framework, Commission Implementing Decision (EU) 2023/1795 of 10 July 2023, under which Google LLC is certified, plus Standard Contractual Clauses where an adequacy decision does not cover a transfer. A push token tied to your device is the one identifier in this stack with no EU residency guarantee, and I have not found a way to deliver reliable push on both iPhone and Android without it.
One smaller item sits in the same category. Sentry keeps account-level metadata in the US whichever region you pick: user accounts, organisation settings, access tokens, audit logs. The account there is mine. The crash events from your phone stay in Frankfurt.
Exporting everything, and deleting it
"Download my data" produces a single JSON file with your trips, friends, groups and events in it. That is Article 20(1) of the GDPR, the right to receive your data in a structured, commonly used and machine-readable format, wired up as a button inside the app. No support ticket.
Deleting lives in the app too. You type your username to confirm, the account deactivates immediately, and everything is purged after a 30-day grace period. Sign back in during those thirty days and the deletion cancels itself. Article 17(1) is the erasure right behind it. I kept the thirty days in front of the purge so an accidental tap stays recoverable.
What is not in the app at all
The dependency list runs to supabase_flutter, firebase_core and firebase_messaging for push, sentry_flutter for crashes, and the UI packages. Two categories are missing from it on purpose, advertising and analytics. You will not find firebase_analytics or google_mobile_ads in there, and none of AppsFlyer, Adjust, Amplitude, Mixpanel or Meta ships inside the binary. Nothing about you is sold, and no profile of you is assembled across other apps or websites. The app is free, version 1.0.33 as of 28 August 2026, and the App Store listing carries no In-App Purchases line because there are none. The legal wording for all of this is in the privacy policy, last updated 28 August 2026.
The last part you cannot check from outside. I run these servers, and whoever administers a database can read what sits in it. Client-side encryption would change that, and this app does not do it. No table in there has a column for a live position, because none was ever collected.
Where this app fits, and who should skip it
If you want a dot moving on a map, this is the wrong app, and Find My or Life360 do that job properly. Will U Be There will not introduce you to strangers. It works for the friends and groups you already have. Planning is not part of it either, so look elsewhere for bookings, route maps and split bills. A November 2025 post on r/apps wanted "a decent location sharing app that doesn't kill battery and doesn't make us feel like we're being tracked by our parents". This is the other branch of that request, where the thing shared is a city and two dates instead of a coordinate, on iPhone and Android, free as of September 2026, in 17 languages.
More on the mechanics in how to know when a friend will be in the same city, and on the tracking apps this sits next to in Zenly alternatives and Life360 alternatives.
If this page and the app ever disagree, write to info@willubethere.app and tell me which of the two is wrong. I will fix that one.