Maple Media buys Castro: what publishers should check

Podnews reported on October 12, 2026 that Maple Media bought the Castro podcast app. Apple's current Castro listing provides narrower confirmation by naming Maple Media Apps, LLC as the developer and seller. Publishers should treat the ownership change as a prompt to check distribution in Castro, not assume that rankings, ad products, or measurement changed.

The App Store page contains conflicting ownership metadata. Its seller field names Maple Media Apps, LLC. The copyright line still names Bluck Podcast LLC. Podnews' report says Maple Media already owns Player FM, Podkicker, and Breaker, but it does not quote a Castro or Maple announcement that explains the deal terms or product roadmap.

What the public record confirms

Maple Media describes itself as a company that acquires and operates mobile apps, and Apple's listing puts Castro under Maple Media Apps, LLC. It also shows that the app remains available. The Castro website still presents the queue, subscriptions, playback controls, CarPlay, Apple Watch support, and Castro Plus to listeners.

The listings do not establish a new analytics method, changed feed ingestion, a ranking change, or a new advertising product. Nor do Castro's website and App Store listing publish an acquisition transition plan for podcasters.

Run a short distribution check. You do not need to rebuild your analytics or rewrite a sponsor report because an app changed hands.

Run a Castro distribution check

Use one newly published episode and one older episode that still receives meaningful listening. Test both in Castro. Use a device that did not create or edit the show.

1. Check playback from the start and after a seek

Start each episode from zero. Then seek forward, pause, and resume. Keep listening long enough to catch an obvious media-file problem rather than stopping after the player opens. If one episode fails, test the same feed item in another podcast app and at the media URL before blaming Castro.

A Castro-only failure and a feed-wide failure need different owners. Record the app version, device, episode URL, and time of the test. Support will need those details to reproduce it.

2. Compare the visible feed metadata

Check the show title, episode title, publication date, description, artwork, and chapter display against the feed you intended to publish. A stale image or description may come from the app's cached copy, the directory record it reads, or the feed itself.

Do not change the RSS feed yet. First, determine which layer is wrong. Our guide to podcast directory distribution explains why a directory view can lag behind the feed source.

3. Test follow and subscription behavior

Follow the show, close the app, reopen it, and confirm the expected new-episode behavior. Castro says new episodes from subscribed shows appear in its feed. Listeners decide which ones enter the queue. Test that subscription flow instead of expecting every episode to download automatically.

If your team also manages a Player FM listing, review the current Player FM submission guide separately. Shared ownership does not make two listener apps behave as one distribution endpoint.

4. Open every campaign destination

Tap the show website, episode links, and any campaign destination visible in Castro. Confirm three things: the final page loads, the offer is current, and the mobile route preserves the campaign parameters you control.

This does not prove that every listener who heard a message clicked the link. Use the podcast ad attribution guide to keep direct response separate from delivery and broader campaign influence.

5. Save evidence before reporting a problem

Take screenshots of the listing and note the test time. Copy the exact feed item and destination URL into the record. If the issue appears only in Castro, send that evidence through Castro's support route. If it appears in several apps, inspect the hosting feed and media file first.

Keep app behavior and host reporting separate

A listening app can show whether your episode is discoverable and playable in that app. Keep this observation separate from the file requests and other delivery data reported by your host or measurement provider.

IAB Tech Lab's Podcast Measurement Technical Guidelines describe podcast measurement as server-log based and cover downloads, audience, and ad delivery. A successful Castro playback test does not identify the corresponding row in a host report. Nor does a host download prove that a person completed the episode in Castro.

Use the podcast analytics guide to label each source and metric instead of combining app observations with host downloads. If your host numbers move after the ownership report, check the feed, release cadence, traffic sources, and measurement setup before attributing the movement to Maple Media.

The same boundary applies to sponsorships. Nothing in the inspected Castro, Maple Media, or Apple pages announces a new Castro ad product or measurement rule. Keep existing campaign definitions in place until a first-party notice or contract changes them.

What to monitor next

Watch the App Store release notes, Castro's website and blog, its support pages, and any first-party Maple Media announcement. A documented change to feed handling, account terms, privacy practices, subscriptions, or playback deserves a new review. A new seller name alone does not tell you which of those systems changed.

For now, save the results of one current-episode test and one back-catalog test. Your immediate distribution check is complete if both play, display the right metadata, and route listeners to the right destinations.

For a consistent host-side baseline while listener apps change around your feed, start with Podder Analytics.