Why Small Frictions Matter

When Apple quietly switched Automator’s default shell to zsh, scripts that worked for years silently broke. No warning, no explanation, just a subtle failure. Most users never noticed. Some gave up. A few dug in, found the cause, and rewrote their workflows.

This isn’t a scandal. But it is a signal.

Whether the change was a licensing workaround, an oversight, or something more strategic, the result is the same: less clarity, more dependency, and more hidden cost for anyone trying to build outside the company’s pre-approved patterns.

It’s not about Apple. It’s about a pattern.

In systems across healthcare, technology, education, and policy, we see the same architecture: distributed harm, diffused responsibility, and rewards for not asking why.

Sometimes no one chooses it. Sometimes someone does.

The point isn’t to accuse—it’s to notice. Because noticing is how we start to see the system clearly enough to fix it.

Where the Cost Falls

When a system fails silently after shifting its internal logic, it places the burden of diagnosis on the user. And when the failure mode offers no feedback, the user is left to guess: Is this me? My machine? My OS?

Often, the inferred conclusion, especially for non-technical users, is: Oh, I need to upgrade.

In this way, even small friction can become a form of structural pressure toward hardware replacement, ecosystem lock-in, or conformity with newer tools. Not because it’s necessary, but because the system offered no other path.

This is how quiet technical choices become part of a larger economic mechanism. The cost isn’t just time or confusion, it’s momentum toward decisions the user didn’t consciously make.

That’s the real pattern. And it’s worth seeing clearly.