Query Regarding Background Bluetooth Notification Handling in iOS

Hi,

I am currently working on a mobile application for iOS that involves communication with a Bluetooth peripheral device, specifically a smart analog watch. I have some questions regarding the feasibility of certain aspects of the architecture and would appreciate your guidance.

Project Overview:

  1. Functionality:
  • The application connects to a Bluetooth peripheral (the analog smartwatch) and utilizes the Apple Notification Center Service (ANCS) to broadcast notifications to the peripheral.
  1. Notification Flow:
  • When a notification arrives on the iPhone, and if the peripheral is connected via Bluetooth, ANCS broadcasts the notification to the peripheral.

  • The peripheral sends the notification back to the mobile application via Bluetooth.

  • The mobile application then sends a request to a server, which uses AI to determine if the notification needs to be displayed on the watch.

  • If the server validates the notification, the mobile app triggers a vibration on the watch to indicate the notification.

Current Status:

I can receive notifications from my watch to the mobile application via Bluetooth when the app is in the foreground.

Questions:

I need this notification handling to work in the background or killed mode. My ideal solution involves a background service that, upon receiving a notification from the mobile app, sends a request to the server and, based on the server's response, sends a valid notification back to the watch via Bluetooth.

Is it possible to implement such functionality in iOS? Specifically:

  1. Can an iOS application receive and handle Bluetooth notifications in the background or when the app is terminated?

  2. What are the best practices or recommended approaches for maintaining Bluetooth communication in background or killed mode?

  3. Are there any specific APIs or frameworks that can facilitate this kind of background operation?

Thanks

Answered by Engineer in 795148022

You might have some misunderstandings and misplaced expectations about how ANCS works and what you can accomplish with your app.

To clarify: ANCS is a BLE service provided by iOS by acting as a peripheral advertising the ANCS service. Then your accessory (smart watch) acts as the BLE central and establishes a connection to iOS, and gets notified via certain characteristics to things like incoming calls, messages, and notifications. I am not sure if you are calling the watch a peripheral as a generic term, or you actually mean a BLE peripheral, but for this to work your watch cannot be a BLE peripheral, and must be a central.

With that said, your expected notification flow will run into difficulties when implementing. For starters, your app will need to be in Peripheral mode unless the watch is going to have a dual role capability, act as central for ANCS and a peripheral for the app.

While you could implement all this with the watch being in central and the app in peripheral mode, you will likely run into issues when the app is in the background or terminated, as the advertisements from apps in those states are going to be hashed and can only be read and decoded by other Apple devices. So, that's something you will need to engineer around.

This hashing does not occur if your peripheral app is in the foreground, so that could be the explanation of why it works in the foreground (again, without knowing your implementation details, I can only guess as to what the issues might be)

Coming to your specific questions: while your solution can be implemented, you might run into some difficulties as I explained above. There is some functionality that will work fine when the app is in the background, or terminated by the system. But if the app gets terminated by the user (by swiping it away), then there will be no way your app will continue to work until the user launches it again manually.

In general, it is possible to have apps work with Bluetooth when in the background and terminated by the system. You can find a lot of details in Core Bluetooth Background Processing for iOS Apps

You may specifically want to look at the "Performing Long-Term Actions in the Background" section to learn how to handle the app being terminated by the system.

TN3115: Bluetooth State Restoration App Relaunch Rules explains the conditions where terminated apps will and will not be able to continue working with Bluetooth after termination.


Argun Tekant /  DTS Engineer / Core Technologies

You might have some misunderstandings and misplaced expectations about how ANCS works and what you can accomplish with your app.

To clarify: ANCS is a BLE service provided by iOS by acting as a peripheral advertising the ANCS service. Then your accessory (smart watch) acts as the BLE central and establishes a connection to iOS, and gets notified via certain characteristics to things like incoming calls, messages, and notifications. I am not sure if you are calling the watch a peripheral as a generic term, or you actually mean a BLE peripheral, but for this to work your watch cannot be a BLE peripheral, and must be a central.

With that said, your expected notification flow will run into difficulties when implementing. For starters, your app will need to be in Peripheral mode unless the watch is going to have a dual role capability, act as central for ANCS and a peripheral for the app.

While you could implement all this with the watch being in central and the app in peripheral mode, you will likely run into issues when the app is in the background or terminated, as the advertisements from apps in those states are going to be hashed and can only be read and decoded by other Apple devices. So, that's something you will need to engineer around.

This hashing does not occur if your peripheral app is in the foreground, so that could be the explanation of why it works in the foreground (again, without knowing your implementation details, I can only guess as to what the issues might be)

Coming to your specific questions: while your solution can be implemented, you might run into some difficulties as I explained above. There is some functionality that will work fine when the app is in the background, or terminated by the system. But if the app gets terminated by the user (by swiping it away), then there will be no way your app will continue to work until the user launches it again manually.

In general, it is possible to have apps work with Bluetooth when in the background and terminated by the system. You can find a lot of details in Core Bluetooth Background Processing for iOS Apps

You may specifically want to look at the "Performing Long-Term Actions in the Background" section to learn how to handle the app being terminated by the system.

TN3115: Bluetooth State Restoration App Relaunch Rules explains the conditions where terminated apps will and will not be able to continue working with Bluetooth after termination.


Argun Tekant /  DTS Engineer / Core Technologies

Query Regarding Background Bluetooth Notification Handling in iOS
 
 
Q