Apple has announced that Chief Design Officer Jony Ive will leave Apple later this year to form an independent design company, which the Financial Times reports will be called LoveFrom. In the wake of the death of Steve Jobs, Ive and his designs were seen as a key factor in Apple’s continued success. His departure, particularly following that of Angela Ahrendts (see “Apple Retail Chief Angela Ahrendts Leaving in April,” 7 February 2019), will undoubtedly send heads spinning, which is why Apple was quick to point out that it would be one of the primary clients of Ive’s new company.

Although Ive was largely responsible for the design of ground-breaking products like the original iMac, iPod, and iPhone, design flops like the iPod Hi-Fi, round Mac Pro, Magic Mouse 2, and first-generation Apple Pencil also occurred during his tenure. Worse, Apple’s fetish for thinness under Ive has driven unpopular technical decisions, such as the loss of the headphone jack on iPhones, the need for many MacBook users to carry dongles, and most notably, the train wreck that is the butterfly keyboard (see “Apple Updates MacBook Pros with 8-core Processors and a Keyboard Fix(?),” 21 May 2019). John Gruber’s commentary at Daring Fireball echoes the post-Jobs wonkiness of Ive’s designs. Reports have indicated that Ive has become less involved with the day-to-day work in recent years, and he has likely felt constrained by his position at Apple. Some will mourn Ive’s departure, but it’s better to see it as a golden opportunity for Apple to chart a new direction in design.

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.

---

Curtis Wilcox is an Apple-focused IT administrator at Harvard University, where he supports classroom instruction, media production, and projects aimed at improving accessibility.

When I hear a term that’s new to me or I’m struggling to find the perfect word for a sentence, I turn to the free Terminology. It’s a powerful utility app for iPhone and iPad from Agile Tortoise, the creator of Drafts.

In much the same way that Drafts gives you a place to start writing, Terminology gives you a launchpad for your word explorations, and its extensible actions are powerful enough that you will usually find what you need.

Terminology Basics

Terminology is, first and foremost, an offline dictionary and thesaurus. After tapping through a quick first-launch guide and searching for a word, it will present you with instantaneous results containing definitions, synonyms, and antonyms.

On top of this, Terminology’s thesaurus results show more- and less-specific words. For example, with the term “dive,” a less-specific word result is “swim,” and more-specific word results include “belly flop,” “jackknife,” and “swan dive.”

Terminology makes it simple to tap into any related words to view their results, arrow back and forth through your history, and, most importantly for me, follow the skein of terms wherever it leads. With the speaker, pencil, and heart icons in the upper right, you can have any word pronounced out loud, add notes to it, and favorite terms you want to revisit later. I find myself mostly relying on my search history in lieu of favorites. Your notes, favorites, history, and settings all sync between your devices using iCloud, so there is no need for an account.

Opening the app, tapping the magnifying glass icon, and typing in the search box isn’t necessarily where you always want to start your word searches. You can jump into the app from its widget (which also serves as a Word of the Day tool) or select a word or phrase in another app, tap Share in the popover to open the share sheet, and use Terminology’s share sheet extension in the top row to jump to the search results. You will need to enable Terminology in the share sheet the first time.

I’ve found this helpful when writing in iOS. If a word or phrase I’ve written doesn’t sound quite right, I can select it, open Terminology from the share sheet, tap around until I find an alternative, copy it to the clipboard with a tap, and paste it into my writing app.

Terminology Actions

All of these features are good, but they’re not quite enough to set Terminology apart from your typical dictionary and thesaurus app from the big names like Merriam-Webster, Dictionary.com or Oxford. Actions are where Terminology really shines, showing itself to be a uniquely powerful tool for writers and word nerds. Actions may seem like a relatively small feature, but for me at least, they’re a game changer for real-life use.

When the dictionary and thesaurus results in Terminology don’t provide what you need, you can tap an action and get immediate results from another source without having to open another app or retype your query. Actions can appear at both the top of the screen (as buttons) and the bottom of a word’s entry (as text links), and you can customize which actions show where.

The free version of Terminology comes with the following actions that all open inline: Look Up (for the built-in system dictionary), Wikipedia, Google, Etymonline (for word history information), IMDb, and Wolfram Alpha. The last one is perhaps the most interesting, since it provides hyphenation rules, first known usage and other etymology information, a word frequency graph, rhymes, lexically close words, anagrams, translations, Internet domains, crossword puzzle clues, the word’s Scrabble score, and the word’s associated telephone keypad digits. Some words even get domain-specific information—try looking up a musical instrument.

