At the 2017 Worldwide Developer Conference (WWDC), Apple announced several big changes that will help podcasters and podcast-consumers. Here’s what you need to know.
WebRTC coming to Safari on macOS and iOS
For a long time, WebRTC has work in Chrome, Firefox, and Opera, on Windows, macOS, Linux, and even Android. But noticeably absent was Safari for macOS and especially for iOS.
Finally making Safari support WebRTC means many of these streaming tools may now be usable on iOS devices! This is great news if you rely on tools like Zencastr, Ringr, or Cast to record multiender conversations with guests or cohosts.
This means, in theory, your guest or cohosts will no longer have to install an app on their mobile device in order to participate in your podcast!
It could even make voice-feedback systems, such as SpeakPipe, work entirely in the browser without the need for apps, plugins, or Adobe Flash!
Redesigned Apple Podcasts app
Apple’s Podcasts app on iOS is still the most popular podcast-consumption method by far. With the redesign iOS 11, it will be easier for subscribers to listen to or resume playback for any of the shows on their device.
The interface is simpler, the display of data is smarter, the experience is smoother, and it will be a whole lot better for seasonal or serialized content!
Updated podcasting spec and iTunes RSS tags
Apple has barely updated the iTunes podcasting spec since they created it in 2005. But with the launch of iOS 11, Apple will support several new and updated RSS tags.
New RSS tags
This is the only show-level tag (also called “channel-level”) Apple added. It sets the type of podcast you have, either
serial. Apple may add more types in the future.
“Episodic” is the default type and it’s the same as what we’ve been using for all shows until now. This is when standalone episodes can be consumed in any order. “Episodic” can have seasons. With or without seasons, the newest episode will be displayed and downloaded first, with the other episodes listed newest to oldest.
“Serial” is the new type and it’s best when your episodes should be displayed and consumed oldest to newest. This is ideal for any podcast that’s best consumed from the beginning of the season or complete series. For example, audio dramas (e.g., The Fall of the House of Sunshine), storytelling (e.g., Serial), or sequential parts (e.g., “How to Podcast” with each episode being a step in the process). This also supports seasons. With or without seasons, the first episode will be downloaded and consumed first.
The rest of these new and updated tags are episode-level (also called item-level).
This tag is for the title of your episode and only the title. There shouldn’t be any episode number, season number, show title, or show abbreviation.
If you use
<itunes:title>, it will take precedence over the standard
<title> tag for each episode, and that can still contain all the other stuff, if you want.
The purpose of this is to get a clean title for the episode to display differently depending on context and other factors.
For example, if the show type is “serial” and you use seasons, “Season #, Episode #” will display above the episode title, and only the episode number will display in the beginning of the title. But if you don’t use seasons, only “Episode #” will display above the episode title, and there won’t be a number displayed in the title.
I like this because it makes the display of titles a whole lot cleaner. And for those rare shows that actually need season and episode number information displayed prominently, Apple Podcasts will handle those nicely.
So if this should contain only the episode title, what about those season and episode numbers? That’s where the next two tags come in.
This tag lets you set the season number to anything greater than zero. Apple Podcasts will group the episodes into seasons and play/download them newest to oldest for episodic show types, or oldest to newest for serial show types.
Apple Podcasts will only display the season number when you have more than one season in your feed. And it displays the season with those episode groups as well as above the title of the currently playing episode.
No matter when you publish an episode in your RSS feed, it will be included with the appropriate season when you use the same season number.
This tag indicates the episode number—anything greater than zero. It’s useful for seasonal, serial, and even non-seasonal or non-serial shows.
The episode number will display with and above the episode title when the show type is serial. Otherwise, it will display only above the title when the show type is episodic.
You may initially be discouraged that this tag supports only numbers above zero. But Apple has accounted for that with another new tag!
This tag can be set to
“Full” is the default episode type and the same as what we’ve published for years. This would be a regular, possibly numbered episode.
“Trailer” is a short episode that could promote either a season or the whole show. It will be displayed more prominently than the rest of the episodes. This could take the place of “episode 0,” if you wanted to do that kind of thing.
“Bonus” is any kind of extra content for a show, such as behind the scenes, Q&A, extras, or anything like that.
Although Apple didn’t clarify, I think “trailer” and “bonus” types will display in relation to their set season and maybe even set episode number. For example, publish a “bonus” episode that uses the same number as another episode, and the episodes may play like this:
- Episode 1
- Episode 2
- Episode 3
- Bonus for episode 3
- Episode 4
- Episode 5
Thus, I think “trailer” episodes will display before their relevant content: before an entire season, or within a season but before the defined episode. And I think “bonus” episodes will display after their relevant content: after an entire season or within a season but after the defined episode.
Apple also changed a couple tags from previous recommendations.
We’ve previously been able to use this tag to force different show notes to display in Apple Podcasts. It could support basic HTML formatting (paragraphs, bold, italic, lists, and links), but was limited to 4,000 characters.
Now, Apple says this should be a short description for the episode. Try to make it only one or two sentences and probably 255 or fewer characters.
This will display with the episode as a short description of the episode’s contents. It will no longer support HTML. If your summaries already contain HTML, then it will be stripped and ignored.
This is a standard RSS tag to contain the entire post. Previously, Apple Podcasts would truncate this text, and that often meant I couldn’t display my full show notes. But in the new update, it seems Apple will display this full content below the episode description and player, and it will support basic HTML formatting (paragraphs, bold, italic, lists, and links). There doesn’t seem to be a character limit.
I think this brings Apple Podcasts in line with how most other podcast apps display the full show notes. (Overcast will even display images!)
Publishing your full notes in this tag will significantly increase the size of your RSS feed, which could be further reason to abandon FeedBurner and ensure you have proper caching on your site or use a reliable third-party feed tool, like Libsyn.
The GUID (globally unique identifier) has been part of the RSS standard for practically forever. I’ve talked frequently about the importance of not changing this tag, especially when you change domains, migrate your feed to a new host or tool, or switch from HTTP to HTTPS. The GUID for each item is how any RSS client (including podcast apps) will know whether that item has already be loaded.
So you could change everything about an episode in your RSS feed, but if the GUID is the same, the episode will not redownload. The inverse is also true. You could change nothing about an episode your RSS feed, but change the GUID—even by only a single character—and that episode will be forced to redownload.
That’s why, for a long time now, I’ve stressed the importance of not changing the GUID except when it’s absolutely necessary to force your audience to redownload an episode (such as when it was so messed up it was unlistenable or unwatchable). But if you change domains, media hosts, feed-creation tools, or anything else about your podcast, the GUID absolutely must remain the same, or else you could force your audience to redownload all your episodes and thus corrupt your stats.
So there’s nothing new about Apple’s advice to “Assign the GUID to an episode only once and never change it.” And their reason is, “Assigning new GUIDs to existing episodes can cause issues with your podcast’s listing.” Or in other words, cause your episodes to display multiple times. But even more interestingly, they pointed out that it “can cause issues with your podcast’s … chart placement in Apple Podcasts.” This makes sense because it means splitting the popularity of a single episode across multiple instances (separate GUIDs), or it means there could be an episode that will seem like it was never downloaded.
Think of it this way. Apple Podcasts doesn’t see unique episodes, it sees GUIDs. So it will track the popularity of a single GUID for many years. But if you change the GUID of that same episode, you’re starting over with tracking and popularity. It’s like throwing the episode’s reputation away and starting over from nothing.
While it may be tempting to do some unethical things with your GUIDs in order to artificially inflate your numbers, this will only hurt your podcast in many ways. The only time you should change the GUID is when it’s absolutely necessary for your audience to be forced to redownload that episode, and they would be grateful for it (such as to fix a corrupted episode).
Podcast cover art size
During Apple’s presentation, they mentioned the 3,000 × 3,000 JPEG or PNG spec for podcast cover art, but they also said, “Under 1 MB.”
Currently, podcast cover art larger than 512 KB in the
<itunes:image> tag has caused feed submission and refreshing issues. My theory is that the feeds are processed linearly, and if there’s a timeout or error anywhere, it prevents any of the following code from being loaded. Because the cover art is loaded near the top of the feed, a bad cover art file can cause issues with the rest of the feed.
But Apple specifically said, “under 1 MB.” That may not be supported right now, but it makes me think it will be supported with the public release of iOS 11 in late 2017.
I really hope this is true because it can be very difficult to compress some 3,000 × 3,000 images below 512 KB and maintain acceptable image quality (some images compress more easily than others).
Consumption analytics from Apple Podcasts
The biggest podcasting news from WWDC, and what you’ve probably already heard about, is Apple’s new Podcast Analytics coming to Podcasts Connect.
When Apple first launched Podcasts Connect in early 2016, I theorized it could be the framework for future stats and other tools. Invited partners have already been able to see download, stream, browse, and even basic demographic stats from iTunes and Apple Podcasts. But the new Podcast Analytics looks like it will be available to all podcasters through their own Podcasts Connect account.
This isn’t simply server-side download data we’ve had for many years (and is mature enough to be trustworthy). But this is specific playback data, limited to Apple Podcasts (and probably iTunes).
Instead of seeing only that an episode was downloaded and how, you’ll be able to see how much of the episode was played after the download (or during a “stream”).
Then, this can show you how many people skip ads or segments, when they abandon the episode, and how many consume the entire thing.
You can learn a whole lot from this data and use it to improve your podcasts. I’ll talk more about that when we real data from these analytics.
You’ll also be able to see how many of your audience are subscribed or not subscribed.
Additionally, Apple will show you the consumption of episodes based on each episodes age, nicely parallel with each other. With this, you would see that one episode reached 500 plays by day 10, while another reached 500 plays by day 6. And these are actual plays since release, not merely downloads.
It also appears you’ll be able to filter data by location (probably countries), platforms (probably iPhone, iPad, macOS, Windows, and such), and even “listeners” (probably subscribers versus nonsubscribers, or maybe even demographic data).
There’s probably even more we’ll be able to see with these stats.
Even though these analytics will be limited to Apple’s own Podcasts apps, that represents 60–70% of all podcast consumption (according to both Blubrry and Libsyn), so it’s a large enough majority—and the largest single platform by far—that it’s reasonable to extrapolate this data to the rest of your audience. However, it’s possible (and maybe even likely) consumers outside the Apple platforms are more faithful to podcast consumption than the more general public using and browsing on the Apple platforms.
This is really exciting because it means podcast analytics will now be more accurate than all other media, except for streaming. For example, you can see whether a banner ad displayed when someone loaded a page, but you can’t know if the person even saw it. Or you can know how many magazines are sold, but you can’t know how many people read them, let alone saw the ads. And you can only assume how many people are watching or listening to broadcast media, but you can’t know whether they skipped the commercials.
This is fantastic for content creators as well as advertisers. I believe it will show that dynamically inserted ads are usually skipped; but personable, host-performed ads are usually consumed. I think it will also show people abandon episodes when podcasters overwhelm their audience with calls to action.
And, I suspect, it may even show greater loyalty to smaller shows.
How and when can you use all this new stuff?
Unfortunately, this will require some patience. Developers already have access to iOS 11 and can test the new Podcasts app, but these new features will be practically useless until iOS 11 is released to the public in Fall, 2017, and then as iOS users upgrade.
The top podcasting tools (such as Blubrry, PowerPress, and Libsyn) are already being tested and updated to support these features. So you won’t get access right away, but you will probably get access before iOS 11 is released. In the meantime, implementing the new RSS tags won’t do anything for you. So please be patient.
The new Podcast Analytics will probably be available at the same time as iOS 11, or shortly after. Apple did say “this year” (2017).
But this does introduce a new problem: how to access your show in Podcasts connect. If someone else submitted your show to Apple, or you lost access to your Apple ID, you may not be able to see these cool new analytics for your show. However, Apple already has a process in place for transferring ownership of apps in the App Store, so I think podcast transfers aren’t very far away.
As tempting as it may be to remove your podcast from Apple Podcasts and resubmit under an Apple ID you control, I strongly advise against that, as you would lose all your ratings, reviews, and ranking for your show. So you’ll have to simply wait.
We also have yet to see how these changes affect podcast SEO, but I’ll share any such updates in Podcasters’ Society and with students of my SEO for Podcasters course.
Watch Apple’s presentation about these podcasting updates
Thank you for the podcast reviews!
- Join me and hundreds of other podcasters at Podcast Movement! Use promo code “noodle” to save 10%!
Need personalized podcasting help?
Ask your questions or share your feedback
- Comment on the shownotes
- Leave a voicemail at (903) 231-2221
- Email feedback@TheAudacitytoPodcast.com (audio files welcome)
Connect with me
- Subscribe to The Audacity to Podcast on Apple Podcasts or on Android.
- Join the Facebook Page and watch live podcasting Q&A on Mondays at 2pm (ET)
- Subscribe on YouTube for video reviews, Q&A, and more
- Follow @theDanielJLewis
This post may contain links to products or services with which I have an affiliate relationship and may receive compensation from your actions through such links. However, I don't let that corrupt my perspective and I don't recommend only affiliates.