iOS / Swift

Хто тримає цей об’єкт живим — шістнадцять посилань, які тримає iOS-застосунок

У Swift об’єкт — екземпляр класу — живе рівно доти, доки щось тримає на нього сильне посилання. Щойно зникає останнє, об’єкт звільняється на місці. Ніщо не приходить потім шукати об’єкти, до яких уже ніхто не може дістатися, як це робить збирач сміття (garbage collectorgarbage collectorзвільняє пам’ять, яку ніхто не використовуєЧастина середовища виконання, що знаходить об’єкти, на які вже ніщо не посилається, і звільняє їхню пам’ять, тож програма ніколи не звільняє її вручну. Ціна — додаткова пам’ять і робота, яку програма не планує, — паузи, короткі чи довгі залежно від збирача.Докладніше в статті →Усі терміни) на Android чи в Java. Тож екран, який мав звільнитися й не звільнився, ніколи не є падінням. Це пам’ять, що росте; таймер, що далі спрацьовує для екрана, якого ніхто не бачить; мережевий колбек, що оновлює в’ю, якої вже немає. Отже, корисне питання до будь-якого посилання — не «чи це витік?». Воно таке: «хто кого тримає і що змушує їх відпустити?». Ось шістнадцять посилань, які iOS-застосунок тримає щодня. Наступні розділи посилаються на рядки за номерами.

Підрахунок посилань: що Swift робить замість збирача сміття

Automatic Reference Counting, ARC, легко сформулювати. Кожен екземпляр класу несе лічильник сильних посилань, що на нього вказують. Компілятор вставляє збільшення там, де посилання зберігають, і зменшення там, де воно зникає, тож самі ви їх ніколи не пишете. Коли лічильник доходить до нуля, виконується deinit і пам’ять повертається — негайно, у тому самому потоці виконання. Ця детермінованість — справжня перевага. Немає пауз на збирання; відпущене зображення звільняє пам’ять тієї миті, коли його відпускає останній екран; файл, закритий у deinit, закривається в передбачуваній точці. Ціна — саме те, про що таблиця: підрахунок не бачить циклу. Два об’єкти, що тримають один одного, назавжди тримають лічильники одне одного на одиниці.

Друга половина моделі — значення. Структура, перелік, кортеж — а також String, Array, Dictionary і Set, які в Swift є структурами, — копіюються під час присвоєння чи передачі, тож дві змінні ніколи не ділять одного значення й рахувати нічого. Стандартні колекції роблять це дешевим через copy-on-write: дві копії ділять один буфер, доки одну з них не змінять, і лише тоді буфер дублюється. Тому ідіоматичний Swift починається зі структури й тягнеться до класу лише тоді, коли важить ідентичність: один спільний об’єкт, за яким стежать кілька екранів, або ресурс із власним часом життя, як-от з’єднання чи плеєр. Рядки 1–3 таблиці прості саме тому, що більша частина програми на Swift — значення.

Знайти цикл — справа секунд, щойно почнеш шукати. Поставте print чи точку зупину в deinit екранів, які вас турбують: якщо він не спрацьовує, коли ви йдете з екрана, — щось досі цей екран тримає. Memory Graph Debugger у Xcode тоді намалює об’єкти, що його тримають, зі стрілками й усім іншим, і позначить витоки, які може довести. Шаблон Allocations в Instruments відповідає на питання обсягу: відкрийте й закрийте той самий екран десять разів, і кількість живих екземплярів його контролера в’ю має повернутися до початкової. Лічильник, що росте на одиницю за кожен візит, — це рядки 6–16 одним числом.

На iOS витоки важать більше, ніж підказує їхній розмір, бо система не вивантажує пам’ять застосунку на диск. Коли пам’яті бракує, вона завершує застосунки — спершу фонові, — і застосунок на передньому плані, що виріс понад власну межу, теж завершують. Це називається jetsam-подією. Для користувача це виглядає як падіння; розробникові ж воно не приходить звичайним звітом про падіння, а з’являється в лічильниках завершень через пам’ять в Organizer у Xcode і в MetricKit. Звичайна причина — зображення, з тієї самої причини, що на сторінці про React Native: декодоване зображення займає ширина × висота × 4 байти, тож фото на 12 мегапікселів займає 48 МБ, хоч яким маленьким був JPEG.

