Apple to Deprecate Scripting Languages in Future Versions of macOS

Share

• Facebook
• Twitter
• Reddit

When Apple announces major new versions of macOS, the company often includes details not just about the next release but also about what will come further in the future. The first macOS 10.15 Beta Release Notes has a Deprecations section that says:

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.

What does this note mean?

The most absolute interpretation is to assume that Apple means “[all] future versions” after Catalina won’t include the runtimes necessary to execute scripts written in these scripting languages.

However, Apple has at times deprecated longstanding components without removing them entirely. For instance, when Apple introduced launchd in Mac OS X 10.4 Tiger, it deprecated the venerable cron scheduling system; ten macOS versions later and cron is still humming along, available for users.

So this may all be a tempest in a teapot if Apple doesn’t end up following through on this threat. But that won’t become clear for at least a year, and in the meantime, we’ll all have to ponder the implications if Apple does kick these languages to the curb.

Why remove these scripting languages at all?

Three reasons: security, efficiency, and focus.

These languages are common in Unix-based systems and have been in Mac OS X since 2001, so why remove them now? Apple has progressively changed macOS to make it more secure, and that is likely the company’s primary motivation for this change. Gatekeeper prevents the automatic running of applications from unknown developers, but scripts are just text files that can do a great deal when executed by the scripting language runtime.

Removing scripting languages will also make macOS use less disk space. The runtime programs for each are small, but like all programming languages, they have many code libraries, common tasks script writers can call upon so they don’t have to reinvent a particular wheel. macOS comes with thousands of these library files that total over 150 MB. That’s not a lot in the scheme of things, but it’s also not trivial with an operating system that has to be downloaded millions of times.

Finally, there’s a principle that in business, you should focus on your strengths. Maintaining these languages has not been one of Apple’s; the company has not kept current with updates to the languages, and users can’t easily use standard tools to find and install additional libraries from the vast repositories available.

Who is affected, and what are their options?

How troubling the loss of these scripting languages will be depends on who you are.

Script Writers

The people who know these scripting languages the best will be the least affected. Those who write scripts for Web development, scientific analysis, or to get other work done in their preferred language already know that maintaining the default installations is not one of Apple’s strengths.

For a long time now, serious users of these languages have been installing separate copies in other folders so they can keep them up to date and easily install libraries from the repositories. That will almost certainly remain possible even after Apple removes the default installations.

App Developers

Mac apps are written in compiled languages but sometimes contain scripts within their app bundles to perform specific tasks. Apple’s deprecation notice recommends that developers include the script’s runtime executable within the application; this shifts responsibility to the developers.

Although multiple apps needing their own copies of Perl, for instance, might seem inefficient, developers need to include only the runtime and exact libraries they use, not a full scripting language installation. Some apps have already taken this route to keep using Java, and many modern apps rely on the Electron framework, which includes Node to run JavaScript.

Alternatively, developers can switch to using compiled code, either rewriting scripts from scratch in a different language or using a tool designed to convert a script into a binary executable format.

Mac Administrators

People who manage many computers for a school or business rely on automation, and automation, in turn, makes heavy use of scripting. While most app developers are already accustomed to dealing with Apple’s security measures for compiled code, Mac administrators are not, so it will be much harder for them to kick the scripting habit.

While some admins are fluent in one or more of these scripting languages, many more are like me, knowing just enough to get by and use scripts shared by the community. For instance, Greg Neagle’s Munki is a popular open-source tool for managing Mac software installs written in Python, but you don’t have to be fluent in Python to use it. Admins currently tend to accumulate useful scripts written in a variety of languages, but installing and maintaining multiple languages on every Mac is too much work, so in the future, admins are likely to choose just one, limiting the number of usable tools. For simpler tasks, admins can also switch to using shell scripts, which will be around at least as long as macOS includes the Terminal app.

Apple

Before removing these scripting languages from macOS, Apple will need to address its own reliance on them. Xcode includes many libraries in all three of the mentioned languages, but it should be trivial for Apple to add the runtimes to Xcode’s already enormous install. iMovie includes a lone Perl script, and it wouldn’t surprise me if Apple’s pro apps like Final Cut Pro X and Logic Pro X also contain some.

In addition to Apple’s apps, macOS 10.14 Mojave contains over 175 scripts outside the folders devoted to Perl, Python, and Ruby. Some are a part of the language, just in a different place, but the rest serve varied purposes. Once I realized how many there were, it seemed much less likely that all three languages would be removed in the macOS version after Catalina.

Everyone Else

It’s hard to say how many everyday users rely on at least one app that contains at least one script. For actively maintained apps, the developer will solve this for the end user. For some open-source projects, particularly cross-platform ones for which macOS is not the primary platform, project contributors may not get around to incorporating a solution.

For those cases and for apps that are no longer maintained, there is a solution: install the scripting language yourself. Each scripting language has its own method of Mac installation, but the simplest and most common method is a general package management system like Homebrew. Homebrew itself is made up of Ruby scripts; I expect its developers will heed Apple’s warning and include that runtime before Ruby disappears in a future version of macOS.

If you’re curious how many of your applications contain scripts in these languages, try copying this command and pasting it into Terminal:

find /Applications -type f | while read in ; do if file -b
"${in}" | grep -q 'Perl\|Python\|Ruby' ; then echo "${in}" ; fi ; done

The first parameter after find is the folder to be checked. On my Mac, Plex Media Server contains many Python scripts and BBEdit includes a couple, as do a handful of other applications, generally from smaller companies or open-source projects.

Start Planning

The point of deprecation notices is to give people time to make changes, but typically these notices don’t operate on a fixed schedule. If Apple itself can’t prioritize ending its reliance on scripts or if the company hears from significant constituencies that they’re not ready, one or more of the languages may stick around.

Even if Apple removes all the scripting languages from the macOS 10.16 release in 2020, it won’t be as significant a change as other deprecations, such as the end of 32-bit app support coming to fruition in macOS Catalina. Unlike that change, if Apple removes a scripting language, you can always put it back.

One final note. Swift can be used as a scripting language, and although its runtime isn’t currently included with macOS, it’s possible that Apple will anoint it as the Mac’s scripting language of choice at some point in the future.

---