Hardware accessory and Bluetooth App Review checklist

Map accessory types and transports

List every supported device, firmware range, transport, entitlement, and setup path. Bluetooth LE, Bluetooth classic, Wi-Fi setup, MFi protocols, USB, HomeKit, and proprietary cloud pairing should not be treated as one generic accessory feature.

Write down what the app can do before pairing, during pairing, after pairing, after disconnect, and when firmware is incompatible. Reviewers often start in the no-accessory state, so that state must be intentional.

Ask for only the permissions the setup path needs

• Bluetooth prompts should appear with clear accessory context.
• Local network, location, camera, microphone, and notification requests should be tied to visible accessory functions.
• Denied states should explain whether setup can continue manually.
• Accessory names, images, and identifiers should match the real product line.
• Privacy labels should cover diagnostic logs, device identifiers, account linkage, and telemetry.

Design a no-hardware review route

If the reviewer cannot access the physical accessory, the app should still show useful setup explanation, demo mode, sample readings, or screenshots of the paired state. Do not hide the entire product behind a spinner that says searching forever.

AppReviewReady interpretation: a demo mode does not replace real accessory QA, but it helps App Review verify app completeness, metadata truthfulness, privacy disclosures, and support routes.

Run an accessory state matrix

1. Fresh install with Bluetooth off, accessory off, accessory nearby, and accessory already paired.
2. Supported firmware, outdated firmware, unknown device, and wrong account owner.
3. Disconnect during setup, disconnect during active use, and reconnect after app relaunch.
4. Accessory reset, account deletion, transfer to another owner, and support diagnostics export.
5. Denied permissions and revoked permissions from Settings.

Give reviewers enough accessory context

When hardware is required and cannot be sent to Apple, explain exactly what can be verified without it. If Apple asks for a video or additional proof, use the same state matrix rather than a general product demo.

Keep accessory firmware and app release plans synchronized. A firmware update that changes pairing, telemetry, or required permissions can invalidate the review path even when the App Store binary did not change.

If the accessory is sold separately, check that App Store metadata does not imply the app is useful without the required hardware unless a demo or standalone mode truly exists.

Accessory review path:
Accessory model: [name]
Connection path: [AccessorySetupKit, Core Bluetooth, MFi]
Hardware required: [yes/no]
Demo mode: [how to access]
Permissions: [list]
Expected paired state: [screen]
No-hardware fallback: [behavior]