PodSpot is provided by Xadrez Inverso, Lda., operating as FAT Fire Apps ("we", "us", or "our"). This Privacy Policy explains how PodSpot handles information when you use the app.
PodSpot's core Bluetooth device-finding feature runs entirely on your device. We use a small number of third-party services to process purchases and to understand how the app is used, described in detail below. We do not sell your personal data, and we do not track you across other companies' apps and websites.
PodSpot's core function is helping you locate nearby Bluetooth devices, such as headphones and other trackable accessories. The app scans for nearby Bluetooth Low Energy devices and processes device names, device identifiers, and signal strength to estimate proximity. This scanning and matching happens on your device. The list of devices found in a scan is never uploaded anywhere. When you choose a device to track, the app records the name that device advertises and what kind of device it is, as Section 5 describes, and never its identifier.
PodSpot may request access to your device's precise location to help locate a device or to tag a saved location note (see Section 4). Location access is optional and feature-dependent: some location-based features won't work without it, but you're free to decline the permission. We don't operate any servers of our own, so location data isn't transmitted to us, and it is never included in analytics events.
Maps shown in the app are rendered with Apple Maps. When a map loads, Apple receives the standard requests any Apple Maps view makes, under Apple's own privacy policy.
PodSpot lets you save notes about a device's location. A saved record may include a device name, a short description, a timestamp, and optionally map coordinates. This is stored locally on your device and is not transmitted to us or to any third party. Onboarding answers and app preferences are also stored locally.
PodSpot uses PostHog, a product-analytics service, to understand how the app is used. PostHog receives a random identifier that we generate the first time you run the app (a UUID that is not derived from your device or your Apple account), basic device and app information collected by the analytics SDK (such as device model, OS version, and app version), and in-app events such as scans started, scan results shown, saved locations opened, paywall views, and purchase-related events. The app keeps that identifier in your device's keychain, so it stays the same if you delete and reinstall the app, and it can move to a new iPhone in an encrypted backup. It is also the identifier our crash reporter and our subscription provider use for you (below and in Section 7), so that analytics, crash reports and purchases can be matched to one another. Every event necessarily carries your IP address to PostHog, which derives an approximate city-level location from it. When you choose a device to track, events include a general category for it (its brand, its type, and a product family such as "AirPods Pro") and the public Bluetooth company number of its maker, and the event recording that choice also includes the name the device advertises, as shown in the scan list (a name you or its maker gave it, such as "Living Room Speaker"). We use that name only for product analytics: we read the names together, as a count of how often each one appears, to learn which kinds of device people look for so the app can recognise more of them. We do not use it to identify you, to contact you or to advertise to you, we do not combine it with information from outside PodSpot, and we do not sell it or share it with anyone except PostHog, which processes it for us. Analytics events never include your precise location, your saved location notes, your contacts, the identifiers of the devices you scan for, or the names of devices you did not choose. PostHog processes this data on servers in the United States. Analytics are active only in App Store builds; debug and TestFlight builds do not report.
PodSpot uses Bugsnag, a crash-reporting service, to find out when the app crashes or stops responding and why. A crash report contains diagnostic information about the failure: the app version, the device model and OS version, the sequence of screens and in-app events leading up to it, and a technical stack trace. It carries the same identifier the analytics use, and the identifier our subscription provider knows you by, so repeated crashes can be recognised as coming from one person's app and matched to their subscription. A report is sent only when something goes wrong, or when you choose to contact support from inside the app. In that case the report is a diagnostic snapshot rather than a crash: the same categories as a crash report, plus whether the app considers you subscribed, counts and dates describing how you have used the app (launches, paywalls seen, rating prompts, locations saved), and the recent in-app event trail, filed under a reference number that is also placed in your email so support can find it. Nothing is attached to your email. Instead a short summary is placed in the message itself, below where you type, so you can read it and edit or remove any of it before sending: the app version and build, your device model and iOS version, the identifier described above, your RevenueCat identifier (normally the same value) and whether the app considers you subscribed, whether Bluetooth is on and what the last scan did, how many locations you have saved and whether location permission was granted, your language setting, and the reference number. Editing that summary changes your email only: the report described above is filed when you send the message, and it carries somewhat more than the summary does. If you open Contact Us and then cancel, or save the message as a draft, no report is filed at all. It is still filed when your device cannot send mail and we hand you off to another mail app or show you the message to copy, because we cannot tell whether you went on to send it. Crash reports and support snapshots never include your precise location, your saved location notes, your contacts, or the names of the devices you scan for. Bugsnag processes this data on servers in the United States. Unlike analytics, crash reporting is active in TestFlight builds as well as App Store builds, so problems can be found before a release reaches you.
PodSpot passes Apple's AdServices attribution token to RevenueCat, so that an install can be attributed to an Apple Search Ads campaign. The token is issued by Apple, contains no advertising identifier, and is available regardless of your tracking settings.
PodSpot does not track you across apps and websites. It contains no third-party advertising or attribution SDK, it does not collect your device's advertising identifier, and it does not link what it collects here with data collected about you in other companies' apps, websites, or offline properties. It does not share your data with data brokers. Because none of that happens, PodSpot never asks you for permission to track, and the "Allow Apps to Request to Track" setting in your device's Privacy & Security settings has no effect on it. This describes the current version of the app. Versions up to and including 1.03 did include an advertising component, and Section 6 describes it.
If you're a California resident or otherwise covered by a US state privacy law, you can exercise your right to opt out of the sale or sharing of personal information by emailing fatfireapps+support+podspot@gmail.com with the subject line "Do Not Sell or Share My Personal Information". We do not sell personal information for money.
Versions of PodSpot up to and including 1.03 included Meta (Facebook) App Events for advertising attribution. In those versions Meta received the same in-app events listed above, device information collected by its SDK, an anonymous device identifier that Meta itself assigns, and your IP address, and Meta could combine that information with information it collects about you in other apps and on its own services. Those versions did not collect your device's advertising identifier and did not show a tracking prompt. The component was removed in version 1.4.0. If you are still running an earlier version, updating the app stops that sharing.
If you purchase a subscription or one-time unlock, payment is processed by Apple through the App Store. We do not receive your payment card details, Apple ID password, or full Apple account information.
PodSpot uses RevenueCat to validate your entitlement status. RevenueCat receives your purchase and subscription status, product and package identifiers, and a customer identifier needed to keep premium features working. That identifier is the random identifier described in Section 5, not your name, email address or Apple account. RevenueCat passes it to Apple with each purchase, and sends subscription events, such as a trial starting or a renewal, to PostHog under the same identifier, so they can be matched to the in-app events described in Section 5.
PodSpot uses Firebase Remote Config (Google) to remotely deliver feature-flag and paywall values. Remote Config receives standard Firebase instance identifiers to deliver its values and does not store personal data about you beyond what's described above.
If you're a beta tester, PodSpot may be distributed to you through Apple's TestFlight, which processes your email address and app usage data for that purpose.
PodSpot does not use Apple HealthKit, does not require an account or mailing-list signup, does not send push notifications, does not store your photos or files in the cloud. It does not use Sign in with Apple or iCloud syncing. The app's bundle may declare a camera permission, but no active feature in the current version uses the camera; if that changes, this policy will be updated first.
If you ask PodSpot to remind you before a free trial ends, the app schedules one notification on your device. It is created and delivered by your iPhone itself, not sent by us or through any server, and you can turn it off in iOS Settings at any time.
Local app data remains on your device until you delete it or uninstall the app, with one exception: the identifier described in Section 5 is kept in your device's keychain, which iOS does not clear when an app is deleted, so it is still there if you reinstall PodSpot. Data held by our third-party service providers is retained according to each provider's own policies, or as needed to meet legal, tax, or fraud-prevention obligations for purchase records.
You can remove the app's other data by deleting the app. To have the identifier's data deleted from our providers, or to request deletion of any data held by our third-party providers, contact us at fatfireapps+support+podspot@gmail.com.
Our third-party service providers may process data outside your country of residence, including in the United States. Where required, such transfers rely on appropriate safeguards, such as standard contractual clauses or the provider's own certified compliance mechanisms.
PodSpot is not directed at children and we do not knowingly collect personal information from children under 13.
PodSpot relies on Apple's on-device security features, including device encryption, and requires our third-party service providers to protect data in transit using HTTPS/TLS encryption.
We may update this Privacy Policy from time to time. If we make material changes, we will update the effective date above and make the revised policy available through the app or our public policy URL.
September 28, 2026: the device you choose to track is now recorded by name, for product analytics only. When you tap a device in the scan list, the analytics event for that tap includes the name the device advertises, alongside the category and maker number already recorded (Sections 2 and 5). We read these names together, to recognise more kinds of device, and never use them to identify, contact or advertise to you. The names of devices you do not choose are still never uploaded, a device's identifier is never recorded, and crash reports still never include device names.
September 21, 2026: PodSpot now uses one identifier across its services. The random identifier in Section 5 is now kept in your device's keychain, so it stays the same when you delete and reinstall the app, and it is also the identifier our crash reporter and our subscription provider use, so analytics, crash reports and purchases can be matched. It is still generated by the app and is not derived from your device or your Apple account. The same update began recording, when you choose a device to track, what kind of device it is and the public Bluetooth company number of its maker (Sections 2 and 5), and never its name or its identifier.
September 10, 2026: the diagnostic report is filed when you send a support message, not when you open Contact Us. Opening the mail composer and then cancelling, or saving it as a draft, now files nothing at all. Where your device cannot send mail and we hand you off to another mail app or show you the message to copy, the report is still filed, because in those cases we have no way of knowing whether the message reached us.
September 10, 2026: tapping Contact Us no longer attaches a diagnostic file to your email. The summary that used to ride along as a file is now written into the message itself, where you can read it and edit or remove any of it before you send. The diagnostic report filed to Bugsnag also stopped carrying a copy of your subscription details - what you bought, when it renews, which store sold it - because our subscription provider already holds those against the RevenueCat identifier the report names, and one authoritative copy is better than two.
September 3, 2026: the Meta (Facebook) SDK was removed from the app. It was the only component that shared data with a company able to combine it with data from other apps, so with it gone PodSpot no longer tracks you in any sense, and this policy now says so plainly rather than describing what it collected. Advertising measurement is now limited to Apple's own AdServices token for Apple Search Ads.
Earlier the same day this policy was corrected twice, and the record is kept here rather than tidied away. A morning version said the app has no tracking prompt and does not collect your advertising identifier, both true, but it left the impression that no cross-app sharing happened at all; at that point the Meta SDK was still present and still sent an anonymous identifier of its own, so a second version described that sharing plainly. Removing the SDK is what made the simple statement true. Advertising-identifier collection is now switched off explicitly in the app's configuration. We also began disclosing two things this policy had not previously named: the IP address that reaches our analytics provider, and the Apple AdServices attribution token passed to RevenueCat.
September 1, 2026: the Amplitude, Mixpanel, Kochava, and AppRefer services named in earlier versions of this policy were removed from the app. PostHog was added for product analytics. Meta (Facebook) App Events was retained at that time for advertising attribution, and was removed two days later.
If you have any questions about this Privacy Policy, please contact us at:
Xadrez Inverso, Lda. (operating as FAT Fire Apps)