Фонові завдання в iOS: BGTaskScheduler та легальна синхронізація

Застосунок майже готовий, але користувачі скаржаться на застарілі дані при перемиканні між застосунками. Apple суворо обмежує фонову роботу, щоб зберегти батарею. Ми допоможемо вам легально й ефективно організувати background-задачі за допомогою BGTaskScheduler — єдиного офіційного способу запуску регулярних фонових завдань в iOS 13+. Розберемося, як уникнути типових помилок, що блокують виконання.

Чому iOS обмежує фонові завдання?

iOS агресивно оптимізує енергоспоживання: застосунок, що пішов у background, отримує 30 секунд для завершення поточної роботи, потім призупиняється. BGTaskScheduler надає два типи завдань, які система запускає у відповідні моменти (наприклад, при зарядці або підключенні до Wi-Fi). Це в 10 разів надійніше старих методів на кшталт UIApplication backgroundTasks, оскільки система сама балансує навантаження та батарею. Близько 90% сучасних iOS-застосунків для оновлення даних використовують саме BGTaskScheduler.

Які типи завдань пропонує BGTaskScheduler?

BGAppRefreshTask — коротке завдання (до 30 секунд). Система запускає його за відповідної умови: пристрій заряджається або підключений до Wi-Fi, користувач активний. Підходить для оновлення даних інтерфейсу.

BGProcessingTask — довге завдання (кілька хвилин). Запускається тільки при зарядці та Wi-Fi. Підходить для важких операцій: міграція бази даних, завантаження великого контенту, перенавчання CoreML-моделі.

Як реалізувати реєстрацію та планування?

<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
    <string>com.yourapp.refresh</string>
    <string>com.yourapp.processing</string>
</array>

import BackgroundTasks

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    BGTaskScheduler.shared.register(
        forTaskWithIdentifier: "com.yourapp.refresh",
        using: nil
    ) { task in
        self.handleRefresh(task: task as! BGAppRefreshTask)
    }
    BGTaskScheduler.shared.register(
        forTaskWithIdentifier: "com.yourapp.processing",
        using: nil
    ) { task in
        self.handleProcessing(task: task as! BGProcessingTask)
    }
    return true
}

