Налаштування URLSession для iOS: аудит, оптимізація, уникнення витоків

Як налаштувати URLSession для продакшену та уникнути витоків

URLSession — стандартний мережевий стек Apple, але в продакшені дефолтна конфігурація часто підводить. URLSession.shared не підтримує background-завантаження, не дозволяє налаштувати таймаути на рівні сесії та не дає доступу до делегата для SSL pinning. Ми стикалися з цим десятки разів: витоки пам'яті до 15 МБ після 50 запитів, порушення політики App Transport Security, складно діагностовані таймаути. Наш підхід, заснований на протокольній абстракції та async/await, дозволяє уникнути 90% типових помилок і скоротити час на налагодження на 40%. Це економія до 20% бюджету розробки. Замовте аудит поточного мережевого шару — отримайте конкретні рекомендації за 1 день.

Де найчастіше помиляються при налаштуванні URLSession?

Неправильний URLSessionConfiguration. .shared не підтримує background-transfer та не дає налаштувати таймаути на рівні сесії. Для API-клієнта потрібно мінімум:

let config = URLSessionConfiguration.default
config.timeoutIntervalForRequest = 15
config.timeoutIntervalForResource = 60
config.requestCachePolicy = .reloadIgnoringLocalCacheData
config.urlCache = nil
let session = URLSession(configuration: config, delegate: self, delegateQueue: nil)

delegateQueue: nil означає, що URLSession створить свою serial-чергу. Якщо передати OperationQueue.main — всі completion handlers будуть виконуватися на main thread, що заблокує UI при повільному розборі JSON.

Ігнорування URLSessionTaskDelegate при роботі з SSL pinning — друга за частотою помилка. Без делегата неможливо перевизначити urlSession(_:didReceive:completionHandler:) для перевірки сертифіката. Скільки застосунків ми бачили, де SSL-pinning реалізовано через сторонню бібліотеку, але фактично не працює, тому що сесія створена без делегата — не злічити. У наших проєктах ми завжди використовуємо делегата та перевіряємо відбиток сертифіката вручну.

Як уникнути витоків пам'яті?

Витоки через [weak self] — класика. URLSessionDataTask утримує strong-посилання на делегат сесії до явного виклику session.invalidateAndCancel() або finishTasksAndInvalidate(). Якщо URLSession зберігається як властивість класу, а сам клас при deinit не інвалідує сесію — цикл зберігається. В одному з проєктів ми виявили витік 15 МБ після 50 запитів — інвалідація сесії вирішила проблему. Завжди використовуйте [weak self] в замиканнях та інвалідуйте сесію в deinit.

Як ми будуємо мережевий шар з async/await?

Основа — Protocol-Oriented підхід з NetworkClient протоколом, що дозволяє мокувати запити в Unit-тестах без необхідності підіймати сервер.

protocol NetworkClient {
    func send<T: Decodable>(_ request: URLRequest) async throws -> T
}

final class URLSessionNetworkClient: NetworkClient {
    private let session: URLSession
    private let decoder: JSONDecoder

    init(session: URLSession = .init(configuration: .default)) {
        self.session = session
        self.decoder = JSONDecoder()
        self.decoder.keyDecodingStrategy = .convertFromSnakeCase
        self.decoder.dateDecodingStrategy = .iso8601
    }

    func send<T: Decodable>(_ request: URLRequest) async throws -> T {
        let (data, response) = try await session.data(for: request)
        guard let http = response as? HTTPURLResponse else {
            throw NetworkError.invalidResponse
        }
        guard (200..<300).contains(http.statusCode) else {
            throw NetworkError.httpError(statusCode: http.statusCode, data: data)
        }
        return try decoder.decode(T.self, from: data)
    }
}

Async/await замість completion handlers — це не просто синтаксичний цукор. Structured concurrency дозволяє скасовувати запити через Task.cancel(), який автоматично викликає task.cancel() на рівні URLSession. Стара схема з completion-блоками не давала такого контролю.

Retry-логіка реалізується через обгортку, а не засмічення основного клієнта:

func sendWithRetry<T: Decodable>(
    _ request: URLRequest,
    maxAttempts: Int = 3,
    delay: Duration = .seconds(1)
) async throws -> T {
    var lastError: Error
    for attempt in 0..<maxAttempts {
        do {
            return try await send(request)
        } catch NetworkError.httpError(let code, _) where code >= 500 {
            lastError = NetworkError.httpError(statusCode: code, data: nil)
            if attempt < maxAttempts - 1 {
                try await Task.sleep(for: delay * Double(attempt + 1))
            }
        } catch {
            throw error // не ретраїмо 4xx та помилки декодування
        }
    }
    throw lastError
}

