Background execution is a system-granted opportunity, not an unlimited timer. Permissions and scheduling behavior belong in the acceptance plan before an agent writes the happy path.
- 1User permission
- 2Register capability
- 3Schedule work
- 4Handle expiration
Work through the example
Test cancellation and expiration through a controlled seam. Make the foreground app explain the last known state instead of promising exact execution time.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
BGTaskScheduler Registration
Register task identifiers in Info.plist under BGTaskSchedulerPermittedIdentifiers:
<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
<string>com.yourapp.refresh</string>
<string>com.yourapp.db-cleanup</string>
<string>com.yourapp.sync</string>
</array>
Register handlers at app launch (before the end of the first applicationDidFinishLaunching call or in the @main App init):
import BackgroundTasks
@main
struct MyApp: App {
init() {
registerBackgroundTasks()
}
var body: some Scene {
WindowGroup {
ContentView()
}
}
private func registerBackgroundTasks() {
BGTaskScheduler.shared.register(
forTaskWithIdentifier: "com.yourapp.refresh",
using: nil // nil = main queue
) { task in
guard let task = task as? BGAppRefreshTask else { return }
handleAppRefresh(task: task)
}
BGTaskScheduler.shared.register(
forTaskWithIdentifier: "com.yourapp.db-cleanup",
using: nil
) { task in
guard let task = task as? BGProcessingTask else { return }
handleDatabaseCleanup(task: task)
}
BGTaskScheduler.shared.register(
forTaskWithIdentifier: "com.yourapp.sync",
using: nil
) { task in
guard let task = task as? BGProcessingTask else { return }
handleSync(task: task)
}
}
}
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| User permission | Confirm the input and environment | Preserve the failure and return to this step |
| Register capability | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Schedule work | Run the focused check | Preserve the failure and return to this step |
| Handle expiration | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
A source review cannot prove that the operating system will schedule a task at a specific time.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- How should I review availability guards when moving a Swift app toward iOS 27?
A measured guard-review example that separates SDK availability, runtime readiness, and static-analysis limits.
- Review AI-generated Swift before you trust it
A focused review, a small patch and a real test beat a confident completion message.
What to do next
Next: Deep links and universal links, and using them for automated screenshots