Terminology’s Pro Features

Agile Tortoise offers a one-time purchase of Pro features for $1.99. The upgrade unlocks a few things you expect from a simple “support the developer” in-app purchase—a dark mode, the capability to have the app automatically switch between dark and light modes based on lighting conditions, and two alternate app icon options.

Much as the built-in actions differentiate the free version of Terminology from the competition, custom actions are what really make the Pro upgrade worthwhile. You can add new actions with a tap from the action library or build your own from scratch. I’ve never had the need to build my own, but I do use several of the pre-built actions that provide one-tap access to additional data sources like Urban Dictionary and Rhymer. Also, if you, like me, use iOS apps for some of the data sources, such as V for Wikipedia or the WolframAlpha app, Terminology’s custom actions can open results directly in those apps.

Here’s the full list of pre-built actions that Terminology currently offers (free actions are in italics):

• Dictionary
  • Look Up (for the system dictionary)
  • Wordnik
  • Dictionary.com
  • Wiktionary
  • Merriam-Webster
  • Oxford English
  • Websters (1913)
  • Urban Dictionary
  • Free Dictionary
• Thesaurus
  • Thesarus.com
  • Merriam-Webster Thesaurus
  • Free Thesaurus
• Reference
  • Wikipedia
  • Wolfram Alpha
  • Etymonline
  • IMDb
  • Google Scholar
• Search
  • Google
  • YouTube
  • Google Image Search
  • DuckDuckGo
  • Bing
  • ImageNet
• Other
  • Rhymer (for rhymes)
  • RhymeZone
  • Giphy
  • Google Translate
  • TV Tropes
  • Snopes
  • Emojipedia
• Apps
  • Drafts (sends the term to Drafts)
  • Drafts Definition (sends the definition to Drafts)
  • WolframAlpha app
  • V for Wikipedia
  • Wikipedia App

Terminology for macOS

Although Agile Tortoise makes a version of Terminology for macOS, it’s not an app per se. What the company has done instead is make their Terminology dictionary and thesaurus available to add as a search option in Apple’s bundled Dictionary app. This is nice to have, especially for a free download. But you don’t get most of the features of the iOS version of Terminology, and I don’t find myself using it much.

If you do decide to try the macOS version, note that it requires a slightly complicated installation process that involves moving the Terminology.dictionary file to the appropriate folder and then activating Terminology within the Dictionary app’s preferences. Agile Tortoise provides a clear installation guide.

So give the Mac version a try if you like, but I highly recommend Terminology for iOS. It’s free to download from the App Store with an in-app purchase option to unlock the Pro features for $1.99.

---

Timothy Buck is a product manager, podcaster, and writer in San Francisco. He hosts and produces two podcasts, UNCO and Accessible. Follow his work at timothybuck.me.

When Apple updated its iWork apps earlier this year (see “iWork Update Brings iOS Apps Closer to Parity”, 2 April 2019), the “What’s New” pages for Pages 8.0 for the Mac, Pages 5.0 for iOS, and the Pages iCloud app all listed a “Table of Contents view” as the top new feature. Long-time Pages users who merely skimmed those pages can be forgiven for saying, “Wait a minute—I thought Pages could already make tables of contents!”

They would have been right, in part. Pages for the Mac has long been able to insert a table of contents into a document as part of its body text. However, the other versions of Pages could not make them, and the tables of contents that Pages for the Mac inserted into documents, while undeniably helpful for the eventual readers of those documents, were not particularly useful navigation tools for their writers.

The new Table of Contents view in the latest versions of Pages provides that navigational help. Appearing in a sidebar (on the Mac) or in a popover (in iOS and in the iCloud app), the Table of Contents view automatically updates itself as you work on the document and provides a quick way to move around the document—just click or tap an entry in the Table of Contents view to jump to it. As one would hope, populating a Table of Contents view is almost effortless. This new view provides other benefits as well.

Make a Navigable Table of Contents

Tables of contents in Pages are style-based: that is, a Table of Contents view lists those paragraphs in your document that have specific paragraph styles applied to them.

Which styles? That’s up to you. Usually, you want table-of-contents entries to be short headings, so if your document has such headings, and you have applied the same paragraph style to each of those headings, you can select that heading style for inclusion in the Table of Contents view.

