App extensions or appexes perform a wide range of tasks, from providing support for file systems like ExFAT to generating thumbnails for QuickLook and enabling Spotlight to index the contents of files. Although they’re relatively old, macOS made major changes in their management in Ventura, and they’ve become popular in many third-party apps. Despite that, there’s remarkably little information about how appexes are managed. As a result, when they play up it’s not clear what you should do. This article tries to disperse that cloud of unknowing.

There are four relatively unknown services responsible for managing apps, their extensions and related services:

• LaunchServices, which plays a prominent part in managing app launch, and maintains a large and comprehensive database of information about known apps and their extensions;
• RunningBoard, which manages resources such as memory and GPU access for some apps and their extensions;
• PlugInKit, which manages appexes for QuickLook, Spotlight, and many other services;
• Duet Activity Scheduler (DAS), which dispatches and manages background activities.

At the heart of PlugInKit is its management daemon pkd, in /usr/libexec, which relies on working files and folders buried in a locked directory deep in /var/folders. It maintains its own registry of appexes, to which it adds annotations such as when they were last managed, and whether they have been ‘elected’. You can follow activities in the log using the subsystem com.apple.PlugInKit, and exchanges with com.apple.launchservices and PlugInKit’s client services such as com.apple.quicklook.ThumbnailsAgent, responsible for the generation of QuickLook thumbnails for files.

Discovery

Of the four services, only LaunchServices appears to maintain a database that persists across restarts, although it’s rumoured to be stored over more than one database. RunningBoard maintains a list of running processes, DAS maintains a list of activities that it’s scheduled to dispatch, and PlugInKit keeps a registry of appexes, but each of those appears to be built from scratch during startup.

Shortly after user login, PlugInKit is initialised and starts populating its registry by a process of discovery, apparently deriving its information from the LaunchServices database, where each installed appex is detailed. Among the information stored there for appexes is their PlugInKit dictionary (PKDict) with the NSExtensionPointIdentifier that sets what type of appex it is, and their SDK data, repeating that type information as the NSExtensionPointName.

PlugInKit looks up batches of appexes to register, grouped according to their NSExtensionPointName. The first of these is com.apple.textinputmethod-services, providing text input methods such as Vietnamese and Traditional Chinese. After those come com.apple.FinderSync and com.apple.fileprovider-nonui, and so on through a set sequence until ending with com.apple.widgetkit-extension.

Log entries for this discovery phase are remarkable as, provided appexes haven’t changed in the LaunchServices database, entries by PlugInKit are almost identical during every startup. This stability is particularly helpful over appex UUIDs: so long as the appex remains the same, its UUID and order in discovery will be the same as well.

Coverage and versions

Particularly in recent versions of macOS, LaunchServices appears to cast its net widely, adding apps to its database from almost any accessible source. This results in some of the features it supports listing multiple versions of apps, some of which aren’t installed in traditional Applications folders.

PlugInKit’s coverage appears more focussed, and its rules over which appex to use ensure that old versions are excluded. Although old versions are registered during discovery, PlugInKit normally only offers the most recent version and, if there are multiple copies of that, the last registered by its timestamp in the registry. It’s also more conservative about which appexes it recognises: while LaunchServices will happily add apps that aren’t stored in an Applications folder and have never been opened on that Mac, PlugInKit appears more cautious in those it registers.

This is best illustrated in a VM with the host Applications folder shared. Initially, before that folder has been opened in the VM, apps and appexes inside it aren’t offered in the Finder’s Open With menu, and appexes such as a QuickLook thumbnail previewer can’t be used. When that shared folder has been opened in the Finder, LaunchServices makes its apps available through Open With. But the thumbnail previewer is only registered with PlugInKit when its shared parent app has been run in the VM.

Continuous discovery

In addition to startup discovery, PlugInKit has automatic continuous discovery during normal running. This can be seen best when an app containing an appex is installed and launched. LaunchServices adds the new app and its appex to its database, in what its log entries refer to as seeding. This is reported to PlugInKit, which then performs re-discovery for all appexes with the same NSExtensionPointName, so adding the new appex to its registry. During this, PlugInKit informs the service using that type of appex, triggering deployment of the capabilities of the new appex.

For example, launching a new app containing an appex with the NSExtensionPointName of com.apple.quicklook.thumbnail results in LaunchServices adding that app and its appex to its database, then PlugInKit performs another discovery of all appexes with that NSExtensionPointName. When the new appex is added to its registry, PlugInKit informs com.apple.quicklook.ThumbnailsAgent of the new QuickLook thumbnail previewer, so it can be made available for creating thumbnails almost immediately.

Discovery is readily traced in the log, but even simpler to follow by opening successive windows in AppexIndexer, and following the UUIDs given there.

Removal of an app with an enclosed appex is also quickly reflected in PlugInKit’s registry, and the appex’s service is informed immediately to ensure that no attempt is made to run the deleted extension.

Practical consequences

• Features of appexes are made available by the subsystem they act in.
• PlugInKit informs an appex’s subsystem of its availability during discovery.
• PlugInKit’s discovery relies on updates to the LaunchServices database.
• Damage to or dysfunction of the LaunchServices database can therefore block or impair PlugInKit registration, in turn preventing correct function of the appex.
• Resetting the LaunchServices database will inevitably delay PlugInKit’s discovery, and could lead to malfunction of appexes, such as failure to generate QuickLook thumbnails.
• Controlling appexes is currently only available in System Settings > General > Login Items & Extensions.
• Controlling appexes using the pluginkit command tool is only temporary, and any changes made there will be reverted in subsequent discovery.
• Investigating appex problems by examining com.apple.PlugInKit subsystem entries in the log is clear and straightforward, and individual appexes can readily be traced using their UUID.