SwiftUI чи UIKit — і кому належить стан

На платформі два UIUIUser Interface — те, що бачить користувачУсе, що користувач бачить і чим керує: екрани, кнопки, поля, стани. UI відповідає за те, ЯК виглядає взаємодія; чи має вона сенс узагалі — це вже питання UX, і ці два поняття плутають постійно.Усі терміни-фреймворки, і iOS-розробник, що працює, читає обидва. UIKit, присутній від першого iPhone SDKSDKSoftware Development Kit — готовий набір для платформиЗібраний набір бібліотек, інструментів і прикладів для роботи з чужою платформою. Відмінність від API в тому, що API лише описує правила, а SDK дає код, який уже вміє за цими правилами говорити.Усі терміни 2008 року, імперативний: ви створюєте в’ю, тримаєте на них посилання й змінюєте їх, коли приходять події. SwiftUI, що з’явився з iOS 13 у 2019 році, декларативний: ви описуєте, який вигляд має екран для заданого стану, а фреймворк сам вираховує, що змінити, — та сама модель, що й у React, до якої дійшли незалежно. Більшість нових екранів пишуть на SwiftUI. Більшість наявних застосунків — це UIKit, усередині якого росте SwiftUI, і обидва взаємодіють в обидва боки: UIHostingController кладе SwiftUI всередину UIKit, а UIViewRepresentable — UIKit-в’ю всередину SwiftUI.

Один факт пояснює майже кожну несподіванку SwiftUI: в’ю у SwiftUI — це структура. Це опис, дешевий у створенні й викинутий після використання, і SwiftUI створює нові його значення щоразу, коли знову виконується body батька, — десятки разів на завантаженому екрані. Тож стан не може жити в структурі. Обгортки властивостей на кшталт @State кажуть SwiftUI тримати сховище поза в’ю, прив’язаним до її ідентичності — місця в ієрархії, — і віддавати його кожному новому значенню структури. Коли ідентичність змінюється, стан іде разом із нею: в’ю, перенесена між гілками if або отримала новий .id, починає знову з початкового значення. Це те саме правило, що й ключі в React, і той самий клас баґів.

Що дає ваша мінімальна версія iOS

SwiftUI постачається всередині операційної системи, а не всередині вашого застосунку, тож найстаріша підтримувана iOS вирішує, який SwiftUI у вас є. Можливості, доданої в iOS 17, на телефоні з iOS 16 просто немає, і коду, що нею користується, потрібна гілка if #available із запасним варіантом. Тому мінімальна версія — продуктове рішення з ціною з обох боків: занизька — і команда пише запасні варіанти для того, що фреймворк уже вміє; зависока — і частина користувачів не зможе встановити наступне оновлення. Нові версії iOS приймають швидко, тож більшість команд підтримують поточну версію й одну-дві попередні.

Ще одна різниця між ними проявилася 2025 року. Обидва малює операційна система, тож коли iOS 26 перемалювала свої елементи керування в стилі Liquid Glass, кожен застосунок на SwiftUI та UIKit, перезібраний з iOS 26 SDK, отримав новий вигляд — панелі вкладок, навігаційні панелі, перемикачі, alert-діалоги — без жодного рядка коду. Apple дозволила відмовитися на рік через ключ UIDesignRequiresCompatibility, і цей ключ ігнорується, щойно застосунок збирають з iOS 27 SDK. Сторінка про Flutter показує, що цей редизайн зробив із застосунками на SwiftUI, React Native і Flutter поруч; для нативного застосунку робота — це власні намальовані в’ю, які змінюються, лише коли їх змінюєте ви.

Паралельність у Swift: хто має право торкатися цього стану

Одне правило на цій платформі не змінюється ніколи: інтерфейсу торкаються лише з головного потоку. Головний потік до того ж має наглядача. Watchdog завершує застосунок, що не встиг вчасно намалювати перший кадр або перестав відповідати, і звіт про падіння несе код 0x8badf00d — «ate bad food». Власна документація Apple показує класичну причину: Data(contentsOf:) з адресою https виглядає як читання файлу, а тихо робить синхронний мережевий запит у тому потоці, який його викликав. В офісній мережі це мілісекунди. У потязі — достатньо довго для watchdog.

