🔢 iOS 26: SwiftUI наконец-то стал таким же быстрым как UIKit?

Нашел интересную статью, в которой автор провел сравнение производительности SwiftUI и UIKit в iOS 26. На WWDC25 компания Apple уверяла, что с производительностью в SwiftUI стало в разы лучше. Но так ли это на практике? Чтобы проверить, он создал максимально сложную ленту и сравнил, как с ней справляются оба UI-фреймворка.


Что тестировали:

Лента содержала следующие элементы:

🔵Изображения высокого разрешения.

🔵Сложную иерархию элементов, текстов и градиентов.

🔵Постоянно анимирующиеся гифки.

🔵Ячейки переменной высоты.

🔵Жесты, которые в реальном времени обновляют состояние.

Все это заставляло экран работать на 120 кадрах в секунду, давая на каждый кадр всего 8 миллисекунд.


Результаты тестов:

🔵Память. SwiftUI использовал около 250 МБ памяти, в то время как UIKit - примерно 90 МБ. Разница почти в три раза.

🔵Hitches (пропущенные кадры). У SwiftUI было около 3,4 хитча в секунду, у UIKit - 0,7. В пять раз меньше.

🔵CPU и батарея. В состоянии покоя SwiftUI загружал процессор на 100%, постоянно. UIKit - опускался до 11%. Энергопотребление у SwiftUI было очень высоким, у UIKit - просто высоким. Термальный профиль SwiftUI быстро полз вверх, и в какой-то момент приложение просто было убито системой из-за перегрева.


💡 Вывод:

Даже в iOS 26 SwiftUI значительно уступает UIKit в производительности при работе со сложными, тяжелыми интерфейсами. В простых лентах разница может быть незаметна, но как только появляются анимации, гифки, сложная верстка и жесты - SwiftUI начинает проседать.

Интересно, что SwiftUI List внутри использует не обычный UICollectionView, а некую UpdateCoalescingCollectionView, что, видимо, и дает такую разницу. Плюс сама архитектура SwiftUI с пересчетом тела вьюх, диффингом и пересчетом layout добавляет накладные расходы, которых UIKit лишен.

Автор делает невеселый вывод: для сложных сценариев, где важна производительность, UIKit все еще вне конкуренции.


➡️ Подписаться на канал
Мобильный трудоголик