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!

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.