Dustin Bluck:
Independent podcast apps are not growing as a category. This is not a particular secret, but perhaps you haven’t seen it stated explicitly. It’s the sort of thing that has to be inferred, but there’s plenty of available data if you look for it. While the podcasting sector has seen growth, this has occurred almost entirely on platforms like YouTube, and the independent podcast app userbase has mostly just stood still.
[…]
I’m sure somewhere out there a 21-year-old just downloaded Castro or Pocket Casts for the first time and thinks RSS feeds are awesome (if you are this person, please email me). But every number I can see indicates the userbase is both static and aging. Every new customer I talk to has used some combination of Apple Podcasts, Overcast, Pocket Casts, or Castro for at least the last 5 years if not the last 10.
[…]
Perhaps there are healthy businesses that get very few new users but instead gracefully age with the ones they have. Ferrari maybe? Buddy, smartphone apps are not one of those businesses.
[…]
I would rather work on flashy features to capture new users, but, reality being what it is, I have to think about things in terms of both the health of the ecosystem and what will actually help retain existing podcast app users.
Nick Heer:
Anil Dash wrote, in 2014, that the simple phrase wherever you get your podcasts is a “radical statement”:
[…] Because what it represents is the triumph of exactly the kind of technology that’s supposed to be impossible: open, empowering tech that’s not owned by any one company, that can’t be controlled by any one company, and that allows people to have ownership over their work and their relationship with their audience.
Video podcasting changes that. In its simplest form, it is just a YouTube channel, which means it is siloed and controlled by Google. Spotify also supports video but only in its app.
Ilya Birman:
So Marco described a problem. What if someone manually asks to download an episode when they already have three downloaded? You can’t just immediately delete it to keep things tidy. So what do you do? Marco added a special hidden “episode downloaded manually” flag to the database, so those episodes would not count towards the limit.
This is one more example of how even the most seemingly trivial features require thinking through and accounting for different cases that may not be obvious at first glance. Every user interface designer and product designer should collect and absorb examples like this.
[…]
Finally, Marco’s wife Tiff suggests a solution to all the problems: just don’t let users download more episodes, she said, and show them a message, roughly: “Your episode limit is three, but this would be the fourth, denied”.
Marco liked the solution. I didn’t. Sure, it solves Marco’s problems, but not the user’s.
Marcin Wichary:
Birman presents this as “Let me click,” but I wanted to offer two alternative/complementary principles that helped me before:
- Let me do things in any order. Here’s Google Home app, where I can change the temperature and the time for holding – but if I change the time first, it frustratingly resets when I subsequently change the temperature. It forces one specific order in an interface that suggests any order is okay[…]
- The current action has the most momentum. The user is right there, active, tapping on things, wanting to get stuff done. If Overcast indeed throws a “your episode limit is three” message, then it forces the user to remember how to get to the settings and change it. The momentum is lost. The decisions of past me should not be as important as the decisions of present me.
Marco Arment:
FWIW, the entire strict-limit feature is gone in the pending update (awaiting App Store review). EVERYONE hated it.
Now I’m just displaying the added-manually status in the UI and allowing it to be toggled manually in the “…” menu.
Marco Arment:
I’ve needed to evolve my expectations for what my role in Overcast is.
After building up a large, passionate userbase over a very long time, it’s not really entirely mine anymore. I can’t just do whatever I want with it.
And the growth era of open/RSS/indie/whatever podcast apps is over. The business is now about serving and retaining my existing customers for as long as possible.
So I can add things here and there, very carefully, but I can’t really change anything significant.
Previously:
Business Castro Design Indie Development iOS iOS 26 iOS App Overcast Podcasts Spotify Storage Video YouTube
Howard Oakley:
Since High Sierra and APFS snapshots, accounting for purgeable space has been inconsistent and often misleading. I first reported this over eight years ago in Sierra 10.12.6 and High Sierra 10.13.3, and most recently three years ago in Ventura 13.3.1. This article looks at how this is handled now in Tahoe 26.6.2.
[…]
There is disappointingly little documentation on space management in macOS, and the closest Apple comes to defining purgeable space is in Disk Utility’s Help pages, where it’s stated to be “space that macOS can free up when needed by removing files from your computer (you can’t manually remove the files that are designated purgeable, but macOS removes them as space is required)”.
On the face of it, that includes cache files but not snapshots, as they can be manually removed in Disk Utility, as I’ve discussed in detail here. This is contradicted when using tmutil localsnapshot to make Time Machine snapshots, which reports that “local snapshots are considered purgeable and may be removed at any time by deleted(8)”, as deleted is the purgeable space and cache management service in macOS.
APFS snapshots can also be created by third-party apps that have the appropriate restricted entitlement. Apple doesn’t explain whether those too can be purged by macOS when additional free space is required.
Howard Oakley:
Before macOS will start copying a file to a volume, it checks whether there’s sufficient free space available. I believe this is normally performed by the FileCoordinator API in Foundation, and appears in the log with the subsystem com.apple.foundation.filecoordination.
If there isn’t sufficient free space to accommodate the file to be copied, deleted in the subsystem com.apple.cache_delete checks whether enough space can be freed by purging items known to be purgeable in the destination volume. deleted has a fixed set of services that can be called on to purge items, listed in /System/Library/CacheDelete.
[…]
Space-based purging of Time Machine local snapshots is unreliable. The reason for this is that Time Machine CacheDelete fails to report purgeable space when it’s available. Even when it does work, it can take nearly half an hour for Time Machine CacheDelete to recognise the appearance of purgeable space.
Sometimes you need to do it yourself with Disk Utility.
Previously:
Apple File System (APFS) Disk Utility Mac macOS Tahoe 26 Storage Time Machine
Vlad Fedorov (Hacker News):
On August 17, GitHub experienced an outage that lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world.
[…]
Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages.
[…]
As part of the reliability commitments we made earlier this year, we have focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks. We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.
Alejandro Forero Cuervo:
This is the wrong way to think about this because there’s no such thing as infinite capacity. A large distributed system will be simultaneously mostly idle and (in some subcomponents) overloaded. The root cause is not “a component didn’t have enough capacity (because of auto scaling failures)”, but rather “this complex system collapses (rather than degrade gracefully) when demand exceeds capacity”.
When components reach capacity limits, the excess traffic of the lowest priority should be rejected. Rejected traffic should not be retried — in fact, not only should clients not retry these errors, these errors should cause client-side throttling. Traffic isolation should be applied — if the cause of the overload is a single client/customer system, no other system should be affected.
Nearly a decade ago I wrote about some of the techniques we applied at Google to implement these protections. Most other large internet services have since copied them, afaik.
Previously:
Craft GitHub Microsoft Azure Outage Programming Web
