App Extensions (.appex) on macOS

App extensions are small, sandboxed executables that let one application inject functionality into another application or into the operating system itself. On disk they appear as .appex bundles nested inside a host app — for example, 1Password for Safari.app/Contents/PlugIns/1Password.appex. The .appex is not a plugin in the classic sense (code loaded into another process); it is a separate process that the system launches on demand and communicates with over XPC.

Core principle

Apple's extension model inverts the old plugin architecture. Instead of a host app loading third-party code into its own address space — a stability and security risk — the system acts as a broker:

1. The containing app ships an .appex bundle declaring an extension point in its Info.plist (for example com.apple.Safari.web-extension or com.apple.authentication-services-credential-provider-ui).
2. When the app is copied to /Applications and launched, the system's plugin registry discovers and registers the extension.
3. When a host (Safari, the system autofill UI, the Share sheet) needs that extension point, the system spawns the .appex as its own sandboxed process and relays messages between host and extension.

The host never executes the extension's code directly. A crashing extension cannot take down its host, and the extension only receives the data the extension point's API contract allows.

Common extension points

Inspecting extensions with pluginkit

The pluginkit command queries the system's extension registry:

bash
# List all registered extensions
pluginkit -m

# Filter for a specific vendor
pluginkit -m | grep -i 1password

# Verbose: show bundle paths and registration state
pluginkit -mv | grep -i safari

An extension that exists on disk but does not appear in pluginkit -m is invisible to the system. Common causes: the containing app was never launched, the app lives outside /Applications (a frequent issue with Nix- or manually-managed installs, since LaunchServices scans standard locations), or the app simply does not ship that extension.

Practical example: locating a credential provider

Whether a password manager can appear in System Settings → AutoFill & Passwords depends entirely on whether its app bundle ships a credential-provider .appex:

bash
# Does the app ship any extensions?
find /Applications/1Password.app -name "*.appex"

# (returns nothing on macOS — 1Password ships no credential
# provider on Mac, so it cannot appear in that Settings list)

This is the diagnostic logic behind the Password AutoFill Providers on macOS and iOS asymmetry: no .appex, no system integration, regardless of any user setting.

Related

• Password AutoFill Providers on macOS and iOS