У меня есть приложение, написанное исключительно на SwiftUI, которое продается в App Store уже 2.5 года. По мере того как мои пользователи хранят в приложении все больше данных, а приложение становится все сложнее и требовательнее, я чувствую, что SwiftUI по-прежнему сильно не хватает в различных областях.
Я не говорю о старых версиях SwiftUI. Я имею ввиду современные версии SwiftUI от iOS 16+, хотя на данный момент SwiftUI уже 5 лет.
Вот некоторые недостатки, которые я заметил за эти годы.
1. Списки в SwiftUI по-прежнему ужасно плохи с точки зрения производительности.
Если я хочу отобразить в списке тысячи элементов, часто происходят провалы кадров, и он лагает с безумно высокой нагрузкой на процессор. Поискал решения по этому поводу в интернете, оказалось, что исправить это невозможно, так как список не использует ячейки повторно, как UITableView, и люди предлагают очень странные халтурные решения, которые я ни в коем случае не собираюсь отправлять в продакшен приложение для тысяч моих пользователей. Это может сломаться, когда они обновят свои iOS.
Я пробовал использовать id(UUID()), но это ломает анимацию, и улучшение производительности было минимальным.
Ввод списка с 10 тыс. элементов из NavigationStack занимает 2-3 секунды, что неприемлемо с точки зрения производительности. Прежде чем вы спросите, почему я пытаюсь отобразить тысячи элементов в списке, я, по сути, пытаюсь показать множество песен в плейлисте, как это делает Spotify.
Я перешел на использование UITableView, и, черт возьми, производительность стала значительно лучше благодаря многократно используемой природе ячеек. Я могу легко показать 100 тысяч элементов без падения частоты кадров.
2. NSFetchedResultsController
Я удивлен, что в SwiftUI до сих пор нет эквивалента этому контроллеру, если только они не анонсировали что-то в WWDC24.
Я пытался использовать UITableView в UIViewRepresentable, используя обертку свойства fetch request, и бам, странная консольная ошибка продолжала выскакивать. Но все ответы на Stack Overflow и комментарии/ответы в сообществе Apple — это просто люди, публикующие случайные исправления, которые сработали для них, и никто не знает причину этого.
3. Природа SwiftUI как «черного ящика» и трудности с поиском ответов
Очень трудно найти ответы на любые ошибки или странные проблемы, которые вы обнаружите в своем приложении на SwiftUI. Многие ответы на Stack Overflow остаются без ответа. Даже если я задам простой вопрос о том, как использовать представления SwiftUI в некоторых частях приложения UIKit, никто ничего не знает, и ответов на ваш вопрос нет. Искать источник ошибок или странного поведения становится очень неприятно, несмотря на то, что SwiftUI на данный момент уже 5 лет.
Похоже, люди до сих пор не знают, что происходит в SwiftUI.
4. Баги в представлениях и неожиданное поведение
В процессе разработки своего приложения в SwiftUI я столкнулся с множеством ошибок. Например, в NavigationSplitView есть проблема с некорректной анимацией строки поиска при переходе к детальному представлению. Она воспроизводиться даже на простом примере. По-прежнему есть проблема случайного сбоя при нажатии на определенную ячейку в списке, которая все еще не исправлена в iOS 17.5.
Либо никто ничего не знает о причине странного сбоя, консольной ошибке. Либо есть тонны и тонны ответов на Stack Overflow, которые являются буквальными халтурными хаками, которые точно сломаются в будущих версиях iOS.
5. Документация Apple по-прежнему ужасающе плоха
В SwiftUI до сих пор не хватает нормальной документации, а примеры кода для новых API вообще отсутствуют. Никто ничего не знает, а документация бесполезна, что является двойным ударом. В итоге я трачу еще больше времени на пробы и ошибки, когда мог бы написать правильную версию на UIKit.
6. Попытка использовать UITableView вместо списка
Была тема в Apple Docs по этому поводу, и человек из службы поддержки прямо сказал, что команда Apple не будет исправлять проблему в попытке использовать UITableView в SwiftUI и рекомендует использовать List, который в моем случае, как я уже говорил, ужасно плох по производительности для больших наборов данных.
Заключение
В заключение хочу сказать, что я очень удивлен обилием комментариев о том, что SwiftUI готов к продакшену, в то время как большая часть SwiftUI недокументирована и нет возможности узнать, как правильно его использовать. Многие разработчики, как и я, ничего не понимают из-за отсутствия ответов на вопросы, связанные со SwiftUI.
Меня просто очень удивляет количество комментариев здесь, на Reddit, утверждающих, что SwiftUI готов к работе, когда даже для такого личного приложения, как мое, которое ни в коем случае не является крупным приложением, может возникнуть столько проблем. Возможно, Reddit просто является огромной эхо-камерой.
Честно говоря, я начинаю сомневаться в правдивости комментариев на Reddit о том, что SwiftUI так хорош для сложных приложений, поскольку я на собственном опыте столкнулся с его узкими местами.
На данный момент я чувствую, что по мере того, как мое приложение растет, SwiftUI делает простые вещи более простыми, а сложные — еще более сложными. Конечно, на SwiftUI очень приятно писать базовые приложения в стиле самой iOS, но по мере усложнения приложения это становится крайне неприятным. Написание ячеек для табличного представления — это очень здорово, но более сложные части, такие как сами табличные представления, представления коллекций и разделенные представления, просто откровенно непроизводительны или чертовски глючны.
Конечно, Apple может улучшить это в будущем. Но какой в этом смысл, когда мне приходится поддерживать старые версии iOS, и даже на WWDC24 все еще нет никаких решений для всех моих жалоб.
Готов ли SwiftUI к проду
Вот некоторые ответы из этого треда:
- UIKit король.
- Я жалею, что использовал SwiftUI для своего текущего проекта. Никогда в жизни мне не приходилось использовать столько хаков, даже когда я работал над PHP v5 более 10 лет назад. Но… по принципу невозвратных издержек, мне не хочется переделывать проект (пока). На данный момент я пришел к выводу, что SwiftUI — идеальный инструмент для игрушечных приложений, если вы придерживаетесь дизайна Apple и не пытаетесь отобразить много или сложные вещи. Если вы хотите чего-то серьезного, используйте UIKit.
- Люди, настаивающие на том, что SwiftUI готов к проду, никогда не работали над средними и крупными проектами — скорее всего, они начинающие одиночки с приложениями на 3-4 экрана. Хотя я не против использования SwiftUI, я бы не стал создавать приложение на SwiftUI. Просто используйте его здесь и там, но не более того. Используйте правильный инструмент для правильной работы.
- В целом вы правы, хотя №1 может быть полностью решен, однако решения не всегда очевидны и документированы. Но да, у меня есть приложение, в котором есть список, настолько сложный, насколько это возможно, и он работает без проблем. №2 — это то, что вы должны использовать в модели представления, и там это работает хорошо. И с №5 я тоже не могу согласиться. Но с 3 и 4 я согласен на 100%.
- Да. SwiftUI отлично подходит для небольших демонстрационных приложений. Посмотрите, что я могу сделать в нескольких строчках кода! Но для крупномасштабных приложений он и близко не готов. Они создали его как нативный ответ на React Native, у которого есть свои проблемы. Если бы веб-разработчики могли писать на чем-то знакомом и родном, это могло бы их привлечь. Но никому из них нет до этого дела, поэтому мы застряли с посредственным фреймворком, который либо является будущим нативной iOS-разработки, либо постоянным техническим долгом. Я выпустил несколько приложений на SwiftUI, и меня вполне устраивает придерживаться UIKit. Гораздо больше гибкости, когда вам нужно сделать что-то нестандартное, а в SwiftUI вы все равно переходите на бриджи, так что зачем беспокоиться. Многие поклонники SwiftUI никогда не сталкивались с дизайнером, который дал бы им дизайн, который просто невозможно реализовать в SwiftUI. Слишком много глупых проблем, когда нужно кастомизировать. Либо Apple должна инвестировать в создание отличного SwiftUI, либо каждое приложение будет выглядеть и вести себя похоже. UIKit гибок и настраиваем так, как Swift UI не может.
- SwiftUI — это причина, по которой я бросил iOS-разработку.
- Главная боль заключается в том, что Apple выпускает пару новых видов и кучу модификаторов на каждой WWDC. Но этого недостаточно. У меня до сих пор есть проблемы в моем приложении, и они не могут быть исправлены, даже если я установлю цель развертывания на iOS 18, так что, как минимум, мне нужно ждать больше года, в надежде, что что-то будет решено, учитывая, что я готов установить iOS 19 в качестве цели развертывания! Я считаю, что SwiftUI — это определенно шаг в правильном направлении, и декларативное программирование превосходит императивное в плане пользовательского интерфейса, но Apple, корпорация с триллионами долларов, должна работать гораздо лучше.
- У меня нет проблем с SwiftUI. Единственное, что меня беспокоит — навигация. Если бы я начинал новый проект сегодня, я бы использовал сториборд для основы, а затем использовал бы хостинг-контроллеры.
- Мы интегрируем SwiftUI в наше приложение. Это корпоративное приложение, очень зрелое, с большим количеством экранов. У нас есть версии приложения для iOS, iPad, телевизора, часов и Vision, и все они используют различные уровни SwitUI (некоторые на 100% состоят из SwiftUI). Хотя мы по-прежнему используем UIKit для многих наших экранов (именно с этого все начиналось), большинство наших новых экранов — это SwiftUI. Это сэкономило нам много времени на разработку благодаря предварительным просмотрам SwiftUI. Кроме того, код стал намного чище и менее сложным. Я уверен, что есть некоторые экраны, которые должны остаться на UIKit, но это природа технологического стека в настоящее время и не является большим препятствием. Плюсы значительно перевешивают минусы. Вам не нужно простое приложение, чтобы использовать SwiftUI.
- На сегодняшний день у Airbnb более 500 экранов в SwiftUI, и они продолжают мигрировать. На Medium они объясняют весь процесс. Вы делаете что-то не так.
- Airbnb печально известна тем, что перестраивает свое приложение каждый второй год или около того. Как и Kickstarter. Технологией занимаются инженеры, которым нужны повышения, а повышения можно добиться не исправлением ошибок, а «созданием». Uber пошел по тому же пути несколько лет назад, перейдя с Obj-C на Swift (кажется, v2 или 3), и понял, что это была их самая большая технологическая ошибка, поскольку приложение увеличилось с 70 до 140 Мб (даже не говоря о том, что приложение стало медленным). Это была большая ошибка, так как в то время лимит загрузки App Store в 3G составлял 100 Мб. А когда вы обычно заказываете Uber? Из дома или когда на улице? И как же они это исправили? Попросив Apple увеличить лимит. И они действительно увеличили лимит для них (до 150 Мб на тот момент). А потом инженеры Uber, которые проталкивали переход на Swift без должной проверки, получили повышение, потому что они «создавали», а не «чинили». Так вот, возвращаясь к Airbnb, да, они будут говорить, как замечательна новая технология, как они гордятся тем, что перешли на новую технологию, как они никогда не вернутся к старой. Потому что деньги. Из-за повышения. И никогда не скажут — потому что это правильно с технической точки зрения.