Leveraging Background Bluetooth for a Great User Experience

One of the most important things that users want when using a connected product is to be able to put its app in a folder and forget about it, trusting that it’ll work. Designing apps with this capability goes far beyond a product’s physical appearance and an app’s user interface. Background Bluetooth on iOS can be extremely powerful but requires cooperation across the system. Understanding how to make use of Bluetooth in the background will help you create a better user experience for your connected product.

If you’re making a connected product and need to build an app you may have a long list of awesome feature ideas that will make your app stand out. All you need to do is start developing.

Before you get too carried away, take a step back and consider this — nobody wants to take the time to learn how to use an app. They want an intuitive mobile experience. For connected products, users want even more than that. They’re looking for an app you can just put in a folder and forget, trusting that it’ll work.

Use-Case Example to Help Understand the Importance of Background Bluetooth

It may sound counterintuitive to design an app “not to be used,” and that’s generally the case, but with connected products the opposite is true. Consider a connected scale that uses BLE to transfer the user’s weight to their iOS device. The user pulls out his phone, launches the scale app, and hits a “measure” button. The user then steps on the scale, and after a few seconds, the measurement appears on the scale’s screen and the app. The user sees his weight in both locations, then closes the app and goes about his day. Both the scale and the app functioned perfectly, yet the process was more tedious than it needed to be.

The user steps on the scale and after a few seconds, the measurement is displayed. The user sees her weight on the scale then goes about her day. Later, the user pulls her phone out and sees a notification from the scale’s app. It reads:

Thursday Morning: XX lbs. 
Way to go! You’ve lost X lbs this week.

Which user experience is preferable? The one where the user doesn’t need to “use” your app. All the user has to do is stand on the scale, and the smart-device part simply happens. This is the power of an “invisible” app.

So, how do you harness the power of “invisible” app design for your BLE connected product?

Core Bluetooth Background Processing and State Restoration

Apple’s Core Bluetooth SDK provides functionality that allows the app to react to certain BLE events while the app is suspended or in the background. Core Bluetooth will even store aspects of your Bluetooth manager instance when the app is no longer running. Therefore, the app can be quickly restored in the background and react to a BLE event that occurs hours or even days later.

All Core Bluetooth callbacks will fire when the app is in the background, whether the user is on the iOS home screen, in another app, or the device is locked. However, once iOS has terminated the app to free up memory, only certain Bluetooth events will relaunch your app in the background. These events include peripheral discovery, peripheral connection, and notifications/indications from a characteristic which your app has subscribed to. Once the app relaunches, all callbacks will fire until iOS terminates the app again.

When iOS terminates the app to free up memory, several Bluetooth state details are saved. If your app is functioning as a BLE central, iOS will store:

• The advertised services the app is scanning for 
• The peripherals pending connection
• The characteristics to which the app is subscribed 

When the app relaunches, iOS returns a list of Bluetooth devices with which your app was interacting. These can be used to retrieve the peripheral objects from iOS, and allow the app to handle the events for which it was awoken.

How to Prevent Negative User Experience

Despite how wonderful background processing and Bluetooth State Restoration sound, several caveats can lead to negative user experiences.

User Denies Bluetooth Access or Bluetooth Turns Off

iOS will no longer relaunch your app in the background for BLE events if the user denies the app access to Bluetooth or turns Bluetooth off. This can occur at any time. While your app will receive a callback if it’s running in the foreground or background, there is no way for it to know if a change has occurred once it has been terminated.

The more likely and more dangerous scenario occurs when the user “force quits” the app by swiping it away in the multitasking screen, or when the device restarts. Both scenarios place the app in the terminated state and prevent iOS from relaunching the app until it is manually launched by the user. Regardless of whether the user negligently forgets to charge his or her phone, or habitually force kills apps and restarts his or her device, these scenarios will harm the user experience with your “invisible” app.

Knowing all of the factors that can negatively impact background processing, you’re probably wondering, “Can I prevent this from happening?” The short answer is that you can’t. Apple has designed iOS in a  way that prevents applications from abusing the user. However, there are ways to minimize the negative user experience stemming from interruptions to your BLE application. 

Push Notifications

Push notifications can be used to send a message to the user. These can be queued locally by the application when it is open, or delivered from a remote server. Local notifications become immune to the app lifecycle once scheduled. Both types of notifications display a message to the user and can relaunch the app if pressed. Once relaunched, the app can be backgrounded or terminated by iOS. Background processing and state restoration will once again function.

There are other ways to relaunch the app in the background that are immune to device restarts and BLE being unavailable to the app. However, these methods require Location Services. Apple’s permissions for Location Services are far stricter than the BLE permission. As of iOS 13, iOS will show the user a map of locations where your app has requested their location. To avoid the misconception that they are tracking users, apps should avoid using Location Services unless it is part of their use case.

Two Ways to Implement “Invisible” Product Design

In an “invisible” app, the app initiates user interaction, instead of vice versa. This is a product of system design, not app development. Mobile operating systems, such as iOS, are actively hostile to background processes due to resource constraints such as energy and memory. iOS terminates suspended apps as needed to increase resource availability for the task that has the user’s focus. There are triggers to launch suspended or terminated apps in the background, such as Core Bluetooth’s state restoration and background processing feature, but they require that the entire system be designed with the triggers in mind.

In BLE design, there are two main implementations. In the first, the device only connects when there is data to be transferred and then disconnects. In the second, the device attempts to maintain a connection as long as possible. The first implementation is more power-efficient, while the second delivers lower latency.

In the case of the first implementation, a disconnected peripheral should only be discoverable when it needs the app to react. If the peripheral is always discoverable, then the user’s device won’t know when to connect and have state restoration launch the app. 

The second implementation leverages state restoration’s ability to relaunch the app when a notification is received. The downside to this is that if a disconnection occurs while the app is terminated, the disconnection event cannot be handled by the app. In order to reduce the chances of that happening, the peripheral may be configured to send a “heartbeat” notification regularly. That notification will trigger state restoration to relaunch the app when received and should result in the app spending minimal time in the terminated state.

For an “invisible” app, push notifications are crucial to app initiated interactions. The app can interact with the user when information is available, or input is required. Providing input can be accomplished by pressing the notification to launch the app directly to the required screen, or through the use of the Custom Actions feature of Apple’s User Notifications framework. When done this way, the user never has to think about the app unless the app has initiated interaction. Smart products are supposed to help users do less, after all.

Core Bluetooth is not the only path to “invisible” connected product design.

Three iOS Frameworks for Design Strategy 

• Region Monitoring, which is part of Location Services, can be used to launch an app in the background when the user enters or exits a region. Regions are defined by geographical location or proximity to an iBeacon.
• Remote notifications are useful to prompt user action when the app is no longer running, such as prompting the user to relaunch the app if the app hasn’t checked in with an external server after a set amount of time.
• HealthKit provides a central location for storing and displaying health and activity information. Apps can read health information that they need and write any health information that they acquire. Users don’t need to fill out health information in your app manually and can view their health data from multiple sources in one place using the Apple Health app.

I hope that this helps you understand what iOS apps can do in the background, and inspires you to try “invisible” product design for your next connected product.

To learn more about Alec, check out this interview