蓝牙设备是否可以在不同应用状态（后台、锁屏、应用被终止）下唤醒 App？

NOTE: The response below was written based on translation.

In the above different scenarios, can the BLE device trigger iOS to wake up, start, or restart the app?

Yes. The document, “TN3115: Bluetooth State Restoration app relaunch rules” has a rundown of the various possible app states and the expected behavior. The one clarification I'll make to it is around the point "App removed from memory". That basically covers any circumstance where the system terminated your app as part of its "normal" operation. The general idea here is that the system shouldn't differentiate between a suspended app and an app that “happens" to not be running due to normal system-level behavior— if it's worth waking your app up, then it's also worth launching it.

If possible, what conditions need to be met for different scenarios (such as CoreBluetooth Background Modes, State Restoration, connection events, etc.)?

The details of what's required are in the "Core Bluetooth Background Processing for iOS Apps" section of the "Core Bluetooth Programming Guide".

If the app has been Force Quit by the user, is there still any official support method to restart the app?

In general, the system tries to avoid relaunching apps that have been Force Quit by the user. In the case of CoreBluetooth, TN3115 does list one exception:

"5. Starting in iOS 26 and iPadOS 26, only apps that use AccessorySetupKit to set up Bluetooth accessories will be relaunched."

Will the lock screen status have additional restrictions on the above behaviors?

Generally speaking, no. Similar to the running/not running case I talked about above, the basic idea is that if it's worth waking an app while the user happens to be actively using their device, then it’s worth waking your app when the user happens to NOT be actively using their device.

However, this does have an exception as well, also mentioned in TN3115:

"4. If the device requires a passcode to unlock, apps will not be relaunched until the device is unlocked for the first time after a restart."

This particular state is known as "Prior to First Unlock" and the problem here is that this is the device’s highest security state where, ideally, as little data as possible is available to the system. That obviously creates a problem since:

• Very few apps are designed to function with only minimal access to their own data.

• Many of our frameworks aren't fully functional, as they don't yet have access to their own data.

I believe that last point actually applies to CoreBluetooth, as accessory pairing data may not be accessible until after the first unlock. However, more broadly, the security and app design issues here are sufficiently problematic that most of our background APIs (including CoreBluetooth) try to simply sidestep the issue and not launch apps prior to the first unlock.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Regarding this behavior, would it be possible to provide a sample project or some example code demonstrating how it works? Also, does this functionality require MFi certification, or is it available to all developers?

Regarding this behavior, would it be possible to provide a sample project or some example code demonstrating how it works?

No, I don't have a current sample.

Also, does this functionality require MFi certification, or is it available to all developers?

This unrelated to MFi and is available to all developers.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Additionally, I’ve noticed that opening the earbuds case can automatically launch the music app. Could we implement something similar, where opening our earbuds (device) automatically launches our app? If so, what would we need to implement, or would users need to perform any setup or grant any permissions?

Additionally, I’ve noticed that opening the earbuds case can automatically launch the music app. Could we implement something similar, where opening our earbuds (device) automatically launches our app? If so, what would we need to implement, or would users need to perform any setup or grant any permissions?

This is a complicated issue, as there are a lot of overlapping behaviors that are caused by very different parts of the system, mixed in with hardware design choices. For example:

...automatically launch the music app

iOS longstanding behavior AVRCP commands go to the current now playing app, with the system defaulting to Music.app if there isn't already an active now playing app.

opening the earbuds case

If you watch the Bluetooth settings screen carefully, you can see that our AirPods are actually connecting/disconnecting based on a combination of the case opening/closing and whether or not both earpods are in the case.

Shifting to here:

Could we implement something similar, where opening our earbuds (device) automatically launches our app? If so, what would we need to implement?

That depends on what you're trying to do. CoreBluetooth will certainly launch apps into the background, but there isn't any way for an app (or an accessory) to launch an app into the foreground. All of this is documented in the links I've already posted.

One comment on the user side:

would users need to perform any setup or grant any permissions?

Alongside the issue above, the user can also create Shortcuts which can be triggered when a Bluetooth accessory connects or disconnects. This is a user-level feature, not an API, but it means there’s another level of custom behavior that can be happening outside of your control.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware