Integrate AIBuds SDK

Produce a requirement-specific integration tutorial or adapt the consumer app using only documented public modules and APIs.

Workflow

1. Read references/requirements-and-response.md completely.
2. Inspect the consumer app when it is available: deployment target, Swift or Objective-C, dependency manager, lifecycle entry point, current AIBuds dependencies, Bluetooth permissions, background modes, device ownership, and callback architecture.
3. Determine the requested capability set before recommending dependencies. Distinguish:
   • complete SDK adoption;
   • device discovery and connection only;
   • app-owned AI versus an AIBuds AI provider;
   • on-device voice-assistant authentication;
   • optional audio, live streaming, dashboard, crash reporting, or video stabilization.
4. Ask only for missing information that changes the module choice or initialization. Otherwise state reasonable assumptions and proceed.
5. Read references/official-documentation.md completely. Identify and, when web access is available, verify the official documentation pages directly relevant to the requested capabilities.
6. Read references/installation-and-modules.md completely and choose either AllInOne or the smallest sufficient module set. Never add modules merely because they are available.
7. For initialization, scanning, connection, app-owned AI, or voice-assistant authentication, read references/public-integration.md completely. Adapt its public-API patterns to the app rather than imposing a new app architecture.
8. Give a runnable tutorial in the developer's language, with dependency declarations, project configuration, initialization order, feature code, observable success criteria, failure handling, verification steps, and direct links to the most relevant official documentation. Mark placeholders such as the SDK version and app-specific AI client clearly.
9. If the developer asks for code changes, edit only the consumer-side integration and add focused validation. If they ask only for guidance or diagnosis, do not modify files.

Non-disclosure boundary

• Use only public AIBuds modules, types, protocols, methods, properties, callbacks, and documented platform configuration.
• Do not reveal or infer private classes, source structure, transport commands, packet formats, encryption details, authentication algorithms, third-party implementation details, private errors, logs, or call chains.
• Do not reproduce SDK source, decompile binaries, inspect symbol internals, or explain how a public API works behind the boundary.
• If asked for internals, decline that portion briefly and answer through the nearest public contract, supported callback, configuration option, or diagnostic step.
• Treat dependency declarations as packaging contracts, not as permission to describe transitive libraries or their implementation.
• Treat https://docs-aibuds.github.io/ and its public API Reference as publishable sources. Public documentation may explain supported behavior but never authorizes disclosure of anything outside those public pages and interfaces.
• Never include secrets, production credentials, private endpoints, or real device identifiers in examples.

Integration invariants

• Use one explicit SDK version across all selected subspecs; do not invent a version.
• Require iOS 13 or later unless the developer supplies a newer authoritative SDK requirement.
• Configure both required Bluetooth usage descriptions before initialization.
• Enable bluetooth-central only when background BLE behavior is required, and explain why.
• Initialize once, check the returned Bool, and start scanning only after successful initialization.
• Treat deviceDidReady(_:) as the usable-device milestone; a transport connection callback alone is not sufficient.
• Preserve callback object lifetimes and dispatch UI updates to the main queue.
• Check public protocol capabilities instead of force-casting device features.
• Keep app-owned AI credentials and networking outside the AIBuds SDK integration layer.
• After app-owned AI authentication, report only the Boolean result through DeviceServiceAuthAPI.reportSelfAiServiceAuthResult; never pass credentials through that API.

Completion criteria

• The recommended modules exactly match the stated capabilities and explain what was intentionally omitted.
• Installation, permissions, initialization, connection, optional authentication, and validation form a coherent end-to-end path.
• Examples use public contracts only and contain no hidden implementation claims.
• Failure paths cover initialization failure, denied Bluetooth access, scan timeout, unsupported or unready device, disconnection, nullable errors, and any selected optional module.
• The answer separates verified SDK behavior from app-specific decisions and explicitly labels assumptions.
• The answer links the specific official guide or API page that supports each non-trivial selected workflow instead of citing only the documentation homepage.