NearVid

2026-08-17

Apple Podcasts added video in 2026 (and why your RSS feed still needs an audio-only MP3)

Podcasting's default output quietly changed shape in 2026. Recording on camera used to be an extra step some shows did for YouTube clips; this year it became close to a platform default. Apple Podcasts added a real video experience, Spotify said it would adopt the same underlying tech, and Edison Research's own numbers show why both companies moved. None of that changes what a classic podcast RSS feed actually accepts, though — and if your show is edited as a single video file, getting a proper audio-only episode out of it is still a separate step.

What actually changed in 2026

On February 17, Apple's own newsroom announcement introduced HLS-based video playback inside the Podcasts app, with the feature reaching the public release of iOS 26.4 in late March. Apple's framing is worth quoting directly: "Video integrates seamlessly into existing shows without disrupting followers or downloads" — meaning creators publish through the same feed, and Podcasts itself lets listeners switch between watching and listening on the same episode.

Spotify followed a few months later. On May 14, TechCrunch reported that Spotify would adopt Apple's HLS approach for its own video podcasts, letting Spotify-hosted shows distribute and monetize video on Apple Podcasts without changing their existing setup — a genuine cross-platform convergence, not just two companies doing their own separate thing.

The audience numbers explain why both moved when they did. Edison Research's Podcast Consumer 2026 study, announced via press release on June 4, found that weekly podcast consumers are now nearly as likely to say they watch (82%) as to say they listen to audio only (78%) — parity that didn't exist a couple of years back. Separately, coverage of the same research in Inside Radio puts a number on the platform shift specifically: 37% of weekly podcast consumers now pick YouTube as the service they use most often, up from 31% two years earlier — enough to overtake Spotify's previous lead in that particular measure.

None of that changes what an audio RSS feed accepts

Video parity at the audience level, and video support inside Apple's own app, are both real. What hasn't moved is the technical spec behind the classic podcast RSS feed — the one Overcast, Pocket Casts, in-car podcast apps, and plenty of listeners on Apple Podcasts and Spotify's audio tier still use. Apple's own audio requirements page for Apple Podcasts Connect still lists exactly two accepted formats for an episode's audio file: MP3 or AAC, with mono recommended at 64–128 kbps and stereo at 128–256 kbps, sampled at 44.1 or 48 kHz. A video file, however it's wrapped or encoded, isn't on that list — the RSS enclosure an audio-only app reads is still expected to be an audio file, not a video track with the picture stripped out at playback time.

In other words, 2026 added a video feed on top of podcasting's usual distribution, rather than replacing the audio one. If your show is recorded and edited as a single video file — through Zoom, Riverside, StreamYard, OBS, or anything similar — that file is exactly right for the video side (YouTube, Apple Podcasts Video, Spotify Video) and exactly wrong, as-is, for the RSS side. Getting a real MP3 out of it is still a step you have to do.

One recording, two publishing jobs Video support is new in 2026 — the audio RSS feed still expects its own file Recorded episode (video file) Publish as video YouTube, Apple Podcasts Video, Spotify Video — same file, unchanged Extract Audio → MP3 Apple Podcasts, Spotify audio, Overcast, Pocket Casts, etc. — done locally, in NearVid MP3 and AAC are the two formats Apple's own RSS spec lists — a video file is neither.
The same edited recording feeds two different publishing paths in 2026: the video file goes out unchanged to video-capable platforms, while the audio RSS feed that older apps and audio-only listeners still rely on needs its own MP3 pulled out of it first.

One recording, two exports

The workflow doesn't change much from what most shows already do — it just adds one local step before the RSS feed gets updated. Record and edit the episode as video the way you already are. Once it's locked, publish that video file as-is to whichever feeds take it now: YouTube, Apple Podcasts Video, Spotify Video. Then, for the audio RSS feed, use NearVid's "Extract audio" card: it pulls out just the audio track and saves it as an MP3, entirely in the browser — the app's own description of the operation is exactly that, "Pull out just the audio track as an MP3." Nothing about that step needs the video file uploaded anywhere.

Unlike NearVid's MP4 conversion — which depends on the browser's own H.264 encoder via WebCodecs and currently only shows up on Chrome and other Chromium-based browsers — Extract Audio runs on the same self-built, GPL-free ffmpeg.wasm engine that handles trimming and WebM conversion, so it works the same way in Firefox or Safari as it does in Chrome. No browser-support gate to worry about for this particular step.

One real limitation worth knowing before you start: NearVid's Extract Audio operation runs on the whole file — it doesn't expose the same start/end range that the Trim and Convert cards do. If your episode needs a false start or a stretch of dead air cut off the front before it goes out as an MP3, handle that first: trim the video losslessly (stream-copy, no re-encode, same source format, essentially instant), download the shorter file, then run Extract Audio on that trimmed clip. It's two short operations instead of one, but both stay entirely on your device either way.

Why local processing matters more here than for an average clip

An unpublished episode is a different kind of file than a random screen recording or vacation clip. It can be an unreleased guest conversation, an ad read that hasn't gone live yet, or a rough cut you're still deciding whether to keep. Running that file through a cloud converter just to pull out an MP3 means a server somewhere briefly holds a copy of content that hasn't been published — for exactly the kind of "quick, low-stakes" step that's easy to route through whatever converter is already open in another tab. NearVid never uploads the file in the first place; extraction happens in the browser tab itself, which is worth remembering specifically because getting the audio out feels like the least sensitive part of putting an episode out.

The honest summary

The facts as of mid-2026: Apple added a real, HLS-based video experience to Apple Podcasts, announced February 17 and live in the public release of iOS 26.4 by late March; Spotify said in May it would adopt the same underlying tech for cross-platform video distribution; and Edison Research's own numbers show weekly podcast consumers now watching (82%) almost as often as they listen (78%), with YouTube specifically up to 37% as the platform used most often, from 31% two years back. None of that changed what Apple's own RSS spec accepts for the audio side of a show — still MP3 or AAC, not video. What NearVid actually does is the small, unglamorous step in between: pull the audio track out of your video file as a real MP3, locally, on any browser, so the file your RSS feed has always expected doesn't depend on uploading the recording anywhere to get it.

Sponsored
← NearVid

This page shows ads only if you consent.