Відповідь Swift, додана у Swift 5.5 2021 року, має три частини. async і await дозволяють функції чекати на мережеву відповідь чи файл, не блокуючи свого потоку: на кожному await функція поступається, і потік робить іншу роботу. Актор — це тип, що захищає власний стан, пускаючи всередину по одній задачі, тож дві задачі не можуть одночасно змінювати той самий словник. @MainActor — актор, що означає головний потік, тож позначка ним на моделі в’ю дає компілятору, а не код-рев’ю, перевірити, що її методи виконуються саме там. Третя частина — Sendable: тип, який безпечно переходить від одного актора до іншого, бо він значення або сам охороняє свій стан.

Swift 6 у вересні 2024 року зробив перевірки помилками, а не попередженнями, у своєму новому мовному режимі: код, що міг дати двом потокам торкнутися того самого змінного стану без координації, перестає компілюватися. Гонка за даними (data racedata raceдва потоки, одна змінна, без блокуванняДва потоки чи горутини одночасно звертаються до тієї самої памʼяті, принаймні один із них пише, і впорядкувати ці звернення нічим. Результат невизначений — хибне значення, «розірване» читання чи падіння набагато пізніше, — і, на відміну від стану гонки в логіці, його можна виключити механічно: детектором гонок або, у Rust, компілятором.Докладніше в статті →Усі терміни) стала помилкою компіляції — той самий хід, що Rust зробив із володінням. Перші міграції були важкими, бо більшість коду застосунків ніколи не казала, якому актору належить, і компілятор позначав це всюди. Swift 6.2 у вересні 2025 року змінив типові налаштування, а не правила. Модуль тепер може зробити все @MainActor, якщо не позначено інакше; async-функція, не прив’язана до актора, виконується на акторі того, хто її викликав, а не стрибає у фоновий потік; а @concurrent позначає функції, які мають піти. Xcode 26 увімкнув обидва налаштування для нових проєктів застосунків. Тож сучасна точка відліку — однопотокова: код виконується на головному акторі, а робота йде з нього свідомо.

Випуск: рев’ю, TestFlight і семиденне розгортання

Те, що дивує команди з вебу, — випуск тут не є деплоєм. Кожен бінарник проходить App Review, перш ніж хтось поза командою зможе його встановити. Apple каже, що в середньому 90% заявок переглядають менш ніж за 24 години і що понад 40% проблем, які зупиняють заявку, підпадають під пункт 2.1 правил, App Completeness: падіння, заглушки замість вмісту, демо-акаунт, яким рецензент не зміг увійти. Для критичного виправлення є прискорене рев’ю, яке Apple надає в кожному випадку окремо. А з червня 2020 року виправлення помилок для застосунку, що вже в магазині, не затримують через порушення правил, якщо питання не юридичне; розділ кейсів розповідає, звідки взялося це правило.

Обійти бінарник неможливо. Swift компілюється заздалегідь у машинний код, а угода Developer Program License Agreement дозволяє завантажуваний код, лише якщо він інтерпретований і не змінює основного призначення застосунку, — саме це дозволяє React Native надсилати оновлення «по повітрю» (over-the-airover-the-airоновлення встановленого ПЗ віддаленоОновлення, яке доставляють мережею до ПЗ, уже встановленого на пристрої, без перевстановлення користувачем, — JavaScript-бандл для застосунку на React Native, прошивка для телефона чи дрона. На iOS і в Google Play так може приходити лише інтерпретований код; нативний потребує нової збірки й ревʼю магазину.Докладніше в статті →Усі терміни), а сторінка про React Native цитує цей пункт. Без релізу нативний застосунок може змінити лише те, що його збудовано читати: вміст, яким керує сервер, віддалену конфігурацію, feature flagfeature flagперемикач навколо нового кодуПеремикач, що під час роботи вирішує, чи активний шматок коду, — тож код може потрапити в продакшен вимкненим і бути ввімкненим для обраної аудиторії пізніше. Він відділяє деплой від релізу й має ціну: кожен живий прапорець — це розгалуження в коді, яке має працювати в обох станах.Докладніше в статті →Усі терміни, що вмикає код, уже наявний у бінарнику. Усе інше чекає наступної збірки, і саме тому важить порядок кроків нижче.

