With well over 400 app extensions and plugins managed by PlugInKit in Sequoia 15.4.1, this article tries to give an overview of their management and control, as well as the diversity of their functions. This follows:

• a general introduction
• an account of discovery and management by PlugInKit
• AppexIndexer to examine appexes known to PlugInKit
• Apple’s appex Home page for developers.

Appex types

Although Apple refers to the type identifier for appexes as NSExtensionPointIdentifier in its developer documentation, where it lists some of them, in macOS this is also synonymous with NSExtensionPointName. In pluginkit dumps, it’s referred to as the SDK, and LaunchServices dumps use both terms, NSExtensionPointName in NSExtensionsAttributes, and NSExtensionPointIdentifier in NSExtension. This is even more confused in the log, where PlugInKit’s entries use the term NSExtensionPointName, but use NSExtensionIdentifier to refer instead to the appex-specific identifier, such as com.apple.iCal.CalendarWidgetExtension.

For the sake of clarity and consistency here, I’ll refer to the appex type identifier as NSExtensionPointName.

Appex locations

Many appexes supplied in macOS are stored as bundles inside dedicated collections such as /System/Library/ExtensionKit/Extensions or in frameworks. Where they are supplied in an app or similar bundle, they’re normally in a PlugIns folder, although according to this article QuickLook generators should be installed in Library/QuickLook, and Spotlight importers in Library/Spotlight.

Types and management

The rest of this article lists appex types, omitting the universal prefix com.apple., according to their management and discovery by PlugInKit during startup. I provide for each, as far as I’m able to tell, the type-specific manager, any controls provided in System Settings or elsewhere, and illustrative examples and other relevant information.

Type-specific managers are those services or subsystems that PlugInKit hands over to during discovery. For example, when it discovers appexes that extend QuickLook by providing either thumbnails or previews, PlugInKit hands those over to com.apple.quicklook.ThumbnailsAgent to manage.

Many appex types aren’t exposed in System Settings, are managed by PlugInKit, but don’t appear to undergo startup discovery. I have relegated those to the appendix at the end. Most of those are single-appex types, and others are only used by macOS.

Appex types that are managed in System Settings and by PlugInKit, and undergo startup discovery:

• FinderSync, managed by the Finder, and controlled in File Providers settings, e.g. Keka Finder Integration
• quicklook.preview, managed by com.apple.quicklook.ThumbnailsAgent, and controlled in Quick Look settings; these are modern substitutes for qlgenerators
• quicklook.thumbnail, managed by com.apple.quicklook.ThumbnailsAgent, and controlled in Quick Look settings; these are modern substitutes for qlgenerators
• ui-services, managed by the Finder, and controlled in Actions settings, includes Markup, ShareSheetUI (not exposed in settings)

Appex types that aren’t managed in System Settings, but are managed by PlugInKit, and undergo startup discovery:

• AppSSO.idp-extension, managed by AppSSOAgent, includes Kerberos and Sign In With Apple; these are single-sign-on extensions
• appstored-services.testflight, managed by appstoreagent; these handle App Store TestFlight
• AudioUnit, managed by AudioComponentRegistrar and axassetsd, for WardaSynthesizer
• AudioUnit-Speech, managed by AudioComponentRegistrar and axassetsd, include KonaSynthesizer and AUSPs
• AudioUnit-UI, managed by AudioComponentRegistrar
• cache_delete_extension, managed by deleted; these support app-specific cache management
• contacts.donation, managed by contactsdonationagent; these exchange info with Contacts
• ctk-tokens, managed by ctkd, include CryptoTokenKit and PlatformSSOToken; these handle tokens for CryptoTokenKit
• diagnosticextensions-service, managed by ControlCenter and diagnosticextensionsd, includes many service-specific Diagnostic Extensions
• email.extension, managed by maild, e.g. SpamSieve; these are Mail plugins
• fileprovider-nonui, managed by the Finder, includes iCloud Drive and PhotosFileProvider
• services, managed by the Finder; none listed
• spotlight.import, managed by mdbulkimport, includes PDFImporter
• spotlight.index, managed by corespotlightd, includes system extensions but not mdimporters
• textinputmethod-services, managed by imklaunchagent, includes many Input Methods
• usernotifications.content-extension, managed by NotificationCenter, includes ContentExtensions
• widgetkit-extension, managed by chronod, includes system and third-party widgets.