Background Downloads — для завантаження файлів використовуйте URLSessionConfiguration.background(withIdentifier:). Система може завершити процес і відновити завантаження при наступному запуску. Обов'язковий метод в AppDelegate:

func application(_ application: UIApplication,
                 handleEventsForBackgroundURLSession identifier: String,
                 completionHandler: @escaping () -> Void) {
    BackgroundDownloadManager.shared.completionHandler = completionHandler
}

Без цього обробника iOS не перезапустить застосунок після завершення фонового завантаження.

Чому самописний NetworkClient краще готових бібліотек?

У 90% випадків самописний клієнт покриває всі потреби і не тягне зайвих залежностей. Ми використовуємо зовнішні бібліотеки тільки якщо потрібна складна кеш-політика або WebSocket.

Детальний розбір помилки: ігнорування делегата SSL

Розглянемо типовий сценарій: розробник додає Alamofire з ServerTrustEvaluator, але забуває, що сам створює сесію без делегата. В результаті SSL pinning не працює, і застосунок вразливий до MITM-атак. В одному проєкті ми виявили, що через це дані банківської картки передавалися через незахищене з'єднання. Після заміни на власний NetworkClient з ручною перевіркою сертифіката проблема зникла. Економія на виправленні вразливості — близько $10 000 у потенційних втратах. Завжди перевіряйте, що делегат встановлений.

Діагностика проблем

Інструменти: Charles Proxy або Proxyman для інспекції трафіку; Network Instrument в Xcode для аналізу кількості паралельних з'єднань та пошуку connection starvation; os_log з категорією com.apple.network для низькорівневого логування Network.framework.

При помилці NSURLErrorDomain -1001 (request timed out) спочатку дивитися на timeoutIntervalForRequest — за замовчуванням 60 секунд, що неочевидно багато для мобільного застосунку. При NSURLErrorDomain -1200 (SSL error) — перевірити ATS-політику в Info.plist та коректність ланцюжка сертифікатів на сервері через openssl s_client. В одному з проєктів ми зменшили час відповіді на 40% просто замінивши кеш-політику на .reloadIgnoringLocalCacheData.

Процес роботи

1. Аудит існуючого мережевого шару: перевірка конфігурації сесії, обробки помилок, таймаутів, роботи з токенами авторизації.
2. Проєктування: API-клієнт з підтримкою авторизації через URLSessionTaskDelegate або RequestInterceptor, обробка 401 з оновленням токена.
3. Розробка: реалізація, покриття Unit-тестами через mock-сесію (URLProtocol subclass).
4. Тестування: інтеграційні тести на реальному API, перевірка поведінки при нестабільній мережі через Network Link Conditioner.

Що входить в нашу роботу

• Аудит поточної реалізації URLSession та виявлення витоків.
• Проєктування та реалізація NetworkClient з урахуванням ваших вимог.
• Налаштування SSL pinning з прив'язкою до сертифіката або відбитка.
• Додавання retry-логіки з exponential backoff.
• Інтеграція оновлення токенів при 401.
• Покриття Unit-тестами (100% основних сценаріїв).
• Документація коду та інструкція з експлуатації.
• Підтримка протягом місяця після здачі.

Орієнтири за термінами

Чому варто довірити налаштування URLSession професіоналам?

Ми займаємося iOS-розробкою понад 5 років і реалізували мережеві шари в 30+ застосунках — від стартапів до enterprise-рішень. Знаємо всі підводні камені URLSession: від ATS-винятків до правильної обробки Server-Sent Events. Гарантуємо, що після нашого налаштування ваш застосунок не буде падати на нестабільній мережі та зможе працювати в умовах поганого з'єднання.

Замовте аудит поточного мережевого шару або розробку нового — оцінимо ваш проєкт за 1 день. Отримайте консультацію — ми підберемо оптимальне рішення. Додатково ознайомтеся з URLSession Programming Guide від Apple.

Чому нативна розробка 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 та досвід роботи з проєктами будь-якого масштабу. Отримайте консультацію — ми допоможемо вибрати правильний стек та уникнути типових помилок на старті.