Podcrate

Podcrate — Privacy Policy

Last updated: 14 August 2026. Published at https://podcrate.app/privacy.

Podcrate is a podcast player for Android. This is the whole of what it does with data.

The short version

Podcrate has no account and no analytics. Your subscriptions, listening positions, downloads, playlists, bookmarks and listening statistics are stored on your device and are not uploaded anywhere. If you install Podcrate on a Wear OS watch, part of your library syncs between your own two devices — that movement, and exactly what makes it, is item 7 under What leaves your device.

Podcrate shows advertising, and the ads are not personalised. A banner appears on the library, episode, downloads and discovery screens — never on the player, never in the car, and never inside or around an episode's audio. Nothing about what you subscribe to, play, or listen to is used to choose an ad, or sent to the ad network. The detail is in Advertising below.

There is exactly one server of ours the app talks to, and only when you search: it signs requests to the Podcast Index directory so that the key for doing so does not have to ship inside the app. It keeps no request logs and stores nothing about you — the detail is in Podcrate's directory service below.

What is stored on your device

Private-feed passwords are encrypted using the Android key store and never leave the device. Exporting your subscriptions as OPML writes feed addresses only, never a password. A full backup file (Settings → Backup) contains your library and settings — it does not contain private-feed passwords or any other credential the app holds (including a Podcast Index API key, if you have entered one), so those are re-entered after a restore.

Files Podcrate writes where you asked it to. Three features write into a folder or file you pick, and they are the only things the app puts outside its own storage: an OPML or backup export, a CSV export of your listening statistics (Listening stats → Export), and — if you switch it on — an automatic backup, which writes one dated file a day into a folder you choose and keeps the newest five. Nothing is written anywhere until you have picked the place, and Android's permission for that folder is one you can withdraw at any time in system settings. Those files are yours: they are not uploaded, and Podcrate never reads a file it did not write except the one you hand it to restore or import.

Uninstalling Podcrate removes all of it, except the files above, which are yours and stay where you put them.

What leaves your device