func scheduleAppRefresh() {
    let request = BGAppRefreshTaskRequest(identifier: "com.yourapp.refresh")
    request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

func scheduleProcessing() {
    let request = BGProcessingTaskRequest(identifier: "com.yourapp.processing")
    request.requiresNetworkConnectivity = true
    request.requiresExternalPower = true
    request.earliestBeginDate = Date(timeIntervalSinceNow: 3600)
    try? BGTaskScheduler.shared.submit(request)
}

Планувати потрібно кожного разу при уході в background через sceneDidEnterBackground або applicationDidEnterBackground. Один виклик submit — одна постановка завдання в чергу. Розробники на SwiftUI також можуть використовувати BGTaskScheduler, плануючи завдання в AppDelegate або через Combine.

Як правильно обробляти завдання та expirationHandler?

func handleRefresh(task: BGAppRefreshTask) {
    scheduleAppRefresh()
    let syncTask = Task {
        do {
            try await DataSyncService.shared.sync()
            task.setTaskCompleted(success: true)
        } catch {
            task.setTaskCompleted(success: false)
        }
    }
    task.expirationHandler = {
        syncTask.cancel()
        task.setTaskCompleted(success: false)
    }
}

expirationHandler — найчастіша помилка, яку пропускають. Якщо не викликати setTaskCompleted до закінчення часу, система вбиває процес і позначає застосунок як такий, що зловживає background execution. Після кількох таких випадків iOS перестає запускати завдання застосунку. Близько 80% проблем з фоновими завданнями пов'язано з неправильною обробкою цього замикання. Завжди встановлюйте expirationHandler всередині обробника, відміняйте всі асинхронні операції та викликайте setTaskCompleted з false. Не забудьте перепланувати завдання на майбутнє.

Коли система запускає завдання та як їх налагодити?

Не можна гарантувати конкретний час запуску — iOS вирішує сама на основі патернів використання, заряду батареї, мережі. Застосунки, якими користувач користується часто, отримують більше фонового часу. Новий застосунок або рідко використовуваний — менше.

Налагодження в Xcode: завдання можна примусово запустити через Debug Menu під час налагодження на реальному пристрої:

Xcode → Debug → Simulate Background Fetch

Або через lldb:

e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.yourapp.refresh"]

Симулятор не підтримує BackgroundTasks — потрібен реальний пристрій.

Як використовувати URLSession для фонового завантаження?

Для фонового завантаження та вивантаження файлів BackgroundTasks не потрібен — використовуємо URLSessionConfiguration.background(withIdentifier:). Система сама керує передачею, застосунок отримує колбек при завершенні через AppDelegate.application(_:handleEventsForBackgroundURLSession:completionHandler:). Це працює навіть якщо застосунок був вивантажений з пам'яті.

Що входить у впровадження?

• Налаштування provisioning profile та code signing для підтримки фонових режимів
• Реєстрація Permitted Identifiers в Info.plist
• Реалізація обробників BGAppRefreshTask та BGProcessingTask з коректним expirationHandler
• Інтеграція з URLSession background configuration для завантаження файлів
• Планування завдань відповідно до життєвого циклу застосунку
• Налагодження на реальних пристроях, налаштування APNs при необхідності
• Документація та код-рев'ю
• Навчання розробників (опціонально)
• Технічна підтримка протягом 1 місяця після впровадження

Орієнтовні терміни та вартість

Вартість впровадження базової фонової інфраструктури починається від $800. Економія бюджету до 30% при замовленні комплексного рішення. Точна вартість розраховується індивідуально залежно від складності та обсягу робіт. Ми гарантуємо, що ваш застосунок пройде App Store Review і коректно працюватиме у фоні. Наша компанія має 5+ років досвіду в iOS-розробці та виконала понад 50 проєктів із впровадження фонових завдань. Отримайте консультацію з впровадження фонових завдань — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення. Зв'яжіться з нами, і ми відповімо протягом дня. Замовте реалізацію фонових завдань у наших експертів для суттєвої економії бюджету та гнучкого ціноутворення.

Чому нативна розробка iOS — найкращий вибір для складних додатків

Додаток крашиться на cold start — EXC_BAD_ACCESS в момент ініціалізації синглтона, який звертається до іншого синглтона, який ще не ініціалізований. Або: ViewController витікає в пам'яті, тому що closure захоплює self без [weak self], і цей ViewController висить у пам'яті через два переходи після того, як користувач його покинув. Це не гіпотетичні сценарії — це два найпоширеніші класи проблем на iOS-проектах, які приходять до нас після іншої команди.

Ми займаємося iOS-розробкою понад 6 років, реалізували 50+ проєктів — від стартапів до enterprise-рішень з мільйонами користувачів. Кожен проєкт проходить через 3 етапи Code Review, власний набір UI-тестів (в середньому 150+ тест-кейсів) та обов'язковий прогін через Xcode Instruments до релізу. Нативна iOS-розробка на Swift — це прямий доступ до платформи. Без прошарку, без компромісів щодо продуктивності, з повним контролем над тим, що відбувається на кожному кадрі.

Чому нативна розробка iOS на Swift — вибір для enterprise-додатків?

Нативний код дає гарантію сумісності з новими API Apple у день їх виходу, а не через місяці адаптації в кроссплатформних фреймворках. Для додатків із чутливою до затримок логікою (фінансові термінали, медичні монітори, AR-навігація) це критично. Swift з ARC та строгою типізацією дозволяє тримати crash-free rate на рівні 99.9% за правильної архітектури. На практиці середній показник на наших проєктах — 99.8%, що на 15% вище середнього по ринку.

Як вибрати між SwiftUI та UIKit для нативної розробки iOS?

На сьогодні SwiftUI покриває переважну більшість production-завдань. Але UIKit не застарів і не зникне — Apple не deprecate-ить його, а продовжує додавати API. Реальна картина на великих проєктах: гібридний підхід. SwiftUI для більшості екранів, UIKit там, де SwiftUI впирається в обмеження.

Які сценарії SwiftUI виграє беззаперечно

Декларативний синтаксис SwiftUI скорочує код UI у 3–5 разів порівняно з UIKit. Екран налаштувань з List, Toggle, Picker — це 40 рядків SwiftUI проти 200 рядків UIKit з делегатами UITableViewDataSource. Економія часу на UI-розробку досягає 60%. Apple рекомендує починати нові проєкти на SwiftUI (Human Interface Guidelines).

@State, @Binding, @ObservableObject (а з iOS 17 — макрос @Observable) створюють реактивний зв'язок між даними та UI без ручного reloadData(). Зміна @State-змінної автоматично перемальовує порушену частину ієрархії. Це працює правильно, якщо розуміти, як SwiftUI обчислює diff — через Equatable та id у ForEach.

AsyncImage, NavigationStack з типобезпечним роутингом через NavigationPath, searchable, refreshable — це готові патерни, які UIKit вимагає реалізовувати вручну.

Коли UIKit залишається необхідним

UICollectionView з compositional layout та diffable data source — складні сітки з різними типами комірок, горизонтальними секціями всередині вертикального скролу, динамічними розмірами комірок. SwiftUI LazyVGrid / LazyHGrid не дають такого контролю.

Кастомні переходи між екранами. UIViewControllerAnimatedTransitioning та UIViewControllerInteractiveTransitioning — інтерактивний pop gesture з частковим прогресом, кастомний hero-перехід з точним керуванням frame. SwiftUI matchedGeometryEffect покриває частину випадків, але не всі.

UITextView з TextKit 2. Багатий редактор тексту, кастомні атрибути, кастомний рендеринг — TextKit 2 (доступний з iOS 16) перейшов на async layout, що вирішило проблеми з продуктивністю на довгих документах. SwiftUI TextEditor — це обгортка навколо UITextView без прямого доступу до TextKit.

UIScrollView з кастомною поведінкою. scrollViewDidScroll, parallax-ефекти, sticky headers з кастомною логікою, pull-to-refresh з кастомним індикатором. SwiftUI ScrollView з scrollPosition та onScrollGeometryChange (iOS 17) закриває частину випадків, але не всі.

Як ми інтегруємо SwiftUI та UIKit: крок за кроком

1. Ідентифікуємо екрани, де SwiftUI дає максимальний виграш (списки, форми, налаштування) — зазвичай 70-80% екранів.
2. Для критичних до продуктивності ділянок (складні колекції, кастомні анімації) залишаємо UIKit.
3. Використовуємо UIHostingController для вбудовування SwiftUI-в'ю в UIKit navigation stack.
4. Для зворотної сумісності обгортаємо UIKit-компоненти через UIViewRepresentable.
5. Coordinator pattern (UIKit) керує навігацією на рівні флоу, екрани реалізовані на SwiftUI.

Один патерн, який ми використовуємо на проєктах: UIKit-координатор керує навігацією, а самі екрани на SwiftUI. Координатор створює UIHostingController, передає ViewModel через ініціалізатор або @EnvironmentObject, керує переходами. Це дає чисте розділення: SwiftUI займається UI, Coordinator — навігацією. Завдяки такому підходу ми скорочуємо час дебагу на 30% порівняно з чистим UIKit.

Як async/await та Combine працюють разом?

До Swift 5.5 асинхронний код на iOS будувався на Combine або callback-ланцюжках. З появою async/await та Actor модель конкурентності стала частиною мови. На нових проєктах ми використовуємо async/await як основний інструмент для мережевих викликів та бізнес-логіки, Combine — для реактивної прив'язки UI-стану.

@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false

    func loadUser(id: String) async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await userService.fetch(id: id)
        } catch {
            // обробити помилку
        }
    }
}