Significant appex types that are managed by PlugInKit, but don’t undergo startup discovery:

• appintents-extension, multiple instances
• intents-service, many IntentsExtensions
• photo-editing, Photos editing, controlled in Photos Editing settings
• Safari.extension, Safari extensions, managed in Safari settings
• share-services, many Share extensions, managed in Sharing settings
• widget-extension, only a couple, e.g. iStat Menus.

Appex types that apparently aren’t managed by PlugInKit, but are controlled in System Settings:

• Dock Tiles
• Finder, these are services offered in the Finder’s Services menu
• Spotlight, these are mdimporters.

also Safari.content-blocker, which is managed in Safari settings rather than System Settings.

Appex types that aren’t apparently managed by PlugInKit or controlled in System Settings:

• authentication-services-account-authentication-modification-ui
• authentication-services-credential-provider-ui
• broadcast-services-setupui
• broadcast-services-upload
• callkit.call-directory
• classkit.context-provider
• dt.Xcode.extension.source-editor
• fileprovider-actionsui
• identitylookup.classification-ui
• identitylookup.message-filter
• intents-ui-service
• keyboard-service
• networkextension.app-proxy
• photo-project
• tv-top-shelf

Appendix:

Appex types that aren’t exposed in System Settings, are managed by PlugInKit, but don’t undergo startup discovery

System, multiple appexes:
followup-extension – multiple FollowUpExtensions
lighthouse.SAOrchestratedExtension – multiple Ingestors
message-payload-provider – multiple
mlhost.worker – many ML-related
mlruntime.extension-point-high
mlruntime.extension-point-ondemand
mlruntime.extension-point-restricted
screensaver – several ScreenSavers
Settings.extension.ui – System Settings
storagemanagement – many apps
usernotifications.service – several NotificationServiceExtensions
wallpaper – several Wallpapers

System, single-app extensions:
amsengagementd-extension – Books, News
amsutility-extension – News
app.non-ui-extension – Swift Playground
app.non-ui-extension.multiple-instances – Swift Playground
app.ui-extension.multiple-instances – Swift Playground
applemediaservices.extensions.compose-review – ComposeReviewExtension
askpermission-extension – App Store related
askto.extension – AskToMessagesHost
calendar.EventKitUIRemoteUIService – EventKitUIRemoteUIExtension
calendar.virtualconference – FaceTimeExtension
contact-view – System Service
contacts.avatar-picker-ui – AvatarPickers
deviceactivity.monitor-extension – ScreenTimeDeviceActivityMonitorExtension
deviceactivityui.report-service – DeviceActivityReportService
extension-view-service-sample-rk – RPVideoEditorExtension_macOS, ReplayKit
extensionkit.app-extension-management – AppExtensionManagement
extensionkit.app-extension-settings – ExtensionKit components
facetime.notification – FaceTimeNotificationExtension
feedback.drafting-extension – Feedback
freeform.USD-renderer-remote-UI – USDRendererExtension
fskit.fsmodule – exfat and msdos file systems (File System Extensions)
GenerativePlaygroundUI.remoteUI – Image Playground
groupactivities – FaceTime RemotePeoplePicker
Home.ui-extension.userList – HomeUIUserList
ImagePlayground.NonUIExtension – GPNonUIExtension
ManagedSettings.service – ManagedClientMSExtension
mapkit.private.RemoteUI – MKRemoteUI for MapKit
mobileslideshow.photo-picker – PhotoPicker and PhotosPicker
networkextension.packet-tunnel – network extensions
PaperKit.extension.ui – PaperKitExtension
PassKit.in-app-payment-ui – Wallet
pdfkit-private – PDFExtensionView in PDFKit
people-picker – System Service
people.legacy.extension – PeopleLegacyMessageService
Photos.MacMusicPickerExtension – PhotosMacMusicPickerExtension
preference.security.privacy – Apple Advertising
preference.sharing.service – Media Sharing
private.translation-api-support – TranslationAPISupportExtension
private.translation-ui – Translate
private.voiceshortcuts-ui – three extensions
replaykit.broadcast-picker – RPBroadcastActivityExtension_macOS in ReplayKit
screentime.web-service – ScreenTimeWebExtension.

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.

