BGTaskScheduler — är Apples ramverk för att planera och utföra bakgrundsuppgifter i iOS 13 och senare. Det ersatte de föråldrade Background Fetch och performFetch och tillhandahåller ett enhetligt API för arbete med bakgrundsoperationer. Enligt Apple Developer Documentation, 2026 omfattar ramverket två typer av uppgifter: BGProcessingTask för långvariga operationer och BGAppRefreshTask för korta innehållsuppdateringar.
Huvudpunkter
BGTaskScheduler — är Apples systemramverk, introducerat i iOS 13, som centralt hanterar utförandet av bakgrundsuppgifter. Före dess uppkomst använde utvecklare UIApplication backgroundTasks, performFetch och händelsehantering i appDelegate, vilket ledde till kodfragmentering och oförutsägbart beteende.
Ramverket fungerar enligt principen om fördröjd planering: applikationen registrerar uppgifter med unika identifierare och iOS bestämmer själv den optimala tidpunkten för deras utförande. Systemet tar hänsyn till batterinivå, användaraktivitet, nätverksstatus och andra faktorer.
Huvudsakliga möjligheter inkluderar arbete med både korta och långa bakgrundsoperationer. Till skillnad från AlarmManager i Android garanterar BGTaskScheduler inte exakt utförandetid — systemet förbehåller sig rätten att försena uppgiften om förhållandena är ogynnsamma.
BGTaskScheduler använder en arkitektur baserad på hanterare (handlers). Applikationen registrerar en hanterare för varje uppgiftstyp och systemet anropar den när rätt ögonblick kommer. Ramverket utför inte uppgiften direkt — det meddelar bara applikationen att det är dags att starta den.
Registreringen börjar med att deklarera uppgiftsidentifieraren i Info.plist via arrayen BGTaskSchedulerPermittedIdentifiers. Därefter anropas metoden registerHandler(forTaskWithIdentifier:) i applikationskoden med en handler-closure.
import BackgroundTasks
let taskID = "com.example.app.refresh"
BGTaskScheduler.shared.registerHandler(
forTaskWithIdentifier: taskID,
using: DispatchQueue.global()
) { task in
task.expirationHandler = {
// anropas vid tvångsavslutning
}
processBackgroundTask(task as! BGAppRefreshTask)
}
Efter registrering måste applikationen uttryckligen begära utförande av uppgiften via submitTaskRequest. Begäran innehåller uppgiftsidentifieraren och datumet för tidigast möjliga start. Systemet sparar begäran och behandlar den när det anser att förhållandena är lämpliga.
let request = BGAppRefreshTaskRequest(
identifier: taskID
)
request.earliestBeginDate = Date(timeIntervalSinceNow: 3600)
do {
try BGTaskScheduler.shared.submit(request)
} catch {
print("Planeringsfel: \(error)")
}
BGTaskScheduler erbjuder två huvudtyper av uppgifter, var och en utformad för sitt eget användningsscenario. Att välja rätt typ påverkar direkt sannolikheten för att uppgiften utförs framgångsrikt av systemet.
BGAppRefreshTask är utformad för korta bakgrundsuppdateringar av innehåll: ladda ny data, synkronisera med servern, uppdatera widgetar. Utförandetiden är begränsad till 30 sekunder, varefter systemet tvångsavslutar uppgiften. Denna typ av uppgifter utförs oftare än BGProcessingTask och har högre prioritet.
BGProcessingTask är utformad för längre operationer: bearbetning av mediafiler, indexering av Core Data-data, skapande av säkerhetskopior. Uppgiften kan pågå i upp till flera minuter, men systemet startar den mer sällan och endast under gynnsamma förhållanden — ansluten till ström, stabilt Wi-Fi och låg enhetsbelastning.
| Parameter | BGAppRefreshTask | BGProcessingTask |
|---|---|---|
| Tidsgräns | 30 sekunder | flera minuter |
| Startfrekvens | hög | låg |
| Villkor | alla | ström + Wi-Fi |
| Kräver ström | nej | rekommenderas |
| Exempel | uppdatera flöde | bearbeta video |
Korrekt registrering — är ett obligatoriskt villkor för att BGTaskScheduler ska fungera. Om uppgiften inte är registrerad i Info.plist kommer systemet att ignorera varje begäran om dess utförande.
I filen Info.plist läggs en array BGTaskSchedulerPermittedIdentifiers till med en lista av textidentifierare. Varje identifierare måste vara unik inom applikationen. Apple rekommenderar användning av omvänd domännotation.
<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
<string>com.example.app.refresh</string>
<string>com.example.app.processing</string>
</array>
För planering används metoden submitTaskRequest. Om uppgiften inte längre behövs kan den avbrytas via cancelTaskRequest eller cancelAllTaskRequests. Systemet avbryter automatiskt uppgifter när applikationen tas bort eller data återställs.
BGTaskScheduler erbjuder möjligheten att spåra status för planerade uppgifter via getPendingTaskRequests. Denna metod returnerar en lista över alla aktiva begäran med information om deras typ, identifierare och earliestBeginDate. För varje begäran kan man kontrollera om den redan har utförts eller avbrutits och fatta beslut om omplanering.
Det är viktigt att notera att systemet inte tillhandahåller någon direkt återuppringning om framgången av bakgrundsuppgiften — hanteraren måste själv rapportera resultatet via uppgiftens egenskaper. setTaskCompleted gör det möjligt att markera uppgiften som framgångsrikt slutförd, varefter systemet kan starta nästa planerade uppgift av denna typ. Om uppgiften inte anropar setTaskCompleted anser systemet den vara slutförd efter tidsutgång eller vid tvångsavslutning.
För diagnos av problem rekommenderas att använda OSLog i hanteraren och visa loggar via Console.app på Mac. Apple tillhandahåller också verktyget MetricKit för prestandaanalys av bakgrundsuppgifter — det samlar in data om utförandetid, energiförbrukning och startfrekvens, som kan användas för optimering.
// Avbryt specifik uppgift
BGTaskScheduler.shared.cancel(taskRequestWithIdentifier: taskID)
// Avbryt alla uppgifter
BGTaskScheduler.shared.cancelAllTaskRequests()
// Kontrollera planerade uppgifter
BGTaskScheduler.shared.getPendingTaskRequests { requests in
print("\(requests.count) uppgifter planerade")
}
BGTaskScheduler lägger strikta begränsningar på bakgrundsarbete. Systemet kan försena uppgiften under obestämd tid om förhållandena är ogynnsamma. Utvecklaren måste förstå att ramverket inte är avsett för realtidsuppgifter.
Bland de viktigaste begränsningarna: systemet garanterar inte att uppgiften utförs vid angiven tid, det maximala antalet samtidiga uppgifter är begränsat och energiförbrukningen kontrolleras strikt. Att starta flera uppgifter i följd kan leda till sammanslagning eller avbokning.
För att öka sannolikheten för utförande rekommenderas att ställa in earliestBeginDate inte tidigare än 1 timme för BGProcessingTask och 15 minuter för BGAppRefreshTask. Det är också viktigt att hantera expirationHandler — om uppgiften inte ryms inom tidsgränsen anropar systemet denna hanterare för korrekt avslutning. Omplanering bör ske inuti själva hanteraren för att upprätthålla en kontinuerlig cykel av bakgrundsarbete.
En annan viktig begränsning gäller nätverksförfrågningar. BGTaskScheduler garanterar inte aktiv nätverksanslutning under utförandet av uppgiften. Applikationen måste själv kontrollera nätverkstillgänglighet via NWPathMonitor och skjuta upp bearbetningen om anslutning saknas. Detta skiljer sig från Android JobScheduler som kan aktivera uppgiften endast vid anslutning till en specifik nätverkstyp. I praktiken kombinerar utvecklare ofta BGTaskScheduler med bakgrunds-URL-sessioner i NSURLSession för tillförlitlig dataladdning.
Från och med macOS Catalina är BGTaskScheduler även tillgängligt på Mac. Detta möjliggör skapandet av plattformsoberoende bakgrundsuppgifter för UIKit-applikationer som körs på Apple Silicon. På watchOS fungerar ramverket begränsat — endast korta BGAppRefreshTask finns tillgängliga för att uppdatera komplikationer och synkronisera data med iPhone. Utvecklare bör ta hänsyn till plattformsskillnader när de planerar bakgrundsarkitekturen.
För felsökning av BGTaskScheduler tillhandahåller Apple flera verktyg. Kommandot e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.example.task"] i lldb tvingar fram start av bakgrundsuppgiften och ignorerar systembegränsningar. I Xcode är flaggan Simulate Background Fetch tillgänglig i Debug-menyn som emulerar en kort bakgrundsuppdatering. För prestandaanalys används MetricKit — det samlar in information om startfrekvens, utförandetid och energiförbrukning för varje uppgift. Dessa data hjälper till att optimera planeringsfrekvensen och välja rätt uppgiftstyp.
I praktiken är BGTaskScheduler lämpligt för att uppdatera widgetdata, synkronisera iCloud, bearbeta push-notiser med innehåll och indexera Spotlight-sökning. Inte lämpligt för att skicka realtidsanalys, chattapplikationer eller några uppgifter som kräver omedelbar utförande.
För djupgående studier av BGTaskScheduler rekommenderar Apple den officiella WWDC-dokumentationen: sessionen “Advances in Background Tasks” (2020) täcker migrering från föråldrade API:er och “Background Tasks in Practice” (2021) innehåller verkliga användningsfall. Även användbart är avsnittet Energy Efficiency Guide, där det beskrivs hur ramverket passar in i Apples övergripande energibesparingsstrategi. Kodexempel finns i det officiella Apple Developer-förrådet på GitHub med kompletta projekt för iOS och macOS.
Vanliga frågor
Background Fetch var begränsat till en bakgrundsuppgift per applikation och hade ingen prioriteringsmekanism. BGTaskScheduler stöder flera uppgifter av olika typer, tillhandahåller ett enhetligt API och automatisk energihantering.
Apple anger ingen explicit gräns för antalet registrerade identifierare, men i praktiken rekommenderas att inte använda fler än 5–10 uppgifter. Ett större antal minskar sannolikheten för utförande av varje specifik uppgift på grund av konkurrens om systemresurser.
För felsökning, använd kommandot e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.example.task"] i lldb. Det tvingar igång uppgiften och kringgår systembegränsningar. Även flaggan Xcode Simulate Background Fetch finns i Debug-menyn.
Ja, BGTaskScheduler kan starta processen även om applikationen har tvångsavslutats av användaren. Systemet kan dock tillämpa ytterligare förseningar och inte alla uppgiftstyper garanterar start i detta scenario.
Systemet anropar expirationHandler och skickar en signal till uppgiften om behovet av att avslutas. Om applikationen ignorerar denna signal och fortsätter arbeta, tvångsavslutar iOS processen. Därefter kan systemet sänka prioriteten för alla bakgrundsuppgifter i applikationen.
Sammanfattning
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också