Combine залишається незамінним для дебаунсингу введення, об'єднання кількох Publishers (CombineLatest, Zip) та функціональної обробки потоку значень (map, flatMap, filter). На практиці 80% проєктів використовують обидва підходи, обираючи інструмент під задачу. Це дозволяє підвищити швидкість розробки на 20% без втрати якості.

Архітектура iOS-додатку

MVVM — базовий патерн. ViewModel містить логіку та @Published-стан, SwiftUI View підписується через @ObservedObject або @StateObject. Правило одне: View не знає про URLSession, CoreData, UserDefaults.

Clean Architecture додає шари Repository та UseCase. UserRepository абстрагує джерело даних (мережа vs кеш). FetchUserUseCase містить бізнес-правило. UserViewModel викликає UseCase та керує UI-станом.

TCA (The Composable Architecture) — більш строгий патерн від Point-Free. State, Action, Reducer, Effect — все явне, все тестоване, composable через Scope. Добре працює у великих командах (5+ iOS-розробників), де важлива передбачуваність поведінки.

Що входить у розробку iOS-додатку

Інструменти, без яких не обходиться жоден реліз

Xcode Instruments. Time Profiler показує, де CPU витрачає час. Allocations — витоки пам'яті та excessive allocations. Leaks — об'єкти, які не звільняються. Перед кожним релізом — обов'язковий прогін.

Firebase Crashlytics. Crash-free rate, групування по stack trace, breadcrumbs подій до крашу. Налаштовується за 30 хвилин, дає картину по всьому парку пристроїв. В середньому crash-free rate на наших проєктах — 99.8%.

Fastlane match. Керування сертифікатами та provisioning profiles через зашифрований git-репозиторій. Усуває «у мене локально збирається, а на CI ні» раз і назавжди. Економить до 4 годин на кожну збірку при ручному підписуванні.

XCTest + XCUITest. Unit-тести для ViewModel та UseCase, UI-тести для критичних флоу (онбординг, оплата, авторизація). В середньому код покритий на 75%.

Процес і терміни

Замовте розробку під ключ — ми оцінимо ваш проєкт за 2 робочі дні та запропонуємо оптимальну архітектуру. Зв'яжіться з нами, щоб обговорити вашу задачу: гарантуємо якість коду, дотримання App Store Review Guidelines та досвід роботи з проєктами будь-якого масштабу. Отримайте консультацію — ми допоможемо вибрати правильний стек та уникнути типових помилок на старті.