Privacy Policy

Effective date: September 18, 2026

Pip ("the app", "we", "us") is a family activity decision app built for personal family use. This policy explains what data the app collects, how it is used, and your rights regarding that data.

1. Data We Collect

Pip collects the following data to provide its core features:

• Location (optional): If you allow it, your approximate location is used to estimate the drive time to a place Pip suggests. It is sent to Apple, through MapKit, at the moment the suggestion is shown. It is not sent to Google and it is not sent to our server. Place searches sent to Google are always centred on a fixed Dubai city-centre point, not on your position, and if you have not granted location access, drive times are estimated from that same point.
• Family library content: Restaurants, games, beaches, family members, and cooking favourites you add during onboarding. This data is stored locally on your device.
• Decision history: A log of suggestions you accepted or rejected. Stored locally on your device. Used to hold back a meal you cook at home or a game you chose in the last three days.
• App preferences: Settings such as your preferred maps app. Stored locally using Apple's standard UserDefaults.
• Usage events (sent to our server): Pip sends a record to a server we run ourselves each time you do certain things in the app: launch it, view a library item, add a place, open a context sheet, request a suggestion, accept, reject, complete or shuffle a suggestion, decide a category, view or complete or skip onboarding, discover a feature, and dismiss a request to rate the app (including the reason it was dismissed). Some records carry a small amount of detail about the action, such as which category or which trigger was involved. Every record also carries a pseudonymous per-install code, the app version, the build number and the OS version. It does not carry your name, email, location, or the names of anything in your family library. There is no setting to turn this off.
• Crash and performance diagnostics (sent to our server):

  Crash and performance diagnostics. If the app crashes, freezes or misbehaves, iOS gives the app a report about it, on your device, through Apple's MetricKit. The app does not send us that report. It reads it on your device and sends a different one that it writes itself, out of a list of things it knows how to describe.

  Two parts of Apple's report are written as ordinary sentences: the reason iOS gives for ending the app, and the message attached to a file or system error. Those are the parts where a file name, or something you typed, can turn up. The app does not send them. In their place it sends six things it recognises: which part of iOS ended the app, the type of error, the standard phrase for the kind of programming mistake that ended it, the name of the error type raised, and two things about a block of memory, its read and write permissions and how it is shared. Each of those six is chosen from a fixed list written into the app: the app compares what iOS said against that list and then sends the list's own wording.

  Three more things travel with those and are not chosen from a list, so they are named here exactly. Two are numbers iOS attached, one to the ending and one to the error. A number is sent only when it sits in the same written part as the name it belongs to, after that name, in the format iOS itself uses. The only things allowed to sit between the two are punctuation, the word iOS writes in front of a code, and a short fixed list of words the kernel puts there itself, one of which carries a number of its own that the app skips rather than reads. Anything else at all stops the search and the number is dropped. Each number is also checked to be a number and nothing else. The third is the size of that block of memory, which the app works out by subtracting two addresses it read itself, so it is a measurement rather than anything iOS wrote.

  Out of those two written parts the app copies no words at all. What it sends from them is a label chosen from a fixed list, or one of the two numbers described above beside the name that number belongs to; where it recognises nothing it records only that there was something there it could not read, never what that was. The same is true of an error type it does not know.

  The stack trace is rebuilt, not filtered. The stack trace is the machine-written part of the report: a tree of steps showing where in the program the failure happened. The app reads Apple's tree and writes a new one containing only the pieces it has names for - for each step, the identifier of the piece of code it happened in, that piece of code's name, two numbers saying where inside it, and the steps underneath. Anything else in Apple's tree, including anything a future version of iOS adds to it, is counted and not copied: the report says how many things it did not recognise, never what they were. Because the new tree is written rather than edited, the only characters it can contain are letters, digits, and - . _ + with the punctuation that separates them: no space, no /, no @, and no letter outside the English alphabet. A file path needs its separator, an e-mail address needs its @, and a name written in another alphabet needs a letter that is not in that set, so none of those three can be written into it at all. Travelling with it: how many steps it wrote, if it left any out, how big Apple's own tree was, and whether it could read Apple's tree at all.

  A web address is the one category of those four that is only partly closed, and this says so rather than rounding it up. A link with a / is refused, but a bare host name such as www.example.com uses only characters a code file's name may use, so nothing in the shape tells the two apart.

  The app build, the iOS version and the processor type travel too. Each is checked against the exact shape it is meant to have - the iOS version, for instance, must be one of a fixed list of Apple platform names followed by a version number and, if present, a build code - and anything that does not match that shape is dropped and counted rather than sent.

  What else travels: which of the four kinds of report this is, the low level exception and signal numbers iOS recorded, the app build, the iOS version and the processor type, the time window the report covers, and, where they apply, how long the app was frozen, how much it wrote to storage, and how much processor time it used.

  One thing travels with it, and it is the same thing that travels with every other count we collect: a pseudonymous per-install code. It lets us tell that ten crashes came from one installation rather than from ten, and it is not your name, your e-mail or your Apple account. We keep the report for 90 days and use it only to fix the bug.

  There is no setting in the app to turn these diagnostics off.

2. Data We Do Not Collect

• We do not collect your name, email address, or any account credentials.
• We do not sell your location or use it to build a profile of you. It is shared in one narrow way, described in sections 1 and 3: your approximate position is sent to Apple to estimate a drive time.
• We do not use advertising SDKs, and we do not use any third-party analytics or tracking service. Pip does send usage events and crash and performance diagnostics to a server we run ourselves; see section 1.
• We do not sell any data.
• Our server and database receive the usage events and the crash and performance diagnostics described in section 1, and nothing else. They never receive your email address or any account credentials, because the app never asks for them, and they never receive your location.

3. Third-Party Services

Pip uses the following third-party services to provide its features:

• Google Places API: Used to fetch restaurant photos, ratings, opening hours, and price levels. Your search queries (restaurant names) are sent to Google's servers. Google's privacy policy applies: policies.google.com/privacy.
• Apple MapKit / MKDirections: Used to estimate drive times. Your approximate location and the destination are sent to Apple for this. Apple's privacy policy applies: apple.com/legal/privacy.
• Amazon Web Services (AWS): The server and database that receive the usage events and the crash and performance diagnostics described in section 1 run on AWS in the United States (us-east-1).
• Apple App Store lookup: On launch Pip asks Apple's public App Store catalogue for the current version of Pip, so it can tell you when an update is available.
• Pip's own configuration file: On launch Pip fetches a small configuration file from pipfamily.app.

4. Data Storage & Security

All family library data and decision history is stored locally on your device using Apple's secure on-device storage. We do not have access to this data. If you delete the app, all locally stored data is permanently deleted.

The usage events described in section 1 are stored for 365 days, and the crash and performance diagnostics for 90 days. Both are then deleted automatically by the database's built-in time-to-live policy.

5. Children's Privacy

Pip is designed for family use and is not directed at children under 13 as the primary user. The app does not knowingly collect personal information from children. Parents manage the app and its content.

6. Changes to This Policy

We may update this policy as new features are added. The effective date at the top of this page will reflect any changes. Continued use of the app after updates constitutes acceptance of the revised policy.

7. Contact