TestFlight — крок перед магазином. До 100 внутрішніх тестувальників із доступом до App Store Connect команди отримують збірку, щойно вона пройде обробку. До 10 000 зовнішніх тестувальників приєднуються за запрошенням чи публічним посиланням; перша збірка для них проходить Beta App Review. Кожну збірку можна встановлювати 90 днів. Далі — сам реліз і найкорисніший перемикач в App Store Connect: поетапний реліз (phased releasestaged rolloutоновлення для дедалі більшої частки користувачівВипуск оновлення спершу для невеликої частки користувачів — 1%, потім 5%, 20%, усі — з перевіркою частоти падінь і помилок перед кожним кроком, щоб поганий реліз дійшов до небагатьох, а не до всіх. Воно обмежує, до скількох людей дійде поганий реліз, а не те, чи дійде він узагалі: у магазинах застосунків зупинене розгортання не забирає оновлення в тих, хто його вже має.Усі терміни). Оновлення отримує 1% користувачів першого дня, далі 2%, 5%, 10%, 20%, 50% — і всі на сьомий день. Його можна поставити на паузу сумарно до 30 днів або відкрити всім одразу.

Календар Apple — вимоги, що діють близько до дати цієї сторінки

Яка iOS-кодова база перед вами

П’ять кейсів і те, чого в кожному бракувало

Нативна iOS-команда успадковує дві речі, яких не контролює: код кожного SDK, який вона постачає, і правила компанії, що тримає магазин. Усі п’ять кейсів — про одне чи друге, і кожен задокументували ті, кого він стосувався: issue на GitHub, заява компанії, власні оголошення Apple.

Перший кейс показує, що може зробити SDK на старті. 6 травня 2020 року, з 14:44 за тихоокеанським часом, застосунки з вбудованим iOS SDK від Facebook почали падати тієї ж миті, коли їх відкривали, — Spotify, Pinterest, TikTok, Venmo, Tinder та інші, зокрема в користувачів, які ніколи не входили через Facebook. Issue, відкритий на GitHub того ж дня, вказав на один рядок: SDK на старті завантажував конфігурацію із серверів Facebook і читав одне зі значень як словник, а сервер почав надсилати щось інше. Facebook виправив це на сервері за кілька годин. 10 липня 2020 року це сталося знову — через той самий компонент. Постраждалі застосунки нічого не зробили неправильно у власному коді. Їм бракувало дистанції: SDK, ініціалізований на шляху старту, ще до першого екрана, без перемикача, щоб вимкнути його віддалено, і без стійкості до сервера, що відповідає в неочікуваній формі.

Третій кейс — операційна система робить видимим те, що код робив завжди. У червні 2020 року перша бета iOS 14 почала показувати невеликий банер щоразу, коли застосунок читав буфер обміну. За кілька днів користувачі виклали записи: TikTok читав його що кілька натискань, LinkedIn — на кожне. TikTok назвав це функцією проти спаму й прибрав її; LinkedIn назвав це баґом. Банерові було байдуже, чий код читав буфер обміну — власний код застосунку чи SDK усередині нього, — і саме в цьому суть: команда відповідає за все, що робить її бінарник. У травні 2024 року Apple перетворила це на вимогу: завантаження мусить декларувати схвалену причину для кожного API з обов’язковою причиною, який воно викликає, зокрема через сторонні SDK. Четвертий кейс — той самий патерн у більшому масштабі. З iOS 14.5, 26 квітня 2021 року, застосунок мусив спитати, перш ніж відстежувати людину в застосунках інших компаній, і система показує цей запит один раз. У лютому 2022 року Meta сказала інвесторам, що ця зміна коштуватиме їй близько $10 млрд того року, — оцінка, як сказав фінансовий директор, і єдине опубліковане число такого масштабу. Типову поведінку, якою володіє платформа, платформа може змінити.

Де це вироджується

Нативна iOS щедра там, де команда дисциплінована, і мовчить там, де ні. Компілятор щороку ловить більше — з Swift 6 і гонки за даними, — але він досі не скаже, що екран так і не звільнився, що SDK читає буфер обміну чи що наступна вимога до SDK — за пів року. Майже кожен збій — одне з цього:

