Discover more from Basta’s Notes
The absolute audacity of Apple Podcasts
A bit of a rant about Apple
Update: I have spoken with someone from Apple and made some corrections to this post. Apple has said that this is not a widespread issue, and I’m inclined to believe them. Their rep has said that they’ll look into the issue of lock-in, and I’ll be happy to retract my criticisms if this is something that’s addressed and documented.
I’ve also removed some of the spicier language and added some clarification from the comments I’ve received. It does sound like more than a few people at Apple have been investigating what I’ve written, and I’ll give them the benefit of the doubt that they’re not bad folks trying to squeeze podcasters for a quick buck.
I’m willing to retract this post entirely if Apple shows that they’re acting in good faith and clears up the lock-in problems (and offers reasonable documentation to their customers). Apple is a behemoth of a company, and an oversight like this is indistinguishable from bad intentions. It’s perhaps a good reminder that the larger our presence is in an industry, the more rigor we must exercise to ensure that we’re doing the right thing.
Apple Podcasts, formerly the podcast feature of iTunes, was once the dominant way to listen to podcasts. And when I say that, I mean overall: they had an overwhelming percentage of market share. In recent years, that was challenged by Spotify, and now they’re somewhere close to 40% of market share.
40% is nothing to shake a stick at. If you entered the podcasting space (like Spotify did) and captured 40% of users, you’d have an amazing product. The problem is what happens when you have an attitude like you own the place.
The disappointing thing about Apple’s dominance has been their lack of improvements since the aughts. In 2017, they updated their RSS extension to add some additional elements, adding support for season and episode numbering (among other minor features). It helped give Apple Podcasts a fresh coat of paint and address some long-standing pain points, like supporting podcasts that aren’t best listened to in reverse-chronological order.
In 2021 (or 2020, I guess—I doubt they wrote all the code in 2021), Apple realized they were playing catch-up and launched an update to their app that added a bunch of new features and changed the way podcasting worked.
Under the hood, Apple stopped having each device request a copy of RSS feeds. Instead, Apple’s servers would request the feed once, and the Apple Podcasts app on your Mac or iOS device would ping Apple for episode updates. On one hand, you could argue this is a good thing (more anonymous if you trust Apple, significant bandwidth savings for hosting services). On the other hand, it means that you now need to trust that Apple isn’t going to do things to your podcasts.
The 2021 update also included some new features. The notable one was that Apple was dipping its toes into podcast hosting. You could sign up to allow Apple to host your show and its audio (for a cool $20/year). In exchange, you could charge a subscription fee to your listeners.
I run Pinecast, a podcast hosting service. Apple’s hosting feature competes directly (well, almost directly, as you’ll see) with Pinecast. It’s a weird situation: they maintain a list of recommended podcast hosting providers (which Pinecast is on!), but then they compete with those services1.
I’ll admit: when Apple announced their 2021 update, I was kind of miffed. Pinecast already has a subscription feature (the Tip Jar). I’d have bent over backwards to integrate Pinecast with whatever Apple was planning to build. Give me a spec and I’ll make it work, and I’ll do it faster than all of their other partners! Alas, Apple YOLOed a solution out into the world and it lived quietly.
I truthfully had completely forgotten about Apple’s hosting feature. Frankly, I didn’t think anyone would actually go use it. This past week, a new Pinecast customer reached out. They were looking to move their show from Apple to Pinecast, and Pinecast’s import tool wasn’t working. Looking into the situation, the problem was spooky.
Pinecast’s import tool allows you to paste an RSS feed into a text input, and the feed details are pulled and populated for a new podcast on Pinecast. All of the audio files are copied over after you review the details. One convenience feature Pinecast offers is that if you paste the Apple Podcasts directory listing instead of the feed URL, I’ll look up the feed URL from the listing and treat it as a redirect. Easy peasy.
This customer was pasting their Apple listing URL, but the import tool was not getting a feed back. In fact, Apple was returning no results for the podcast ID. That’s weird, because visiting the show in your browser shows the podcast’s details.
What I learned is that Apple does not produce an RSS feed for podcasts that they host. That’s right: if you host your show with Apple, the only listeners you can have are folks with the Apple Podcasts app. It’s wild to require listeners to have to have specific hardware in order to listen to a podcast—paid or not.
Alas, it is what it is. My solution was simple: if fetching a feed URL from an Apple Podcast listing failed, I’d hit the cheeky API that Apple uses to power the web UI. This would let me get the show and episode details, and I’d use this to return a synthetic RSS feed to the import tool. Easy enough!
I managed to get this working. The only thing that wasn’t working, though was the audio. Apple provides a HLS playlist URL for episode audio instead of the URL of an audio file. This isn’t ideal. There are no podcast apps (besides Apple Podcasts, apparently) that can play HLS streams. My solution was this: set up a Lambda function that accepts the HLS URL, pull the stream and save it as AAC in an S3 bucket, and return a 302 redirect to the AAC file’s URL. The synthetic feed would simply link to the Lambda function for the audio. The import tool would be none the wiser.
Except, when I crafted the ffmpeg incantation to pull and convert the HLS stream, it errored. I tried some different command line options and it simply refused to play. So I tried in the browser with a HLS player, and it still didn’t play. My last hope was VLC. VLC can play _literally anything_ you throw at it, it seems. And VLC, sure enough, failed to play this HLS stream. What gives?
I signed up for the Apple Podcasters Program (their name for the hosting service) and uploaded a test podcast. When I went to upload my audio file, something jumped out at me: they note that the audio will be protected with DRM. Sure enough, opening the m3u8 playlist, there is Apple Fairplay DRM info. Keep in mind, this is for audio that’s going to be publicly available without a paid subscription.
Here’s what’s fucked about this: once you’ve started using Apple for hosting, you’re stuck—at least as far as the documentation and UI is concerned. You’re permanently locked into using Apple, unless you want to start your podcast over. Maybe you want to accept subscriptions from Android or Spotify users, or you don’t like the UI, or the features aren’t sufficient for you.
The first problem is that there’s no RSS feed. With an RSS feed, returning a 301 redirect allows you to change your feed URL. If you’re moving from Pinecast to Libsyn, Pinecast will happily allow you to redirect your Pinecast feed URL to your new Libsyn feed URL. Every podcast app (including Apple Podcasts) knows what this means, and updates your feed URL so that it only checks Libsyn going forward.
With Apple, there’s no feed, which means there’s no redirects. You can’t switch to anything because there’s nothing to switch with. Even if you were able to copy your show to another hosting service2, your existing subscribers wouldn’t be able to hear any new episodes you post.
The second problem is that you can’t get your own audio files back. Once you’ve uploaded a file to Apple, that file is no longer available to you, and the DRM prevents it from being downloaded by a tool or another hosting service. Only Apple Podcasts can access that audio, even if you’ve chosen to make that audio freely available. Hell, even choosing to download the audio in Apple Podcasts makes it available for offline listening, but doesn’t produce an MP3 or M4A file that you can move around or archive—it retains its DRM.
Update: as some readers have pointed out, you should be keeping your source audio stored. I don’t disagree, but bad stuff happens and sometimes you don’t have your source audio anymore.
What I dislike the most about all of this is that they don’t make this especially clear. At every step, they do tell you the truth (see above). They say that your podcast will be available to listeners on Apple Podcasts,
but they don’t explicitly say that your podcast won’t be available to anyone else3. When you upload your audio, they say it will have DRM, but they don’t make it clear what the consequences of this are. They tell you your show won’t have an RSS feed, but they don’t tell you what you’re giving up by not having one. If you're not privy to what this all means, you can find yourself paying for a service you can't leave. This feels predatory towards paying customers, even if it is unintentional.
Apple is letting people pay $20/year for a service that locks unwitting customers into their ecosystem. They make it essentially impossible to leave, even when they offer no meaningful value-add to folks who have outgrown the offering.
Apple: y’all need to offer a way to leave. Trapping your customers is an incredibly shitty thing to do. The podcast hosting ecosystem has allowed podcasters to move freely between services forever. This should be obvious and documented.
Update: the Apple rep that I spoke with states that it is not their intention to compete with hosting services, but the Apple Podcasters Program offering hosts assets meant for the Apple Podcasts directory and app and offers a subscription option for listeners—two core features of any podcast hosting service.
Even if we assume that the Apple Podcasters Program is meant specifically for folks to offer a subscription option to podcasters, the lock-in issues I’m describing here are still very real. A podcast that you pay to listen to is still a podcast, and the inability to move it to another provider that offers comparable services feels real bad.
It’s also worth noting that this isn’t a viable option because of GUIDs. Each podcast episode has a unique ID, so that if the episode details change, the podcast app doesn’t think it’s a new episode. Manually copying a show over means you’re not retaining a GUID, so even if Apple let you point your listeners at a new feed, all of the episodes would appear as unlistened. RSS feeds are critical to portability.
Update: I’m striking this because they do say “only”, though there’s a compelling argument to be made that this doesn’t make it clear what that actually means.