Unlike Android, iOS restricts background processing in an effort to improve battery life and user experience. When your app enters background mode, developers lose direct control over it. How and when your app gets a chance to execute a task depends entirely on the system. At its core, iOS uses an internally complex algorithm to determine which apps are allowed to run in the background, based on factors such as user activity patterns, current battery state, and more.

In this tutorial, we will learn how to request periodic background execution time on iOS. After understanding how it works, we will apply this technique to a BLE-based app in some specific cases in the next tutorial.

Let’s get started!

iOS developers are building applications that play both roles Peripheral and Central to exchange data with other copies apps. The data can be exchange a small of information via BLE packets or the signal strength indicator (RSSI) value from one to the others. However, keeping the app last forever in the foreground is impossible. Sooner or later, the app will enter to background mode by the user and finally will be suspended by the system depending on RAM available, power consumption and other factors. Thus, understanding the procedure of advertising and scanning on iOS devices helps you to build good applications that fit your expectations.
At the end of this tutorial, we will build a simple application that acts as both a scanner and an advertiser. When two applications find each other, they will write a log record for analysis. Depending on the results, we will find out how effective our application is using Core Bluetooth.
Let’s switch the gear!

In the previous post, I basically give you a quick look at iBeacon - A Bluetooth protocol built on top of BLE by Apple, and made a simple demo of how iBeacon can wake up an application after being terminated by the user. However, I did not mention other foundation concepts in Beacon, it also did not give you a deep look at the advantages and disadvantages of this powerful technology.
Today, I would like to introduce you to a good book giving a solid knowledge in Beacon field, especially iBeacon: Building Applications With iBeacon published by O’Reilly.
After reading this book, I ensure that you will get a good knowledge in iBeacon field and your mind will be more open to the next coming up ideas.
Let’s drive-in!

Welcome to the next part of the series of “How to deal with BLE in the background“.
In the previous part, I guided you how to keep your app alive as long as possible when your app enters to background mode by using State Preservation and Restoration technique supported by Apple. However, there are some usecases this technique can not handle, as described below (refer to Apple document: Conditions Under Which Bluetooth State Restoration Will Relaunch An App)

As you can see, there is a common case when users force quit the app from the multiple task view (Whether accidentally or intentionally), the Restoration technique can not awake your app. Let’s imagine that your app has a feature allows users to press a button on your BLE-connected devices to find where their phone is, but if your app is not running or is not able to wake up to handle the BLE signal sent from your devices, this feature would be useless.
In this post, I will show you a technique using iBeacon to deal with this case, which makes your app another chance to wake up despite it is terminated by users. Let’s drive-in!

Preface

When working with CoreBluetooth, have you ever wondered how a BLE app on iOS can survive when it is terminated by the system? How can we bring it back to the background? Is there anything like an Android service that can run indefinitely? You can find the answer to all these questions in this post. Read on!

Introduction

As I mentioned in the previous post, CoreBluetooth allows us to create applications that can communicate with BLE devices such as heart rate monitors, body sensors, trackers, or hybrid devices.
There are two roles to play in the CoreBluetooth concepts: Central and peripheral.

• Central: Obtain data from peripherals.
• Peripheral: Publish data to be accessed by a central. We can make a Bluetooth device plays as a peripheral from either firmware-side or software-side.

In this post, I will show you how to create a peripheral by using our own identifiers. Also using another device, as a central, to connect and explore our services. Let’s get it started.

The Core Bluetooth (CB) framework allows iOS and MacOS apps communicate with BLE devices. Your apps can discover, explore, and control the BLE devices, such as heart rate monitors, trackers or hybrid watches.