You use the Select Styles editor to choose the paragraph styles that your Table of Contents view looks for when it collects its entries. All three Pages apps have an Edit button right at the top of their Table of Contents views that, when clicked or tapped, displays this editor. The editor lists all the paragraph styles in the document with a checkbox by each style: check the box and the paragraphs using that style show up in the Table of Contents view. You can also establish a visual hierarchy among the Table of Contents view’s entries by using the indent and outdent controls associated with each style.

The default Blank template in Pages already includes a set of useful paragraph styles, and four of those styles—Heading, Heading 2, Heading 3, and Heading Red—have been preselected for inclusion in the Blank template’s Table of Contents view. Use those styles in any document based on that template and you’ll automatically have a usable Table of Contents view. Many of the other Pages templates also provide pre-selected table-of-contents styles. Note that it doesn’t matter if you redefine how any of these styles look, or even if you rename them: as long as they’re selected for inclusion, paragraphs using those styles show up in the Table of Contents view.

Include a Table of Contents in a Document’s Text

The new Table of Contents view does not prevent you from including a table of contents within a document’s body text. You can still do that in Pages on the Mac, and you can also now do so in Pages for iOS.

In fact, the new Table of Contents view simplifies the process: place your insertion point where you want the table of contents to appear and then click or tap the Insert Table of Contents button at the bottom of the Table of Contents view in either the Mac or iOS versions, though not in the iCloud app. Doing that inserts all the entries in the document’s Table of Contents view into the document, pre-selected and ready for formatting.

Unfortunately, you don’t have a lot of formatting control over an inserted table of contents. For example, you cannot select individual words or characters within an inserted table of contents, but you can select all the entries at each level of the table of contents. It’s all paragraph formatting, with no character-level overrides.

When you select entries within an inserted table of contents, the Format inspectors both on the Mac and in iOS offer a Text tab that provides these formatting settings:

• You can set the typeface, color, style, and size.
• You can left-, center-, or right-justify the selected entries.
• You can adjust the spacing between lines and paragraphs.
• You can show or hide the page number on which each entry begins.

In addition, with the Format inspector on the Mac, you can set a tab stop that controls where the page numbers appear, and you can set leader lines.

An inserted table of contents’ entries need not match those in the Table of Contents view—in other words, you can use a separate table of contents for navigation than the one you insert in the document. When you select an inserted table of contents, the Format inspectors on both the Mac and in iOS let you customize styles: you can choose a different set of paragraph styles to define the inserted table of contents’ entries. You can also break up the inserted table of contents so that, for example, each section of a document can have its own table of contents.

Why Enhance the Table of Contents Features Now?

Apple has been working hard for a while to bring its iOS iWork apps closer to functional parity with the Mac versions, and you can view the new table-of-contents capabilities in Pages for iOS as just another step in that ongoing project. Why Apple would want to do this is hardly mysterious: with the advent of the iPad Pro line, the company has been repositioning the iPad from being primarily a content-consumption device to being a keyboard-optional mobile productivity device. Making iWork more capable on iPads advances that strategy.

But there’s a bit more going on than that, I think, when it comes to tables of contents in Pages. Of late, Apple has focused more of its energies and resources on its Services business, a business that includes the Apple Books store. Pages has long been capable of exporting documents as EPUBs, the standard format offered by Apple Books, and recently Apple included a new item on Pages for Mac’s File menu and on Pages for iOS’s More (•••) menu: Publish to Apple Books. With that command, Pages users can easily create ebooks for sale or distribution through Apple Books. The latest update to Pages released this week even includes a new Novel ebook template.

Where do the tables of contents in those ebooks come from? From the new, easy-to-use, almost-automatic (if you use the right styles) Table of Contents view. If Apple wants to expand its book store offerings with self-published books, having a robust and user-friendly ebook-authoring app included on every Mac and iOS device couldn’t hurt.

Whether this addition to Pages pays off in this broader way remains to be seen, of course, but even if most users never make an ebook with Pages, many will still find the new Table of Contents view a useful addition. It represents what Apple can do when it’s at its best: providing powerful capabilities in an attractive, easy-to-use package.

Note: Portions of this article are adapted from Take Control of Pages, Second Edition, and are used with permission. The 347-page book provides comprehensive documentation of everything Pages can do, on any platform, so if you need help with creating and manipulating a table of contents—or anything else—purchase a copy.