As noted by Michael Tsai, in the Xcode 11 beta release notes, Apple notified us that scripting runtimes will be removed from “future versions” of macOS. I previously linked Dr. Drang’s thoughts on this as well:
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of macOS, scripting language runtimes won’t be available by default, and may require you to install an additional package. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
Considering how integral these runtimes are to my own daily use of my Mac, this is a real annoyance. I’m fully capable of installing them myself, but I still find the decision baffling.
Consider the things I share right here on my blog. It’s an extensive list, and 90% of these projects rely on Ruby, Python, or Perl to function. Even the ones that don’t require you to go anywhere near the command line use scripting languages in the background to do what they do. So while this might not be a huge blow for me, it’s an impediment to anyone who uses my projects that isn’t a Terminal nerd.
The Markdown Service Tools are one of my most consistently popular projects. Every one of those Services relies on a scripting language, all via Automator. So if the runtimes aren’t available by default, does that mean that Automator won’t have a Run Shell Script action anymore? Or, very likely, that Automator will be no more, replaced by Shortcuts and entirely lacking scripting runtimes?
The announcements also include a switch from Bash to Zsh as the default shell. I’m unclear as to whether bash will be removed from the default install entirely, but doing so would also require many of my projects to be re-tooled for zsh so as not to require every user to install bash just to run a simple shell script. Feasible, but unlikely that I’d ever get around to updating everything that uses bash scripting at its core. Don’t forget, even Homebrew requires Ruby to install itself, so that’s a speed bump to easily installing command line tools.
Marked makes use of the system Ruby runtime when it compiles Scrivener documents for preview, and many of my customers use Custom Processors that rely on scripting runtimes, even if they have limited experience in the shell. Some apps rely so heavily on system runtimes that they’d be crippled without embedding their own runtime. Dropzone, for example, uses Ruby as the base for all of its Destinations, and embedding Ruby in a way that makes it useful to the general population is not a simple task. I’m sure we’ll all figure it out, but I’m also convinced that it’s an unnecessary burden on developers.
So the question is why? I can’t wrap my head around any real benefit to Apple’s line of reasoning on this. They’ve not been great about keeping the runtimes up to date, but that’s actually been a boon, requiring less effort to keep scripts working with every OS release. These runtimes were even touted as a selling point in the past, and Microsoft is just now starting to add tools like this to the default Windows install. And they’re including a sexy Terminal. So why is Apple moving in the opposite direction?
My only guess is that it’s directly related to the iOS-ification of macOS. iOS is based on Unix, just like macOS, but scripting runtimes have never been included (nor are they installable without bundling). So, security? A higher wall on the garden, one more easily controlled? It can’t be about file size, nor complexity for the everyday user. It doesn’t affect either in any measurable way. I don’t have an answer to this question yet, and I don’t know that we’ll ever really get one.
It’s a long list of pitfalls and downsides with no easily grokked upside to the decision. My best hope is that Apple provides the runtimes in a package like the Command Line Tools available through the developer site. Maybe it will be as easy as clicking a PKG file and running the install. But I still can’t figure out why this is a necessary change.
