Solving an iOS App Processing Conundrum—All In a Day’s Work at DevBBQ

4.9
123
Solving an iOS App Processing Conundrum—All In a Day’s Work at DevBBQ

Finding a creative solution to improve an iOS app's responsiveness and user experience by solving a data processing conundrum.

Here at DevBBQ, we’re digital creators with big appetites—and nothing gets our mouths watering more than when clients come to us with their product challenges.

We were recently tasked with finding a creative solution for just such a challenge, this time involving an app that one of our client distributes to its management team in order to track employee activities, store and product details (including data covering 7 years of financial metrics across 1,000+ stores), sales targets, and other business KPIs. This particular app manages a lot of data and syncs with our client’s servers on a daily basis—a 2–5 minute process. Our client recognized that their users disliked having to wait for the app to import the day’s data, and asked if this could be done in off-hours in the background—say, overnight—so that everything would be ready when users started work in the morning.

Based on this, we arrived at the following 2 client requirements:

  1. Perform a data sync at a specific time (specifically: after internal servers have updated, but before users have logged on for the day).Perform the data download and database update (duration: 2–5 minutes; fairly CPU and memory intensive).
  2. Perform the data download and database update (duration: 2–5 minutes; fairly CPU and memory intensive).

These were clear enough from a development perspective, but from experience, we knew that we were going to have to use some finessing in order to mesh our client’s needs with Apple’s rules:

  1. Apps are allowed time for background processing (i.e., when the app first goes into the background for 10–30 seconds).
  2. Apps can respond to push notifications when in background mode and are again allowed only 10–30 seconds of processing time.
  3. Apps can process network requests in the background, which allows the device to finish a network request if the user goes into background mode during the request.
  4. Each device chooses a time when it can perform a network background fetch request. This is not under developer control, and usually takes place when the device is idle. Again the limit is around 30 seconds and the background fetch is not guaranteed to even get called during this time.
  5. Background processing can only happen in background mode (e.g., when the user switches to another app or presses the Home button), and not when the app has been terminated.
  6. Apps must stay within certain CPU and memory limitations or the app will be shut down by the device.

Want to see how we solved it?

Check out our blog which includes snippets of code and more details about our challenges.