What Does Apple Actually Require of a Podcast?

What are the actual requirements?

Technical, specific, and unglamorous. Apple's podcast requirements begin with the feed: it must "adhere to RSS 2.0 specifications, be publicly addressable (not password-protected)" and carry a proper XML declaration.

Each episode needs a unique enclosure tag carrying its URL, length and type, and — the requirement that matters most over time — "a globally unique identifier (GUID), which never changes".

Server behaviour is part of the specification rather than an implementation detail. Apple requires support for "HTTP HEAD requests and byte-range requests", which is what allows artwork to display and episodes to stream rather than forcing a full download before playback.

Then a set of conventions that catch people out: "only ASCII filenames and URLs that include a-z, A-Z, or 0-9", case-sensitivity across all XML tags, dates formatted per "RFC 2822 specifications", and XML entities such as ' and " in place of HTML ones. A show also needs artwork meeting Apple's specifications and "at least one episode".

The encoding conventions are the ones that quietly break things. A non-ASCII character in a filename, an inconsistently cased XML tag or a date in the wrong format will not usually produce a clear error message; the feed simply fails to parse or an episode fails to appear, and diagnosing it afterwards is considerably harder than getting it right at the start.

None of it is optional, and all of it is checkable before you agree to record.

Why does the GUID matter so much?

Because it is the only thing that keeps an episode the same episode.

Apple's requirement is emphatic on the point: the identifier "never changes". Where a GUID is stable, a platform can track that episode across feed updates, host migrations and URL changes, preserving its history, its position in listings and any analytics attached to it.

Where a GUID changes — which happens when a show migrates hosts carelessly, or when a content management system regenerates identifiers — platforms see new episodes rather than existing ones. Subscriber counts, play history and rankings can reset, and duplicate entries appear.

For a guest this is the difference between an appearance that remains addressable years later and one that quietly detaches from its own history. It is also a question a guest can ask before booking, and one that distinguishes a show run competently from one run casually.

Host migrations are where this is decided, and they are more common than guests assume. Shows move platforms for price, features or ownership changes, and a migration that preserves identifiers keeps a decade of episodes intact while one that does not can orphan the entire back catalogue in an afternoon.

What do these requirements have to do with a guest?

Everything, indirectly. A guest's appearance is only as durable and as findable as the feed carrying it.

As reported elsewhere in this series, the durable artefact of a podcast appearance is text rather than audio, and Google's episode-level indexing depended on transcription that the discontinued Google Podcasts ecosystem surfaced. What survives all of that is the episode page and the feed entry, both of which depend on the show meeting the specifications above.

A feed that is publicly addressable can be read by anyone, including the crawlers examined throughout this series. A feed behind a password cannot. Stable GUIDs mean the episode keeps its identity; ASCII URLs mean it resolves everywhere; byte-range support means it plays rather than stalls.

None of that is glamorous, and all of it decides whether an appearance is still retrievable when someone goes looking for it.

It also explains an asymmetry in how appearances age. Two guests recorded the same week on two different shows can find, three years later, that one episode is still addressable with a working page and a transcript while the other has vanished into a migrated feed — an outcome decided entirely by technical choices neither guest was consulted about.

What Apple does not require

An audience, a production standard, or any threshold of quality — and the absence is as informative as the requirements.

Nothing in the published technical requirements sets a minimum number of listeners, a minimum episode count beyond one, or a production benchmark. A show with a compliant feed and a single episode meets them.

This is worth holding alongside the pricing report elsewhere in this series, where reported fees for guest appearances ranged from a few hundred dollars to five figures. Nothing about a show's presence in Apple Podcasts indicates that anyone listens to it, because presence requires only that the feed is well formed.

Apple maintains separate content guidelines governing what may be published, which the technical requirements reference and this report does not examine. The point stands: being in the directory is a technical status, not a measure of audience.

This is worth stating because directory listings are routinely used as credentials. Appearing in Apple Podcasts is a fact about a feed, and a media strip citing it as though it were a measure of reach is citing compliance with a technical specification.

The same caution applies to chart screenshots, which as reported elsewhere in this series record momentum in a category on a particular day rather than audience size.

What should a guest check before booking?

Four things, all observable from outside and none requiring the host's cooperation.

Does the show publish an episode page with real text — notes, names, ideally a transcript? That is the artefact that stays findable, as this series has reported repeatedly.

Is the feed public and the back catalogue intact? A show whose older episodes have disappeared has either migrated badly or pruned deliberately, and a guest appearance is the kind of thing that goes missing in both cases.

Does the show report platform-measured numbers — Apple's engaged listeners and average consumption — rather than only downloads? That question, examined earlier in this series, separates shows that measure their audience from shows that quote the metric requiring least of their listeners.

And does anything about the show suggest an actual audience, rather than merely a compliant feed? Directory presence answers the second question and not the first.

All four checks take a few minutes and can be done from the show's public page and feed. None requires trusting anything the host says about their audience, which is the reason to do them.

If a show cannot answer any of them, that is itself an answer about how the episode will be looked after once the recording stops.

What this means for anyone booking appearances

Treat directory presence as a floor rather than a credential. Meeting Apple's requirements means a feed is well formed; it says nothing about whether anyone is listening.

Ask about the technical basics where the appearance matters. Stable GUIDs, a public feed and an indexable episode page are what keep the appearance retrievable, and a show that cannot answer those questions is a show whose archive may not survive its next migration.

Prefer shows that publish text. This is the single most consistent finding in the podcast reports in this series: the conversation is the experience, and the transcript is the asset.

Media Morpheus books podcast appearances. What a booking delivers is an appearance on a real programme before whatever audience it has. Whether that appearance is still findable in three years depends on the show's feed hygiene and publishing practice — which costs nothing to check and is rarely checked.

Methodology and limitations

This report quotes Apple's published podcast requirements documentation on its Apple Podcasts for Creators support site, covering feed specifications, episode identifiers, server behaviour, filename and encoding conventions, artwork and minimum episode count. Four limits apply. First, Apple maintains separate content and subscription guidelines governing what may be published, which the requirements reference and which this report does not examine; rejection reasons on content grounds are outside its scope. Second, the requirements describe Apple Podcasts specifically, and other platforms maintain their own specifications. Third, no data is reported on how often shows fail these requirements, because Apple publishes none. Fourth, platform requirements change without notice and this describes the position at the date of publication.

Conclusion

Apple's requirements for a podcast are technical rather than editorial: a public RSS 2.0 feed, a permanent GUID on every episode, servers that answer HEAD and byte-range requests, ASCII filenames, correctly formatted dates, artwork to specification and at least one episode. Nothing in them concerns audience, production quality or whether the show is any good, which means directory presence is a statement about feed hygiene alone. For a guest, the requirements matter for an indirect reason that runs through every podcast report in this series: the appearance is only as durable as the feed and the episode page carrying it, and the stable identifier Apple insists on is the thing that keeps it retrievable when everything around it changes.

Frequently Asked Questions

Sources

1. official Apple. Podcast requirements, Apple Podcasts for Creators, for feed, identifier, server and artwork requirements.
2. official Apple. Listener analytics, cited for the measured consumption metrics a show can report.