Sharing: 3D modeling & rendering flow in Figma

Background

Current situation

I have been working for the current company for half a year. I have a clear picture of the working pattern: We are a small design team, but each member has to be responsible for both the UI and UX design for many internal systems.

Some of the design requirements are not complex at all, but the stakeholders want to make the interface aesthetically beautiful and different from other internal systems. In contrast, other demand sides hope designers can provide a clear and understandable solution to tackle the complex interaction flow.

The previous one was much more difficult for me since I was interviewed for the senior UX designer position, and I had not expected to address these design requirements, which may have occurred considerable times.

So it is time-consuming to design a portal website or refine a running internal system since I have to try multiple design solutions to ensure it will be aesthetically beautiful and outstanding.

Ideation

I wonder if 3D pictures could be a great approach to suit this type of design requirements. So I researched external products from large firms, trying to know how they use 3D pictures in their SaaS products.

After collecting and investing in multiple products, I found the patterns:

1. 3D pictures are most likely used in landing pages, login pages, portal pages, and the like;
2. Admin panels and dashboards do not use 3D pictures frequently, but they would appear in entries, feedback, and background decoration.

Conclusion

Based on the pattern above, real working conditions, and small-sized tries, I summarized the first conclusion:

1. 3D pictures are not frequently used on dashboard pages and system admin. However, using 3D pictures could improve the variety of pages. So it is not worth it to spend so much time on it.
2. 3D pictures can effectively meet the expectations of demand sides when they want to make their dashboard and admin pages distinguish from other similar sites.

Difficulties

Since I don’t have skills in 3D design, and my working strength is too high to spend much time learning, modeling, and rendering delicate 3D pictures, I just simply searched 3D visual elements on the Internet and then applied them to my deliverable.

Initially, this approach was workable and can help me complete my work quickly. However, drawbacks are uncovered after multiple uses:

1. Difficulties of matching business contexts. 3D pictures on the Internet support common scenarios well but can’t always precisely describe certain business scenarios.
2. Lack of series of an element. Although we finally found a perfect 3D picture, it is hard to reach other similar elements from the same series, resulting in poor scalability.
3. Risks of infringement. Using 3D pictures on the Internet might cause infringement, so applying it directly consists of potential risks.
4. Inconsistent quality. Free elements are not guaranteed quality and sometimes fail to meet the standards of our design team.

Here, I draw the second conclusion:

Searching for 3D pictures on the Internet has limited effectiveness, so we can’t fully rely on this approach.

After drawing this conclusion, I feel horrible: does it mean that I should strive to learn skills in 3D design? My work strength doesn’t allow me to learn professional 3D software like Cinema 4D or Blender.

After thorough consideration, I think the core demand for me is not to learn 3D software, rather, I should have the ability to gain 3D pictures. Apart from that, the whole process should consist of these features that suit my workflow well:

1. Quick render. Since it is not worth it to spend much time on it during my work time.
2. Consistent style. Ensuring our design has great scalability.
3. Great customizability. It means that I can fully control elements on 3D pictures, ensuring outputs highly represent the business requirements and contexts.

By chance, I know there is a plugin in Figma called “Vector to 3D”. By learning outputs published in the community, it seems that this plugin could meet the features above well, improving my work effectiveness and quality. So I asked my team leader if I could spend some time discovering this plugin and sharing my experiences with team members, and she approved.

Therefore, this post is to record my internal sharing: My experience of how to build 3D modeling & rendering flow in Figma that improves our design effectiveness and quality.

