Нативна розробка iOS-застосунку на Swift
Swift — не просто заміна Objective-C. Це інший спосіб думати про архітектуру: строга типізація, value semantics, async/await замість callback hell, SwiftUI-декларативність замість імперативного UIKit. Застосунок, написаний з урахуванням цих принципів, простіше підтримувати та масштабувати.
Архітектура: що вибираємо та чому
Для більшості продуктових застосунків ми використовуємо Clean Architecture з MVVM на рівні presentation. Розділення на шари — Domain, Data, Presentation — дозволяє тестувати бізнес-логіку без UI та без залежності від конкретного фреймворку даних.
ViewModel на Swift Concurrency: @MainActor для публікації стану в UI-потік, Task для фонової роботи. Немає ручного DispatchQueue.main.async — компілятор перевіряє потокобезпеку через Sendable та actor isolation.
Навігація. UIKit: Coordinator Pattern — AppCoordinator управляє UINavigationController, дочірні координатори відповідають за флоу (AuthFlow, MainFlow, OnboardingFlow). Це ізолює навігаційну логіку від ViewController'ів. SwiftUI: NavigationStack з NavigationPath для програмної навігації, Router-об'єкт як EnvironmentObject.
Залежності. Swift Package Manager замість CocoaPods там, де це можливо. SPM — нативний інструмент, не потребує pod install та не ломає workspace. Для пакетів, ще не мігрованих у SPM (рідкість у 2024), використовуємо CocoaPods точково.
Типовий стек: Alamofire або нативний URLSession для мережі, Combine або async/await для реактивності, Kingfisher для кешування зображень, swift-composable-architecture (TCA) для особливо складних стейт-машин.
Де теряється час на старте
Cold start. Застосунок запускається повільно, якщо в application(_:didFinishLaunchingWithOptions:) відбувається занадто багато синхронної ініціалізації: SDK аналітики, Core Data stack, конфігурація Firebase. Рішення: ліниво ініціалізуємо некритичні сервіси, важкі операції на background queue, MetricKit для моніторингу часу запуску у продакшені.
Memory leaks у замиканнях. Класика: [weak self] забули в closure, переданому в NotificationCenter або Timer. Instruments → Leaks + Memory Graph Debugger — обов'язкова частина процесу до релізу. Xcode 15 додав попередження компілятора для частини таких випадків, але не для всіх.
UITableView та UICollectionView з важкими ячейками. Декодування JPEG на main thread при cellForRowAt — FPS падає при швидкому скролі. Переносимо декодування на background через ImageIO з явним kCGImageSourceShouldCacheImmediately: true, заповнюємо ячейку вже готовим CGImage. На iPhone SE 2nd gen різниця між правильним та неправильним підходом — 8 FPS vs 60 FPS при скролі ленти.
SwiftUI vs UIKit: як приймаємо рішення
| Критерій | UIKit | SwiftUI |
|---|---|---|
| iOS мінімум | iOS 13+ нормально, iOS 12- | iOS 14+ для стабільної роботи |
| Кастомні анімації | Повний контроль через Core Animation | Обмежені, але розширюються з кожною версією |
| Продуктивність списків | UICollectionView Compositional Layout — найкраща у класі | List достатня для більшості; LazyVStack для кастома |
| Команда | UIKit знають всі iOS-розробники | SwiftUI потребує переосмислення паттернів |
| Складні жести | UIGestureRecognizer — максимальний контроль |
gesture modifier + GestureState — достатньо у більшості випадків |
Для нових проектів з iOS 16+ мінімумом — SwiftUI як основа, UIKit для компонентів, де SwiftUI ще не дотягує (кастомні клавіатурні аксесуари, деякі жестові взаємодії). Для підтримки iOS 14 — гібрид, де UIKit backbone та SwiftUI-екрани через UIHostingController.
Процес розробки
Старт проекту: аналіз вимог → технічне проектування архітектури → узгодження → розробка по спринтам. Кожен модуль супроводжується unit-тестами на бізнес-логіку (XCTest), критичні UI-флоу — UI-тестами (XCUITest).
CI/CD через Fastlane: fastlane test на кожен PR, fastlane beta для TestFlight, fastlane release для App Store. Сборки для тестувальників — автоматично при мерже в develop.
Firebase Crashlytics — підключаємо на початку проекту, не перед релізом. Краші у TestFlight ловимо заздалегідь.
Що впливає на строки
- Кількість екранів та складність навігаційного флоу
- Інтеграції: платежі (StoreKit 2), авторизація (Sign in with Apple, OAuth), карти (MapKit), камера/фото (AVFoundation, PhotosUI)
- Необхідність підтримки iPad / Mac Catalyst
- Наявність готового дизайну та API
Прямолінійне застосунок (авторизація, лента, профіль, деталі): 3–4 тижні. Продукт зі складною бізнес-логікою, кастомними компонентами та інтеграціями: 2–3 місяці. Вартість розраховується індивідуально після оцінки ТЗ.