Podcrate makes the ordinary network requests a podcast app has to make:

  1. To publishers. Fetching a show's RSS feed and downloading or streaming its episode audio, directly from the publisher's own servers or CDN. Nothing is proxied or re-hosted by us. Those servers see the request, the time, and the IP address it came from — exactly as they would if you opened the feed in a browser. Podcrate identifies itself with a User-Agent of Podcrate/<version> (Android; +https://podcrate.app) and sends no identifier of you.
  2. To podcast directories, when you search or browse discovery: Apple's public iTunes Search and top-charts APIs and fyyd — both straight from your device — and the Podcast Index API, which is reached through a service we run (see below). fyyd is asked only when neither of the other two found what you searched for. They receive your search terms and your IP address. Their own privacy policies apply to what they do with that. The "because you follow" row on the discovery screen also asks a directory to look up shows by their feed identifier — the shows your podcasts recommend in their own feeds. Your subscription list is not sent: the recommendations are read out of feeds already on your device, and what the directory is asked is "what show is this?", one identifier at a time. It is not asked at all when data saver is on.
  3. To artwork hosts, to display show and episode covers — again, the publisher's own host.
  4. To Podcrate's directory service (proxy.podcrate.app), for the Podcast Index searches in 2. This is the only service we operate that the app talks to.
  5. To Google's ad network, to fetch the banner. What that request contains — and, more to the point, what it does not — is in Advertising below.
  6. To a Chromecast on your own network, if you ask for one. Casting sends the episode's address, its title, its show's name and its artwork address to the device you picked, so that the device can fetch the audio itself — directly from the publisher, exactly as your phone would have. Nothing about your library, your queue, your positions or your history is sent, and no file on your phone is: a downloaded episode is streamed from the publisher while it plays there, because a Chromecast cannot read your phone's storage. The Cast SDK is Google's and talks to Google's services to discover and connect to devices; Podcrate only ever loads it when you open the cast sheet, and never in the background. Episodes from private feeds are refused rather than cast, because the only way to send one would be to put your login into a URL on your network — see What Podcrate does not do.
  7. To your own paired watch, if you install Podcrate on one. Watch sync moves your subscriptions, queue, listening positions and per-show playback settings between your phone and your watch — and nothing else: bookmarks, playlists, statistics, history, searches and passwords stay on the phone, and the watch sends back only where you are in what you played. It travels over Wear OS's Data Layer, Google's transport for a phone and its paired watch; when the two are not connected directly it can relay through Google's sync service, encrypted in transit. Nothing moves unless a watch you paired, with Podcrate installed on it, takes part — and none of it is an account: delete either app and its copy is gone.

That is the complete list of what Podcrate sends. One thing leaves your device without the app sending it — Google Play's own crash collection, which applies to every app on the store; it has a section of its own under Crash reports.

Podcrate's directory service

It exists for one reason. Podcast Index authenticates with a signed request, so the alternative to signing on a server is shipping the signing key inside the app, where anyone can extract it and spend it. Signing happens on our server instead, and the app carries nothing.

When you search, the search term reaches that server, and so does your IP address, because that is what making a request means. What happens to them:

If it is down, search falls back to Apple and everything you already subscribe to is unaffected — feeds and audio never go through it.

Advertising

Podcrate is free, and the banner is how it is paid for. Ads are served by Google AdMob.

Where they appear. On the library, episodes, downloads and discovery screens, as a banner at the bottom. That list is the whole of it, and it is enforced in the app's code rather than by convention: every other screen is excluded by default, including any screen added in a future version.

Where they never appear. On the player, in car mode, on the transcript screen, in the notification, on the lock screen, or in a widget. Episode audio is never modified and no advertising is ever inserted into or around it. Nothing about advertising ever interrupts, pauses, or delays playback.

They are not personalised, and this is the important one. Podcrate tells Google's ad network to serve non-personalised ads for every request it makes. That means:

What the ad request does contain. Making a request means Google's servers receive your IP address, and the SDK reads your device's advertising ID. On a non-personalised request Google states that this is used for frequency capping, aggregate reporting and detecting invalid traffic, rather than for ad targeting. You can reset that ID, or delete it entirely, in Android's Settings → Privacy → Ads — Podcrate keeps working either way. The SDK also collects the ordinary technical information any ad request carries: device type, operating system version, and whether an ad was shown or clicked.

Google's own description of what it collects for ad serving is at https://business.safety.google/privacy/ and https://support.google.com/admob/answer/9012903. Once a request reaches Google, Google's policies govern it — that is the honest limit of what this page can promise for you, and it is the reason personalisation is switched off before the request is made rather than after.

Consent. In the EEA, the UK and Switzerland, Podcrate asks for consent through Google's consent form before any ad is requested and before the ads SDK is started at all. If consent is refused, or the form cannot be shown for any reason, no ad is requested. You can change or withdraw that consent at any time from Settings → Ads → Ad privacy settings.

No paid removal exists yet. A Premium subscription that removes ads is planned; it does not exist today, and this page will say so when it does.

What Podcrate does not do

Crash reports

Podcrate contains no crash-reporting SDK. We have not added Crashlytics, Sentry, or anything like them, and the app itself never sends us a crash.

One thing happens anyway, and it is not ours to switch off, so it belongs on this page. Google Play collects crash reports for every app on the store, from devices whose owners turned on "share usage and diagnostics data" in their Android settings. If Podcrate crashes on such a device, Play shows us the stack trace — the lines of our own code that failed — along with the device model, the Android version and the app version.

What we get from that is a count and a stack trace. There is no identifier of you in it, we cannot tell which reports came from the same person, and your library, listening history and statistics are not part of it. One honest caveat: a crash message sometimes quotes the thing that caused it, so if a particular feed is what broke the app, that feed's address can appear in the trace. We use these reports for one thing — finding out that a bug exists — and a feed address that turns up in one is a bug to fix, never something to keep or to associate with you.

You control it in Android Settings → Google → Usage & diagnostics, and turning it off there applies to every app on the device, including this one. Google's handling of that data is covered by Google's privacy policy.

If we ever add crash reporting of our own, it will be off until you turn it on, and this page will say so before it ships.

Permissions

Podcrate asks for no location, contacts, microphone, camera or storage permissions.

Children

Podcrate is not directed at children under 13 and collects no personal information from anyone, including children. Advertising is limited to creative rated suitable for teens and below, and — because ads are never personalised — no child's data is used to select one.

When this changes

2 August 2026 — advertising. The previous version of this page said Podcrate contained no advertising SDK and read no advertising identifier. Both were true when written and neither is true now: the app shows a banner, and the ads SDK reads the advertising ID. It was flagged here as planned before it shipped, and it has shipped. What has not changed is the part that matters: nothing about what you listen to leaves your device, and no ad is chosen from it.

2 August 2026 — crash reports. The same day, a Crash reports section was added. Nothing about the app changed to cause it: Google Play has always collected crash reports for every app on the store, and this page simply had not said so. We still ship no crash-reporting SDK of our own.

2 August 2026 — casting. What leaves your device has a sixth entry: a Chromecast you pick, which receives an episode's address and the words describing it so that it can fetch the audio itself. It is the first entry on that list you have to ask for by name. Nothing about your library or your listening is in it, and the Cast module is not even loaded until you open the cast sheet.

2 August 2026 — recommendations, and the chosen audio version. Two additions to the lists above. The discovery screen now has a "because you follow" row, and item 2 of What leaves your device says exactly what it asks a directory and what it does not: your subscription list is never sent, only the identifiers of the shows your own podcasts recommend inside their feeds, one at a time, and nothing at all when data saver is on. Separately, an episode published in more than one version can now have one picked; which one you picked is stored on the device with everything else, and picking one changes only which address the app fetches.

2 August 2026 — starred episodes. The on-device list above gained a line: which episodes you have archived or starred. Both have always been kept the same way as everything else here — on the device, in the same database, uploaded nowhere — and this is the list saying so rather than any change in where anything goes.

An optional sync account is still on the roadmap. It does not exist today, and this page will be updated — with the date above changed — before it ships. Nothing on this page is retroactive: data already on your device stays on your device.

Contact

Questions, or a publisher asking for a show to be delisted: privacy@podcrate.app.