Work with Vector to 3D

Introducing the plugin

This is a paid plugin, we can search for and install it in the Figma community.

The control panel is comprised of three parts: Global, Object, and Animation settings. Here I will simply introduce the interface of the first two parts, ensuring all readers learn what this plugin can make.

For the Global setting, we can adjust the cameras, and background on the “General” panel; apart from that, we can set the render quality and details on the following panel called “Render”; and then we can control lights on the next panel named “Light and Shadow”, this panel supports varies functions of lights, like the number, size, position, strength, color and so forth.

For the Object setting, we can make a 3D model by extruding, inflating, or revolving, and then increase the detail of the model by setting “Mesh Quality”. Moreover, this plugin also supports material settings, like roughness, metallic, transmission, and the like.

These features are more than sufficient to handle nearly all of my design tasks.

Make a template

In this part, I will introduce two functions of this plugin: Save Preset and Template Preset.

Saving preset allows us to memorize the current view, modeling, and material settings of the frame. We can reload all the settings by the next open, even sharing with friends.

Templating Preset is not only the masterpiece of connecting the plugin with Figma but also a key factor in effectively generating 3D pictures.

Once we built a template, the plugin would memorize all the raw object preset, next step, we can replace the raw object with anything else, and succeed the raw object preset to it.

This approach is highly convenient for us when producing 3D elements. We just have to create a template, and then we replace various shapes, finally, we can produce endless 3D elements that fit our actual needs well.

How it works: First, we need to set the frame as a component and make the replaceable element that we want to replace with a new one a child component. (In the following example, I set the square bottom as a replaceable element.)

Second, we duplicate the whole component and tune settings in the plugin, then save it. (In the following example, I make a glass ball and a square bottom base with a metallic surface)

Third, we need to create a bunch of shapes that are to replace the replaceable element, making them an individual component and ensuring their layer number, order, and name are the same as the replaceable element.

Last, we can hold the keys “cmd” + “option”, drag a new shape component to replace the replaceable element, and then reload the model again. Now we can see the new shape is applied to the same presets.

Now we successfully made a template, we can produce endless 3D elements by creating and inserting new shapes.

Actual practice

Here, I will share a case that is already used multiple times in my daily workflow.

In this template, the shape of icons and background are replaceable, generating endless pictures and fitting nearly all of my design tasks. So it can be a resource library, empowering other team members.

Meanwhile, I created a color pattern, which not only can be used to represent states like success, fail, warning, and the like but also can be applied to the system with different color themes, ensuring our outputs are highly scalability.

Benefits

In the post above, we learned the interface of Vector to 3D, how to make a template, and how I use this flow in actual workflow.

We are familiar with the 3D design workflow in Figma. To conclude this post, I’d like to summarize the key advantages of this process.

1. Low learning costs

We can simply recognize that the plugin “Vector to 3D” is a lite version of 3D software, simplifying complex functions from traditional 3D software and keeping essential functions.

2. Full design process within Figma

This workflow allows us to produce great 3D elements that don’t have to leave Figma. Apart from that, we can simply tune colors in Figma, which doesn’t like the traditional workflow that always switches from software to software.

3. High scalability

One of the core features of Vector to 3D is that makes up models from vector shapes, by taking advantage of this, we can efficiently produce 3D pictures that effectively meet our needs and align well with business contexts.

4. Consistent styles

The plugin Vector to 3D can coordinate with the components of Figma, not only remembering global presets like lights and cameras; but also allowing replacements to succeed presets like materials and position from previous elements. By templating these presets, we can endlessly produce 3D pictures with the same style.

This workflow is not only successfully used in my daily work but also influences my colleagues. After this sharing, 50% of my team members purchased and used this plugin in their design tasks.

Solution for non-Figma users

If you or your team are not using Figma for work currently, or you are not a designer but just simply want to try the flow from SVG shapes to 3D models, you can visit the online version of Vector to 3D: https://www.meimu.design/vector-to-3d/

Sharing: 3D modeling & rendering flow on Figma was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.