How do you complete a file download after the app backgrounds?

WHAT THIS TESTS: This question probes whether you understand the difference between foreground URL sessions and true background transfers on iOS. Interviewers want to know if you can name the correct API surface, explain the system contract, and avoid naive workarounds that violate platform policy. It separates developers who have shipped real networking features from those who have only worked in the foreground.

A GOOD ANSWER COVERS: First, create a URLSession using URLSessionConfiguration.background, supplying a unique identifier so the system can reassociate the session if the app is terminated. Second, enqueue a download task rather than a data task, because data tasks do not support background transfers. Third, implement the UIApplicationDelegate method application(_:handleEventsForBackgroundURLSession:completionHandler:) to capture the completion handler when the system wakes the app. Fourth, in the URLSessionDelegate, invoke that saved completion handler after all delegate messages finish, and do so within approximately 30 seconds or the system will kill the app. Fifth, acknowledge that the system controls the networking process, which means transfers continue even if your app is suspended, and the system may relaunch the app if it was terminated.

COMMON WRONG ANSWERS: A major red flag is suggesting beginBackgroundTask or beginBackgroundTaskWithName will keep the download alive. That API only provides about 30 seconds of background CPU time and is intended for short cleanup work, not multi-minute or multi-gigabyte downloads. Another red flag is proposing a repeating NSTimer or a while loop to prevent suspension; the OS will still throttle or kill the process, and this violates App Store guidelines. Claiming that a standard URLSession with a default configuration works in the background is also incorrect, because default sessions tie the task to the foreground process and suspend when the app backgrounds.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle authentication challenges when the app is not in the foreground. They may also ask what happens if the user force-quits the app, in which case the system discards the background session and does not relaunch the app. Another common follow-up is how to update the UI after the download finishes while the app is still backgrounded; the answer is that you cannot, but you can schedule a local notification or refresh the UI in applicationDidBecomeActive. They might also ask about background transfer limits, such as the recommendation to use discretionary transfers for large files so the system can schedule them on Wi-Fi and power.

ONE CONCRETE EXAMPLE: Suppose your app downloads a 500 MB video file. You initialize a URLSession with URLSessionConfiguration.background, passing a unique identifier like com.example.video. You create a URLSessionDownloadTask and resume it. The user backgrounds the app and later the download finishes. The system wakes your app and calls the app delegate handleEvents method. You store the completion handler. The URLSession then calls the delegate method urlSession(_:downloadTask:didFinishDownloadingTo:), where you move the file from its temporary location to the Documents directory. Finally, you call the stored completion handler, and the system snapshots your UI and suspends the app again.