Seeking Apple Recommended Solution for Extended, Deterministic Background Sync/Upload for Offline-First App (Large Data)

Question

Created 2w

Replies 2

Boosts 0

Participants 3

Context

Our enterprise application is offline-first for iOS and iPadOS, designed to work completely offline, storing a very large local database (DB) and many attached files (images and videos) locally. Users create and update entities on the device.1

When connectivity is available, the app performs a bidirectional sync: local changes (including multi-gigabyte files) are uploaded, and thousands of DB updates are pulled down and applied locally.

The Challenge: Foreground Requirement

The complete sync process often requires 10 to 20 minutes to finish. Users expect their devices to proactively sync when online, even if it takes this long.

Our fundamental problem is that, at present, users must keep the app in the foreground to complete the task. We have confirmed that on iOS, the system aggressively terminates the app process, typically after 30 seconds of being sent to the background. We currently advise users with large projects to keep the app in the foreground and connected to power.2

Existing Mitigation and Technical Details

We have implemented several best practices to optimize transfers and manage device resources: We use battery checks before initiating large transfers, with a low battery threshold (around 15%) to pause actions if the device will enter a danger zone.2 Our upload mechanism uses HTTP Range Requests to implement a resumable single-stream approach for maximum throughput, ensuring that if a connection drops mid-transfer (even at 1.2 GB of a 2.5 GB file), we only re-transfer the remaining bytes, rather than losing all progress. This addresses network resilience and speed but not the OS background limitation.3 The Core Issue

The various background options provided by iOS and iPadOS do not appear deterministic enough to reliably handle the immediate, extended data synchronization (uploading GB files and pulling down substantial DB changes) that we require. We are seeking a solution where a user-initiated task engages in background work almost immediately, reliably continuing for 10–20+ minutes after the user leaves the app or locks the screen, allowing for more "natural" device usage.

Our Question for Apple Engineering

Given the high volume of data transfer and the need for deterministic, extended background execution, what is Apple's current recommended, official approach for an enterprise app that requires prolonged background syncs—specifically, how can we architect this on iOS/iPadOS to reliably continue the upload and download of large data sets and database updates after the app moves out of the foreground?

Answered by DTS Engineer in 889148022

As Albert suggested, there are a variety of different tools that you can reach for here. I have links to a lot of them in iOS Background Execution Limits. I also recommend that you have a read of Moving to Fewer, Larger Transfers.

I suspect you might be able to make some headway by combining approaches:

Use a URLSession background session for your large attachments.
Use a continued processing task to complete your sync when the user moves the app to the background.
And if that doesn’t pan out — for example, because the user cancels the task — use a background processing task to complete the sync overnight.

This isn’t a trivial exercise and I suspect that you’ll need to tweak things to match the real world circumstances encountered by your app.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

DTS Engineer OP

Apple

2w

Thanks for the interesting post. Looking forward to engineers opinion about this subject.

I don't think It is advisable to make a recommendation beyond the 30-second timeframe based solely on data transfer, battery usage, and application duration. The actual upload and synchronization time from the device on a foreground application may take up to 20 minutes?

Currently, your architecture relies on managing HTTP requests directly within the app. As you have observed, the system aggressively suspends and terminates app processes shortly after they enter the background.

My opinion is that anything taking minutes should be completely re-architected. You must migrate your large file transfers to a background URLSession even thought you got seconds not minutes.

While background URLSession solves the minutes file transfer problem, it does not solve the compute problem of applying "thousands of DB updates" locally. If your app attempts to keep a open session or make paginated API calls to sync the DB in the background, it will be killed.

When the system wakes your app to deliver the downloaded files, you are granted a very short execution window (typically around 30 seconds). If DB processing takes minutes. You cannot do this immediately in the background wake-up window. You must schedule a BGProcessingTask via the BGTaskScheduler.

My primary recommendation is to refrain transferring in the foreground big files and instead focus on utilize iCloud storage, allowing iCloud to synchronize itself automatically. https://developer.apple.com/icloud/cloudkit/

Looking forward to other opinions.

Albert   Worldwide Developer Relations.

Answer 2