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 все еще вне конкуренции.