• Збережені замикання й делегати, що сильно захоплюють свого власника, течуть тихо й ніколи не падають (рядки 6–9).
• Таймери, display link, сесії й обробники вебв’ю, які ніхто не анулює (рядки 12–15).
• Задача, що крутиться вічно й тримає з собою свій екран (рядок 11).
• unowned там, де мався на увазі weak, — витік перетворюється на падіння на повільній мережі.
• Модель, створена всередині @ObservedObject, що скидається щоразу, коли оновлюється батько.
• Синхронна робота в головному потоці — файл, декодування, прихований мережевий виклик, — доки watchdog це не завершить.
• Continuation, не відновлений на кожному шляху, — і екран, що вантажиться вічно.
• Сторонні SDK, запущені на старті, без способу їх вимкнути й без переліку того, що вони читають.
• Запити дозволів на старті, а не тієї миті, коли вони потрібні фічі, — система питає один раз.
• Вимоги Apple — видалення, маніфести приватності, життєвий цикл на сценах, мінімальний SDK, — виявлені в день, коли мав вийти реліз.

Чесна межа — сама платформа. Нативний iOS-застосунок — найкраща версія застосунку на iPhone: найновіші API з першого дня, власні елементи керування платформи та їхні редизайни задарма, детермінована пам’ять, компілятор, що виключає гонки за даними. І це одна платформа. Продукт, якому потрібен ще й Android, платить за другу нативну команду, за кросплатформний шар або — як вирішив Shopify у вересні 2026 року, про що розповідає сторінка про React Native, — за агентів для програмування, що перекладають між двома; безкоштовного варіанта немає. І кожен реліз досі проходить через рев’ю однієї компанії та її календар. Команда, що планує з урахуванням обох, вважає їх частиною графіка, а не погодою.

Практична перевірка займає десять хвилин. Прочитайте мінімальну версію iOS і версію Xcode й знайдіть їх у таблиці календаря. Пошукайте в коді var delegate: без weak, Timer.scheduledTimer(, addObserver(forName:, .sink { без списку захоплення, URLSession(configuration: із делегатом і add(self, name:. Відкрийте й закрийте три найнавантаженіші екрани по десять разів із відкритим Memory Graph Debugger. Перевірте, що Info.plist декларує маніфест сцен. Подивіться на мовний режим Swift і рівень перевірки паралельності кожної цілі збірки. І переконайтеся, що наступний реліз налаштовано на поетапний.

Коли це застосовувати

Пов’язані сторінки

• РозробкаAndroid / KotlinРозробка під Android — це створення застосунків мовою Kotlin для системи, що володіє часом життя застосунку й може будь-коли перебудувати екран чи вбити процес. Цей один факт пояснює найчастіший баґ платформи — екран, що повертається порожнім, — і майже кожну архітектурну рекомендацію Google. Сторінка починається з шістнадцяти подій, що знищують екран, і того, що переживає кожну; далі — смерть процесу й збережений стан, Kotlin і корутини до версії 2.4, Compose і його три фази, фонова робота, доріжки Google Play і його календар на 2026 рік, п’ять задокументованих кейсів і те, де все це вироджується.
• РозробкаReact NativeReact Native — це фреймворк, який виконує React-компоненти в рушії JavaScript на телефоні й перетворює їх на справжні в’ю iOS та Android, а не на вебсторінку. Через цей поділ вебкоманда може випустити застосунок, що відчувається нативним, — і через нього ж типовий збій тут — екран, який перестає відповідати, поки JavaScript зайнятий. Сторінка починається з шістнадцяти речей, які робить екран, і того, що рухається далі, коли потік JavaScript заблоковано; далі — нова архітектура, списки й зображення, Expo й оновлення «по повітрю», релізи до 0.87 і дедлайни магазинів на 2026 рік, що насправді спільне, п’ять задокументованих кейсів, зокрема повернення Shopify до нативу у вересні 2026 року, і те, де все це вироджується.
• РозробкаFlutterFlutter — це UI-фреймворк від Google, який малює кожен піксель застосунку власним рушієм з однієї кодової бази на Dart для iOS, Android, вебу й десктопа. Через цей вибір застосунок на Flutter виглядає однаково всюди й не змінюється, коли змінюється операційна система, — навіть коли вона змінюється навмисно, як це зробила iOS 26. Сторінка починається з шістнадцяти речей, які потрібні застосунку, і того, малює їх Flutter чи мусить просити платформу; далі — три дерева й бюджет кадру, ціна перебудови, Dart та ізоляти, межа з платформою й редизайни ОС, релізи до Flutter 3.47, п’ять задокументованих кейсів і те, де все це вироджується.