audioaccessorykit — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited audioaccessorykit (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 2 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Automatic audio switching support and intelligent audio routing inputs for third-party audio accessories. Enables companion apps to register audio accessory configuration with the system, and app extensions to report placement and connected source changes that help the system switch audio output. Available iOS 26.4+ / iPadOS 26.4+.
Beta-sensitive. AudioAccessoryKit is new in iOS 26.4. Re-check current Apple documentation before relying on specific API details.
AudioAccessoryKit builds on top of AccessorySetupKit. The accessory must first be paired via AccessorySetupKit before it can be registered for audio features. The central type is AccessoryControlDevice, which registers a Configuration from the container app and applies ongoing configuration updates from the app extension.
ASAccessory object.
import AccessorySetupKit
import AudioAccessoryKit| Platform | Minimum Version |
|---|---|
| iOS | 26.4+ |
| iPadOS | 26.4+ |
In the current Xcode 26.6 toolchain, AudioAccessoryKit is present in the device SDK but not the iPhone Simulator 26.5 SDK. Use a physical-device destination for this target. If the rest of the app must build for Simulator, isolate target membership or guard the import and implementation with #if canImport(AudioAccessoryKit) and provide a simulator stub.
After pairing via AccessorySetupKit, register the accessory from the container app by passing an AccessoryControlDevice.Configuration that describes the capabilities and any initial state the accessory supports:
let accessory: ASAccessory // Obtained from AccessorySetupKit pairing
let configuration = AccessoryControlDevice.Configuration(
devicePlacement: .offHead,
deviceCapabilities: [.audioSwitching, .placement]
)
try await AccessoryControlDevice.register(accessory, configuration)Registration activates the specified capabilities and gives the system the configuration it needs to participate in audio routing decisions.
In the app extension, access the device's current configuration using the static current(for:) method:
let device = try AccessoryControlDevice.current(for: accessory)
let currentConfig = device.configurationThis returns the AccessoryControlDevice instance associated with the paired ASAccessory. The device exposes both the accessory reference and the current configuration. Apple marks current(for:) as app-extension-only.
In the app extension, push configuration changes to the system with update(_:). Only update fields for capabilities that were declared during registration:
let device = try AccessoryControlDevice.current(for: accessory)
var config = device.configuration
config.devicePlacement = .onHead
try await device.update(config)Treat this as a gated write workflow: confirm registration declared the capability, copy and mutate device.configuration, then try await update(_:). The method returns no configuration value; update an app-side mirror only after the call succeeds. On failure, use the disposition in Error Handling. Apple marks update(_:) as app-extension-only.
Automatic audio switching lets the system intelligently route audio output to the correct device based on placement and connected sources.
Declare .audioSwitching during the canonical registration flow above. Include .placement and an initial placement only when the accessory can report ongoing placement changes.
Automatic switching commonly uses these AccessoryControlDevice.Capabilities:
| Capability | Purpose |
|---|---|
.audioSwitching | Device supports automatic audio switching |
.placement | Device can report its physical placement |
Combine capabilities as needed. Do not declare .placement unless the accessory can keep the system updated with real placement state.
Report the physical position of the accessory from the app extension to help the system make routing decisions. Update placement whenever the accessory detects a position change.
AccessoryControlDevice.Placement defines four cases:
| Placement | Meaning |
|---|---|
.inEar | Accessory is seated in the ear (e.g., earbuds) |
.onHead | Accessory is on the head (e.g., headband headphones) |
.overTheEar | Accessory is over the ear (e.g., over-ear headphones) |
.offHead | Accessory is not being worn |
config.devicePlacement = .inEarApply this mutation within the canonical current→copy→update sequence above.
Common transitions:
.offHead to .onHead or .inEar when the user puts on the accessory.onHead or .inEar to .offHead when removedFor accessories that connect to multiple Bluetooth devices simultaneously, inform the system from the app extension which devices are connected. This lets the system route audio from the appropriate source.
Provide the Bluetooth address of connected devices as Data:
let primaryBTAddress = Data([0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC])
config.primaryAudioSourceDeviceIdentifier = primaryBTAddress
let secondaryBTAddress = Data([0xAB, 0xCD, 0xEF, 0x01, 0x23, 0x45])
config.secondaryAudioSourceDeviceIdentifier = secondaryBTAddressUpdate these identifiers when the Bluetooth connection state changes (new device connects, existing device disconnects), then call the canonical update(_:) sequence.
Automatic switching uses these configuration fields:
| Property | Type | Purpose |
|---|---|---|
deviceCapabilities | Capabilities | Declared device capabilities |
devicePlacement | Placement? | Current physical placement |
primaryAudioSourceDeviceIdentifier | Data? | Primary connected Bluetooth device address |
secondaryAudioSourceDeviceIdentifier | Data? | Secondary connected Bluetooth device address |
In the app extension, inspect the device's declared capabilities through its configuration:
let device = try AccessoryControlDevice.current(for: accessory)
let caps = device.configuration.deviceCapabilities
if caps.contains(.audioSwitching) {
// Device supports automatic audio switching
}
if caps.contains(.placement) {
// Device reports physical placement
}Read the current placement to determine if the accessory is being worn:
let device = try AccessoryControlDevice.current(for: accessory)
if let placement = device.configuration.devicePlacement {
switch placement {
case .inEar, .onHead, .overTheEar:
// Accessory is being worn
break
case .offHead:
// Accessory is not being worn
break
@unknown default:
break
}
}AccessoryControlDevice.Error covers failure cases during registration and updates:
| Error | Cause |
|---|---|
.accessoryNotCapable | Accessory does not support the requested capability |
.invalidRequest | Request parameters are invalid |
.invalidated | Device registration has been invalidated |
.unknown | An unspecified error occurred |
Handle errors from registration and update calls:
let configuration = AccessoryControlDevice.Configuration(
devicePlacement: .offHead,
deviceCapabilities: [.audioSwitching, .placement]
)
do {
try await AccessoryControlDevice.register(accessory, configuration)
} catch let error as AccessoryControlDevice.Error {
switch error {
case .accessoryNotCapable:
// Accessory hardware does not support requested capabilities
break
case .invalidRequest:
// Check registration parameters
break
case .invalidated:
// Coordinate container-app registration again
break
case .unknown:
// Log, surface, or propagate; Apple does not classify this as transient
throw error
@unknown default:
throw error
}
}Do not infer that .invalidated or .unknown is transient. Correct invalid capabilities or request parameters, discard an invalidated handle and notify the container app to re-evaluate registration where appropriate, and surface unspecified errors. Load Error Recovery Patterns for the complete disposition and invalidation handoff.
Register only the ASAccessory returned by a completed AccessorySetupKit pairing.
If registration declares .placement, the extension must update placement on every detected transition using the canonical update sequence.
Clear or replace primary and secondary source identifiers whenever Bluetooth connections change; stale identifiers reduce switching accuracy.
// WRONG -- ignores invalidation, keeps using stale device reference
try await device.update(config) // Throws .invalidated, unhandled
// CORRECT -- discard the handle and let the container re-evaluate registration
do {
try await device.update(config)
} catch AccessoryControlDevice.Error.invalidated {
await notifyContainerAppToReevaluateRegistration(accessory)
}AccessorySetupKit and AudioAccessoryKit importedregister(_: _:) with AccessoryControlDevice.Configurationcurrent(for:) and update(_:).placement capability accompanied by ongoing placement updatesAccessoryControlDevice.Error cases handled, including @unknown defaultupdate(_:) calls use try await and handle errors~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.