Last Week on My Mac: Discovering discovery

Apps are getting ever more flexible, and in doing so they’re also becoming increasingly complex. Gone are the days when they mostly opened files, did things to them, and saved them again. We now expect to be able to use our favourite image editor from inside the Photos app, and to share documents between multiple apps, using features as services in reusable components.

For those of us who used OpenDoc back in the 1990s this is all familiar territory. Intended as Apple’s response to Microsoft’s OLE (Object Linking and Embedding), OpenDoc broke apps down to single-task components that worked together. This was best exemplified in the suite of Internet tools provided collectively as Cyberdog for a brief period in 1996-97. Those included a web browser, FTP and email clients, and a newsreader, that could be embedded in other apps that supported OpenDoc’s Bento format.

When Steve Jobs killed OpenDoc in 1997, few could have envisaged what was to come later in app extensions, or appexes, nor how extensively they have become used by macOS. From speech synthesisers and Blu-ray encoders to wallpapers and widgets, appexes have proliferated far beyond the wildest dreams of the OpenDoc designers, but so little is known about they’re managed by macOS.

macOS Sequoia keeps extensive registries of apps and appexes. The most detailed is the grand database maintained by LaunchServices, only visible through its hidden lsregister command tool. Appexes are the preserve of the PlugInKit registry, which can be dumped using the pluginkit tool. Resource management is performed by RunningBoard and appears inaccessible, as do the activity schedules managed by Duet Activity Scheduler (DAS).

All four registries appear to be constructed afresh during startup, in the case of LaunchServices and PlugInKit by a process of discovery, something I’ll be looking at in more detail in the near future. For PlugInKit, it’s discovery that determines which appex services are offered, whether they’re generators of QuickLook thumbnails or previews, Safari extensions, or file systems such as ExFAT or MS-DOS. The latter are refugees from their former existence as kernel extensions, a route now being followed by macFuse 5.0.

Although the user has limited control over those in System Settings and, in the case of Safari extensions, in Safari’s settings, the PlugInKit registry is designed to operate automatically. If the user does try making changes using pluginkit those are likely to be undone when the registry is next updated, and in any case following reboot.

There are some differences obvious between LaunchServices’ database and PlugInKit’s registry. While LaunchServices comfortably accommodates as many versions of apps that it can find, and offers them as choices for opening documents in the Finder’s contextual menu, PlugInKit makes the user’s life simpler by only offering the latest version of each appex. Given that appexes now include replacements for QuickLook’s qlgenerators, and Spotlight importers, that’s hardly surprising, and the prospect of being offered multiple versions in the Share menu would be overwhelming for any user.

PlugInKit and appexes aren’t recent, and probably date back to OS X 10.9 Mavericks, with their NSExtension property list definitions appearing a year later in Yosemite. In macOS 13 Ventura, Apple augmented that with ExtensionKit and ExtensionFoundations both for creating extensions and the extension points offered by host apps. Appexes now cover many different domains, and have become increasingly popular in third-party products, with some like Eternal Storms’ Yoink relying on them for their tight integration with macOS.

Improving our understanding of appexes and their management by PlugInKit isn’t an academic exercise. Host apps and their extensions don’t always work in perfect harmony. Whether you’re developing either of them, or just trying to cope with their disagreements, insight can be important. Now that Sequoia requires QuickLook thumbnail and preview generation to occur in appexes rather than qlgenerators, the qlmanage command tool is of limited value, and you have to rely on PlugInKit instead.

Once upon a time, Apple used to provide extensive and well-written conceptual documentation, where it explained how Mac OS worked, so that when we came to tackle problems we could fall back on understanding. Now we’re largely left to fend for ourselves, so armed with a forthcoming new version of AppexIndexer, I’m off to discover PlugInKit discovery.