How to Maintain Background Connection with BLE-Triggered WebSocket Companion Hub for Real-Time Alerts on iOS

Question

Created 2w

Replies 1

Boosts 0

Participants 2

I’m building a companion app that connects to a custom hardware hub (IoT device) used for home safety monitoring. The hub is installed in homes and is responsible for triggering critical alerts like fire alarms, motion detection, door sensor activity, and baby monitor events.

Current Architecture:

The hub initially connects to the app via Bluetooth (BLE) for provisioning (to get Wi-Fi credentials).
Once provisioned, the hub switches to Wi-Fi and communicates with the app via a WebSocket connection to stream real-time event updates.

What I’m Trying to Achieve:

My goal is to maintain background communication with the hub even when the app is not actively in use, in order to:
Receive real-time updates from the hub while the device is locked or the app is in background.
Trigger local notifications immediately when critical sensor events (e.g., fire, motion) occur.
Ensure persistence across backgrounding, app swipes (force close), and device reboots, if possible.

What I'm Observing:

On iOS, WebSocket connection is suspended or dropped shortly after the app goes to the background or is locked.
Even though the I've scheduled periodic fetches, notifications are delayed until the app is reopened, at which point all missed WebSocket messages arrive at once.
If the app is force-closed or after reboot, no reconnection or notification happens at all.

Key Questions I Have:

Since the hub is initially provisioned via BLE, and could potentially send BLE flags or triggers for key events, can I use bluetooth-central mode to keep the app active or wake it up on BLE activity?
Once the hub switches to Wi-Fi and uses WebSocket, is it possible to combine BLE triggers to wake the app and then reconnect to the WebSocket to fetch the full event payload?
Is there a legitimate and App Store-compliant way to maintain a connection or background task with:
- BLE accessory triggers followed by
- Real-time data processing via Wi-Fi/WebSocket?
Would this use case qualify as a "companion device" scenario under iOS background execution policies?
What is the best practice for handling this kind of hybrid BLE + WebSocket alerting flow to ensure timely user notifications, even in background/locked/force-closed states?

Any advice, documentation links, implementation patterns, or examples from similar companion device apps would be greatly appreciated. Thanks in advance!

Boost

Answer 1

Engineer OP

Apple

2w

In order for your app to keep a WebSocket open continuously, it has to be running continuously as well.

While there are certain APIs that will keep your app active in the background, for example continuous location updates for navigation, App Store rules specifically prohibit using a background capability in order to keep the app running for an arbitrary reason unrelated to the purpose of the capability.

As you are using BLE, that could possibly be a solution, in theory. In practice, you would need to start a BLE connection, and have your accessory continuously communicate with your app in order to never let it sleep - during which time you could keep your sockets open.

Except, this will: a) deplete the batteries on both ends rapidly, leaving you with unhappy customers, and b) would be a flimsy solution as a drop in the BLE connection would take longer to re-establish than the time you have before the app in the background is suspended, resulting in your sockets to close.

So, this is not going to be a success the way you are looking at it. Perhaps you can re-architect your solution to let go of the notion of a continuously open WebSocket, and have the accessory wake up your app as necessary when there is an even that the app or the user needs to respond to.

You may want to read about iOS Background Execution Limits for further understanding of the limitations.

Argun Tekant /  DTS Engineer / Core Technologies

2