Чому iPhone закриває важкі застосунки першими

Якщо ваш застосунок створено на Flutter або React Native, iOS з більшою ймовірністю закриє його саме тоді, коли клієнт ще ним користується. Не «впаде» — саме закриється: тихо, у фоні. А коли клієнт повернеться, він отримає порожній застосунок.

Це найменш зрозуміла ціна кросплатформного фреймворку — і вона не потрапляє в жоден звіт про збої. Ось як це працює і чого вам коштує.

Чому iPhone закриває застосунок, а не сповільнює його?

Будь-який інший комп’ютер реагує на брак пам’яті сповільненням. Він переносить на диск те, чого ви давно не торкалися, лишає все відкритим і працює далі. Повільно — але нічого не втрачено.

Телефон на iOS так із застосунками не робить. Коли пам’яті бракує, він обирає застосунок і закриває його. Ані попередження, ані діалогового вікна клієнт не побачить. Застосунок просто зникає, а пам’ять, яку він тримав, повертається телефону.

В Apple є назва для показника, за яким оцінюють ваш застосунок. Це обсяг спожитої пам’яті, або memory footprint, і те, як його рахують, пояснюють у сесії WWDC про пам’ять в iOS. Apple також описує, як читати звіти, що лишаються після таких закриттів — саме з них розробники взагалі дізнаються, що це сталося.

Комерційно важлива тут логіка вибору. Першими закривають найважчі застосунки.

Ваш клієнт не бачить збою. Він бачить застосунок, який усе забув

Це варто уявити, бо для людини, з якою це стається, воно зовсім не схоже на помилку.

Клієнт на половині оформлення замовлення. Він перемикається на банківський застосунок, щоб переписати номер картки. За двадцять секунд повертається — і ваш застосунок відкривається зі стартового екрана. Кошик порожній. Форма порожня. Можливо, доведеться заходити в акаунт заново.

Жодного збою не було. iOS закрила ваш застосунок у фоні, щоб звільнити пам’ять для того, що на екрані, — рівно так, як і задумано. Ваш моніторинг збоїв не покаже нічого, бо збою не було.

Ціна цього — не технічна:

• Покинуті кошики в найгірший момент — клієнт уже вирішив купити
• Повторні входи в акаунт, а це найчастіша скарга у відгуках в App Store
• Звернення в підтримку на кшталт «мене постійно викидає з акаунта», які майже неможливо відтворити на новому телефоні розробника
• Відгуки в дусі «застосунок нічого не запам’ятовує» — і такий відгук висить ще довго після того, як ви все виправили

На старших і дешевших iPhone усе гірше. Пам’яті менше, тож застосунки закриваються раніше й частіше. Це нерідко саме ті клієнти, яких ви найменше можете дозволити собі втратити, — і ніколи не той телефон, на якому тестує ваша команда.

Про яку різницю в пам’яті йдеться?

У єдиному опублікованому тесті на iPhone, де той самий застосунок зібрано на нативному Swift, на Flutter і на React Native та виміряно всі три однаково, одна прокрутка списку зі 100 елементів додала:

Створено на	Приріст пам’яті за одну прокрутку	Порівняно зі Swift
Нативний Swift	9,74 МБ	—
Flutter	25,33 МБ	у 2,6× більше
React Native	45,13 МБ	у 4,6× більше

SynergyBoat, серпень 2025. Один навчальний застосунок з картками, зібраний чотирма способами, iPhone 16 Plus, по три запуски. Результат React Native до того ж сильно стрибав між запусками — читайте його як «приблизно в чотири-п’ять разів», а не точно 4.6.

Через самі по собі 45 МБ застосунок ніхто не закриває. Саме це й пропускають. Це приріст від однієї дії. Клієнт гортає список, відкриває товар, вертається, гортає знову — і за сесію все це накопичується.

Застосунок, який росте найшвидше, першим дістається межі. На найдешевшому телефоні. Посеред оформлення замовлення.

Які функції ви не зробите взагалі?

Усередині застосунку пам’ять — це питання міри: важчий закривають раніше. Поза застосунком це вже глуха стіна.

Віджети на головному екрані, Live Activities на екрані блокування, меню «Поділитися» та власні клавіатури працюють у значно меншому бюджеті пам’яті, ніж сам застосунок. Розробники, які вперлися в цю стіну, називають ліміт віджетів приблизно в 30 МБ. Ця цифра походить із логів збоїв, які публікували розробники, а не зі специфікації Apple, тож сприймайте її радше як спостережений порядок величини, ніж як офіційне число.

Хай там як, бюджет малий — настільки, що власна документація React Native попереджає: споживання пам’яті «зазвичай завелике» для найтісніших із цих бюджетів.

Наслідок наздоганяє команди пізно, і знати про нього варто до вибору: якщо віджети чи Live Activities важливі для вашого продукту, цю частину все одно писатимуть на Swift — хоч би на чому ви створили основний застосунок. Кросплатформний фреймворк не прибирає нативну роботу. Він її переносить — і тепер ви платите за два набори навичок замість одного.

Що з цим робити?

Усе це не означає, що кросплатформність — хибний вибір. Це означає, що різниця в пам’яті — реальна ціна з конкретною назвою, і їй місце в рішенні, а не серед дрібниць, від яких відмахуються.

• Тестуйте на найстарішому телефоні, який плануєте підтримувати, а не на найновішому. На новому iPhone цієї проблеми не видно, на п’ятирічному вона очевидна
• Спитайте себе, чи тримає ваш застосунок щось, що шкода втратити. Читалка, яка забуває сторінку, — це прикро. Оформлення замовлення, бронювання чи довга форма — це втрачені гроші
• Якщо віджети є в дорожній карті, закладіть у бюджет Swift — незалежно від того, що оберете для основного застосунку
• Якщо ефективність і є продуктом, це головний аргумент за нативну розробку. Він важить більше, ніж чиста швидкість. Ідеться про фонове аудіо, камеру, карти, ШІ на пристрої та довгі сесії

Повне порівняння — з усіма числами, які ми змогли перевірити, і умовами кожного вимірювання — у матеріалі Swift проти Flutter і React Native: RAM і CPU, із джерелами. Якщо цікавить дуель двох фреймворків: Swift проти Flutter або Swift проти React Native. Хочете зважити це на конкретному продукті, а не в теорії — напишіть нам: ми створюємо на всіх трьох.