When you’re building a Bluetooth Low Energy product, one of the earliest and most impactful decisions you’ll make is architectural: how will your device connect and communicate? Will it maintain a persistent connection or advertise periodically, connecting only when needed?
This choice fundamentally shapes your product’s power consumption, responsiveness, and ability to scale. We’ve guided many connected product teams through this decision and seen how getting it right early saves months of rework and how getting it wrong leads to flaky connections, poor battery life, and frustrated users.
This article breaks down the two primary connection strategies (always-connected and dynamic) and the hybrid approaches many real-world products use, so you can make an informed choice that aligns with your product’s goals and constraints.
The Two Primary Strategies
Most BLE products start by choosing between two foundational approaches: maintaining a persistent connection or connecting only when needed. Let’s walk through how each one works and where it makes sense.
Always-Connected
In an always-connected setup, the peripheral and central form a persistent BLE link that stays active as long as possible. Once connected, the device typically stops advertising and focuses on maintaining that connection. If it drops, both sides work to reconnect quickly.
The appeal here is predictability. Data moves at regular, low-latency intervals, making this setup great for products where users expect immediate feedback, like fitness trackers streaming live data or medical devices that need continuous monitoring.
But that reliability costs power. Even when idle, a maintained connection burns through more energy than periodic advertising. For devices running on coin cells or targeting multi-month battery life, that overhead adds up fast.
Scalability can also become a constraint. Phones typically support at most seven or eight simultaneous BLE connections, and some OS versions or device models allow even fewer. Since each always-connected device occupies one of those slots, systems with multiple peripherals can hit limits quickly.
Background behavior adds more complexity. Mobile OSes often drop connections after inactivity, backgrounding, or Bluetooth toggling, so reconnection logic needs to be robust and transparent to the user.
Use this approach when:
- Data moves frequently or continuously
- Users expect instant, low-latency feedback
- Power budget can handle the idle cost
- You’re working in a simple 1:1 or 1:few topology
Dynamic (Intermittent)
Dynamic architectures connect only when needed. The peripheral advertises periodically, either at a steady cadence or triggered by events, and disconnects once data exchange is complete.
This setup trades immediacy for efficiency. Without a persistent link, you save significant power during idle periods, making this approach ideal for sensors, trackers, or other devices that wake occasionally to send data. A well-tuned advertising strategy can stretch battery life from weeks to months or even years.
The tradeoff is latency: establishing a connection adds a second or two before data can move. That delay might not matter for periodic syncs or background data but feels sluggish for real-time control or feedback.
Dynamic systems also depend on how reliably the phone can discover the peripheral. iOS and Android scan on their own schedules, and background scanning can be slower or inconsistent across devices. Designing around that variability is key.
Use this approach when:
- Data is periodic or event-driven
- Power efficiency is a top priority
- You need to support many peripherals
- A 1–3 second connection delay is acceptable
How to Choose the Right BLE Architecture
Choosing between an always-connected and a dynamic approach comes down to understanding how your product needs to behave in the real world. The right decision depends less on preference and more on how you balance power, responsiveness, scalability, and reliability for your specific use case.
Power Profile
How often does data need to move, and what’s the power budget?
If your device exchanges data frequently (every few seconds or continuously), the overhead of repeated connections outweighs the idle cost of staying connected. An idle BLE connection still consumes measurable power, typically on the order of hundreds of microamps to a couple of milliamps, depending heavily on connection interval, PHY, and radio settings (Nordic’s power profiler often shows this as per-event current spikes rather than a flat draw). Reconnecting repeatedly, however, adds additional overhead: each time the phone discovers the peripheral and establishes a new link, it incurs short bursts of higher current due to scanning, advertising, the connection handshake, and re-establishing security. For use cases with frequent updates, an always-connected architecture is almost always more efficient overall.
If data moves sporadically (every few minutes, hours, or only on user interaction), a dynamic architecture will significantly extend battery life. The math is simple: if you’re only transferring data 1% of the time, why burn power the other 99%?
Examples: A continuous glucose monitor that transmits every 5 minutes benefits from staying connected. Whereas a smart water filter reporting usage once a day should disconnect between syncs.
Data Frequency and Latency Expectations
Does the user need instant feedback, or is a short delay acceptable?
Real-time control systems, live dashboards, and streaming applications demand low latency. Always-connected is the clear choice, data flows immediately without connection overhead.
For periodic syncs, telemetry uploads, or event-driven updates where a 200-800ms reconnection delay won’t hurt the experience, dynamic works fine. Modern BLE with proper implementation (cached connection parameters, short advertising intervals) can reconnect in under a second. The key question isn’t whether you can reconnect quickly, but whether that delay disrupts the user experience.
Examples: A pulse oximeter displaying live SpO2 readings can’t tolerate connection setup delays. However, a fitness tracker syncing yesterday’s workout can.
User Interaction Model
How does the user trigger interactions, and what do they expect?
If the user expects the device to “just work” the moment they open the app, no waiting, no setup, you need either a persistent connection or a very aggressive dynamic reconnection strategy (sub-second reconnects with optimized advertising).
If the interaction is more deliberate (a “sync now” button, opening a specific screen), users will tolerate brief connection delays. The perceived delay also matters: if your UI shows a clear “connecting…” state, a 1-2 second wait feels intentional rather than broken.
Examples: A hearing aid adjusting settings via an app needs to feel instant. But a bathroom scale uploading weight data can take a moment to connect.
Scalability: Number of Devices
Will users connect one device, or many?
iOS and Android limit simultaneous BLE connections to around 7-8 total active connections per device, shared across all apps and system services. If your product involves multiple peripherals, keeping them all connected simultaneously isn’t practical.
Dynamic architectures scale better in 1:many scenarios. Connect only to the device you’re actively using, then disconnect when done. This frees connection slots and reduces cumulative power drain on the phone.
Examples: A home with 15 smart sensors shouldn’t keep all of them connected at once. Instead, rotate connections based on what needs attention. But a single medical device worn continuously can justify a persistent connection.
Connection Reliability and Environmental Factors
Will your device operate in challenging RF environments?
Always-connected architectures are vulnerable to interference, physical obstacles, and range limitations. A dropped connection requires reconnection logic anyway, so ask yourself: if you need robust reconnection code for failure cases, why not design around dynamic connections from the start?
Environmental factors matter more for some products than others. A device worn on the body maintains a stable connection. A device in a concrete basement, near Wi-Fi routers, or with the user’s phone in another room will drop connections regularly.
If your architecture assumes persistent connectivity but doesn’t handle disconnections gracefully, you’ve built the worst of both worlds: always-connected power drain with dynamic reconnection delays. Design for the reality of your deployment environment.
Examples: A fitness tracker worn on the wrist can maintain a reliable, always-connected link. However, a smart lock mounted on a metal door, with walls and Wi-Fi interference between it and the user’s phone, should use dynamic connections triggered when needed.
Platform Behavior and Background Limitations
How will iOS and Android background behavior affect reliability?
iOS can maintain BLE connections in the background and can even relaunch a terminated app when certain BLE events occur, as long as the app has the proper CoreBluetooth background modes enabled. However, these relaunches aren’t guaranteed to happen immediately, and if the user force-quits the app or toggles Bluetooth off, the system will not wake the app for BLE activity at all. This breaks the “always-connected” assumption for many real-world scenarios.
Android’s foreground service framework theoretically supports long-running BLE connections, but in practice, reliability varies by manufacturer. Many OEMs (Xiaomi, Huawei, Samsung, Oppo) apply aggressive battery optimizations that throttle or kill background processes (even those using a foreground service) unless the user explicitly exempts the app from restrictions. Android 14+ has improved consistency, but the ecosystem remains fragmented.
If your product relies on a stable, long-term background BLE connection to a smartphone, you should treat that as an unreliable link. Either:
- Accept that “always-connected” really means “connected while the app is active or in the foreground,” and design the UX around that reality
- Move critical always-on functionality off the phone and allow devices to communicate directly (BLE mesh, proprietary RF links, or direct sensor-to-actuator connections)
- Use the phone only as a monitoring/configuration interface, not a critical data relay
Examples: A closed-loop insulin delivery system cannot depend on a phone maintaining a continuous BLE link; the pump and sensor must communicate directly to ensure safety. A fitness tracker that logs live workout data can reasonably assume the app stays in the foreground during that activity, but not throughout the entire day.
Regulatory and Safety Requirements
Are there safety or compliance implications?
Medical devices requiring continuous monitoring for patient safety may mandate persistent connections to ensure timely alerts. However, given the platform limitations above, “persistent connection to a smartphone” is not a reliable safety architecture. If lives depend on connectivity, the phone can’t be the single point of failure.
For safety-critical applications, the standard solution is device-to-device communication. The critical devices (sensor, pump, monitor) communicate directly using BLE mesh, proprietary RF protocols, or hardwired connections, with the smartphone serving only as a monitoring and configuration interface. This ensures that critical functions continue even if the phone is off, backgrounded, or out of range.
Regulatory bodies scrutinize connection failure handling closely. If your device must alert a user to a critical condition, your architecture must guarantee that alert reaches them, which typically means on-device alarms, haptic feedback, or direct device-to-device alerting rather than relying solely on a phone connection.
Examples: Wellness and lifestyle products have more flexibility. A smart scale doesn’t need to be fail-safe; a pacemaker does.
Hybrid Models: Real-World Patterns
In reality, many products don’t fit neatly into “always-connected” or “dynamic” buckets. Hybrid strategies balance responsiveness with power efficiency, adapting behavior based on usage patterns.
Common Hybrid Patterns
- Opportunistic connections: The device advertises when idle but only connects when an event occurs (e.g., a button press, sensor threshold, or user opening the app). This keeps power low during idle periods while enabling fast interaction when needed. Best for sensor networks and event-driven devices, where most of the time, nothing is happening.
- Short-lived connection windows: The device connects briefly around user interactions (e.g., opening the app, starting a workout), exchanges data in a burst, then disconnects and returns to low-power advertising. Ideal for fitness trackers, smart scales, and other devices with predictable interaction patterns.
- Fast-then-slow advertising: After boot or disconnection, the device advertises aggressively (20ms intervals) for 30-60 seconds to enable quick discovery, then scales back to a slower interval (500ms-1000ms) to save power. If a connection is requested, it ramps back up. Common in consumer products where users expect fast initial pairing but the device needs long battery life.
- Connection on wake: The device stays disconnected most of the time but connects automatically when woken by motion, user interaction, or a scheduled event, then disconnects after a timeout. Works well for wearables and motion-activated devices where the physical interaction is the trigger.
There’s No Right Answer, But There Is a Right Process
Advertising and connection architecture is one of the most consequential decisions you’ll make when building a BLE product. This choice ripples through everything: how your device behaves in the real world, how users experience it, and whether your product can scale as it evolves.
There’s no universal “right” answer. Always-connected works beautifully for real-time, interactive products with reasonable power budgets. Dynamic architectures shine for low-power, event-driven devices that sync intermittently. Hybrid approaches let you adapt behavior to match how users actually interact with your product.
The key is making this choice deliberately, documenting it clearly, and validating it under real-world conditions. If you’re uncertain, start with a flexible architecture that allows for adjustment as you learn more about how your users interact with your device.
Once you’ve settled on your architecture, the next step is translating that strategy into specific implementation details: advertising intervals, connection parameters, scan windows, and the state machines that tie it all together. Our BLE Connectivity Architecture: The Ultimate Guide walks through those technical details and includes code patterns for common scenarios.
And if you’re building a connected medical device or tackling tough architectural decisions you’re not entirely sure about, an experienced partner can make all the difference. Give us a shout—we’d love to help.
