Smart Polling: The Right Episodes at the Right Time

The Hidden Cost of Blind RSS Polling — and How Smart Frequency Matching Fixes It

RSS polling is the backbone of podcast delivery — every app must periodically check feeds for new episodes. The problem is that most apps poll on a uniform schedule, typically every 30 to 60 minutes, regardless of how often a show actually publishes. A daily news briefing and a quarterly bonus episode get the same treatment: dozens of unnecessary network requests for the show that almost never updates, and just barely adequate coverage for the one that posts every morning at 6 a.m. For listeners with libraries of 50 or 100 subscriptions, this uniformity creates a constant background drain on battery and mobile data — most of it wasted on feeds that have not changed since the last check.

The podcast:updateFrequency tag, introduced as part of the Podcasting 2.0 namespace, gives podcasters a direct channel to communicate their intended publishing cadence. Using the RRULE format from the iCalendar standard, a feed can declare schedules as specific as "every weekday at 7 a.m." or as simple as "weekly." This machine-readable signal is designed precisely for apps to consume — it moves the source of truth about update timing from guesswork or historical inference to an explicit declaration by the person who knows the schedule best: the podcaster. Hosting platforms that support the namespace embed the tag automatically when a show's publishing schedule is configured; for self-hosted feeds, it can be added manually to the channel block.

The Podcast App implements this standard by parsing the podcast:updateFrequency tag during each feed sync and storing the derived interval alongside the subscription record. When scheduling the next background refresh, the app uses the declared frequency rather than a global timer — a show marked as weekly gets its next check scheduled roughly seven days out, while a daily show gets checked the following morning. To prevent edge cases from causing problems, all derived intervals are clamped: no feed is checked more than once every 15 minutes (protecting against malformed or extremely frequent RRULE values) and no feed is left unchecked for longer than 7 days (ensuring even low-frequency shows stay current). This clamping logic means the feature degrades gracefully even if a podcaster inadvertently sets an unusual value.

Used alongside Podping, smart polling delivers the best of both worlds. Podping provides near-real-time delivery for shows on supported hosting platforms — episodes arrive within minutes of publication regardless of the polling schedule. Smart polling picks up the remainder: shows on hosts without Podping support, feed corrections, metadata updates, and chapter file changes that Podping does not always signal. Together, the two systems cover the full spectrum of update patterns across a listener's library, with neither unnecessary redundancy nor coverage gaps. The result is a background sync layer that is both more responsive than traditional polling and meaningfully lighter on the resources that matter most to mobile users.