I’m very grateful to all of you who looked at my little AppexIndexer, and particularly to those who commented and made suggestions. I’m delighted to come back with version 1.0 build 8, which I hope gets closer to what you’ll enjoy using. Its changes include:

• Adding support for appex UUIDs. Although the log tends to censor most clues about which appex an entry is referring to, it’s more likely to give its UUID, and armed with AppexIndexer you can use that to identify the appex in question.
• Providing a range of four sort orders. These are the SDK or type, the name of its parent app, the UUID, and the appex’s display name. Once you have loaded up the list of appexes, you can switch instantly between these sort orders.
• ‘Live’ search for UUIDs, explained below.

Tools at the top of each window include the UUID search box at the top right, four radio buttons at the left to switch between sort orders, and checkboxes for the two content options of showing appex and parent paths, and UUIDs. Start by clicking on the Get Appexes button to populate the window, then you can set it up how you want.

To help distinguish the name of parent apps, there’s a ‘parent’ emoji preceding each. You’ll also notice that SDKs shown now omit the standard com.apple. opening, as that is universal.

As before, AppexIndexer supports mixtures of continuous and discontinuous selection. Copy those you want, and they’ll paste as text containing all the available fields, not just those being displayed at the time.

Search was quite a challenge, and my solution is inspired by that explained by Tiago Gomes Pereira in his Create with Swift blog.

SwiftUI Search on Lists and similar is nothing like macOS Find, and is better-suited to displaying those entries that match in a single field rather than in all their text content. With its new sort options, AppexIndexer should be quick and simple to locate appexes by all criteria except UUID. Rather than requiring the user to paste in the UUID they want to find, this ‘live’ search should produce perfect matches when you’ve only typed in a few characters from the target UUID. Those don’t have to be characters from the start, but can be any from within the UUID. For example, to find the appex with a UUID of E1366424-89DD-4CEB-85D8-C8E00928313F, you could start typing in e1366, or c8e00, etc., as you wish. You don’t need to use capitals either.

Typing the first couple of characters should narrow the list down quickly, and by the third or fourth you should have a perfect match. If you want to return to the full list of appexes, select that appex entry and empty the search box by clicking on the X button at its right and just that single entry will be selected in the full list.

If you type in an incorrect character, you’ll be informed that no results could be found.

AppexIndexer 1.0 build 8 is now available from here: appexindexer108
I’m afraid that it still requires Sonoma 14.6 or later, but hope that you find it efficient in use and a good tool for exploring appexes.

Enjoy!

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.

App extensions, appexes, have become plentiful and widely used by macOS and third-party software, yet discovering and controlling them is patchy and limited. The most coherent access is in System Settings > General > Login Items & Extensions, where some are gathered in the list of Extensions at the end. Others like Safari extensions are controlled in app settings, while most remain hidden out of sight.

To take stock of all these appexes, I turned to the pluginkit command tool, but the lists it generates are seemingly ordered at random, and so extensive that it would require some serious scripting to make any sense. Instead, it’s easier and more effective to put together a little app to do that. So I present you with AppexIndexer, an exploratory utility that displays key information about all appexes recognised by macOS.

Click on its button to Get Appexes and the window below will fill with well over 400 items, arranged in alphabetical order by the first entry in each line, the SDK or NSExtensionPointIdentifier. Some of those should be fairly obvious: for instance, those appexes listed in Photos Editing settings use the com.apple.photo-editing SDK. In a future article I will explore the relationships between settings categories and SDKs given.

Following that comes the display name of that appex, again ordered alphabetically within that SDK group, which should be the same as that used in System Settings. Next comes the path to that appex, so you can inspect it and its Info.plist for further information.

Many appexes also have a parent, so the last two entries given are the name and path to that parent, when they’re available. One quick way to recognise third-party appexes is to glance down the right side of the list, as they invariably have a familiar parent. Appexes built into macOS are far less likely to have parents (and you can read into that what you like!).

Even in a modest installation, you’re likely to see well over 400 in your Mac’s list, from SpamSieve, an Email Extension with the SDK of com.apple.email.extension, through to QuickLook thumbnail previewers, screensavers and wallpaper. I’ve already explained in general terms what these are and how they work, in this article.

One significant feature missing at this stage is Find/Search, which I’m still working on, for LogUI as well. There’s also additional information given by the pluginkit command tool, and more still that’s available from each appex’s Info.plist file inside its bundle. This initial release lets you save the window’s contents using the Save as RTF button, and you can copy any selected entries and paste them as text. Row selection can be continuous using the Shift key, and discontinuous using Command.

Appexes are not only growing in number, but also becoming increasingly important in macOS. In some cases, they include background processes that could be used maliciously as a method of persistence. Although appexes still need to comply with TCC’s strict rules for accessing protected services and data, they can be an effective way to fly under a user’s radar.

AppexIndexer 1.0 build 5 is now available from here: appindexer105
I’m afraid that it requires macOS Sonoma 14.6 or later, to support the features it uses in SwiftUI.

I hope that you find this information of use. Please let me know what features you’d like the app to support, whether you’d like it to access appex property lists, or other useful data, and how you might want to use a future version. While I’ve got my own ideas, I’m interested in yours, and will try to accommodate them.