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!

As your iOS development skill is growing, I believe you use UIScrollView, UICollectionView, UITableView, and other native views regularly and proficiently in your applications. Yet, some iOS developers still don’t know what exactly UIStackView is, what it uses for or in which situation should we use UIStackView.
In this tutorial, I will introduce you to UIStackView - A view helps us to simplify our iOS layouts.

Let’s imagine you’re going to build an application that allows the user to add or remove views in run time. Remember how we will accomplish this task? We first have to remove all constraints in the relative area and update them all over again. Or remember the case where you implement the sign-in / sign-up view, you add many text fields and manually set constraints between those views. In such situations, UIStackView appears to be more useful than other views.

In the previous post, Advanced iOS Concurrency: Operations, we walked through the Operation concepts on iOS and made a demo application that fetches some posts of mine. After downloading the cover images, they will be applied to a simple filter, then be displayed in a table view. The application, however, has not been completed yet. There’s something that went wrong with our app making the app did not show downloaded images properly. In this tutorial, we will continue where we left off.
Get ready!

There are two techniques to deal with Concurrency in iOS: GCD - Grand Central Dispatch and Operations. Most of the time, GCD provides most of the concurrency capabilities you need. Yet, sometimes you’ll want some extra advanced customizations. It’s time to use Operations. This tutorial will introduce Operations in Swift, also explain when and why we use Operation instead of GCD.
Let’s switch the gears!

There is a big gap between knowing the path and walking through the path.

Some applications can survive without any data storage. Most other useful applications, however, save some state such as user configurations, user profile, goals, etc. on iOS, Apple provides Core Data as a framework to persist your valuable data. One thing to keep in mind that although CoreData can store data in a relational database it’s actually not a database engine.
In this tutorial, I will share with you a bad experience I faced when I work with Core Data. Hopefully, after reading my sharing, you will avoid facing the same problem in your projects.
Let’s get started.

Last night, I read a chapter of a book as one of my favorite books: "The pragmatic programmer" (By Andrew Hunt and David Thomas). This chapter discusses how to use assertion to make the code easier for debugging. We all know that assertion is an essential tool for writing tests, but It does more than that. Let’s go with me to meet this guy: Assertion.

Preface

ANCS, stands for Apple Notification Center Service, is designed by Apple. It allows Bluetooth accessories that connect to iOS devices via BLE a simple way to access notifications that happend on iOS devices.

As a Software Engineer, you definitely have heard about the Memory leak concept. Memory leak is a situation where blocks of memory are located by the program remain in the memory despise they are no longer referenced. Leaks waste space by filling up pages of memory with inaccessible data. As a result, the size of memory using in your apps keep increasing, affect the user experiences and the performance of your app. Even worse, your app will be crashed randomly because a process will be terminated by the system if it consumes too much memory.
In this topic, we will discuss how the memory is managed in iOS and how to use the memory efficiently. Read on.

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!