Комментарии 40
С выходом Swift UI единственная проблема была в установке минимальной версии iOS 13, которая на тот момент являлась актуальной. Это сдерживало разработчиков какое-то время оставаться на UIKit.
Считаю, что сейчас прекрасное время, чтобы использовать Swift UI, ведь это охватывает большинство устройств на рынке. Как по мне, если у человека уже был опыт с Flutter или Jetpack Compose, то освоиться будет куда проще!
Про быстродействие чушь какая-то, и вообще в статье много сомнительных заявлений
Привет!?
Давайте разберем конкретные моменты, мне это очень поможет?
А пожалуйста.
Вы "быстродействие" обосновываете "более быстрым и эффективным развитие фреймворка", "лёгкостью, читабельностью и удобством в работе", "опытом программиста" и т.д. Это все, естественно, не связано.
Если оставить только связанное, то остаются только структуры против классов.
Отбросим тезис про то, что структуры быстрее, чем классы, т.к.это тоже очень холиварный вопрос (там все не так однозначно, как писали в рекламных статьях, продвигающих Swift).
Сконцентрируемся на том факте, что SwiftUI – это всего лишь обертка поверх UIKit. Т.е. все ваши структуры под капотом все равно создают соответствующие классы UIKit и работают с ними. Т.е. никакого выигрыша в производительности Вы не получите просто по одной причине: вместо того, чтобы работать только лишь с одними классами, вы еще создаете, модифицируете, гоняете по памяти, удаляете эти самые структуры-обертки-описания этих самых классов. Большее количество работы ну никак не может быть быстрее, чем меньшее количество работы. Согласны?
Теперь про "сборку мусора". Ее на iOS нет. Вместо нее используется механизм подсчета ссылок. Вопрос, который проясняют с каждым джуном на собеседовании. Этот механизм считается очень быстрым и имеющим нулевые затраты на управление памятью (на самом деле не нулевые, но близкие к нулю). При этом точно такой же механизм используется и для определения момента удаления структуры из стека. Поэтому этот аргумент в пользу быстродействия SwiftUI и структур тоже сомнителен.
Но да, спасибо за проделанную работу. Осталось ее подкорректировать и получится очень классная статья-сравнение. Можно будет ссылаться на нее и на Вас в моих дискуссиях про 2 технологии :)
Полностью согласен со всем сказанным. Собственоо эта же утверждение "лежит на поверхности" данной статьи в несколько "подсознательной" форме. Достаточно детально проанализировать смысл двух цитат из этой статьи:
"UIKit предоставляет великолепный инструментарий, однако требует высокого уровня квалификации для работы с ним."
"SwiftUI... Благодаря такому подходу, разработчики могут писать менее сложный код."
Не люблю холиварных вопросов, но суть ясна - с одной стороны сложный профессиональный интрумент с высоким порогом использования (требованиями к профессионализму), а с другой облегчённое упрощение с низким порогом входа для использования ...
Сконцентрируемся на том факте, что SwiftUI – это всего лишь обертка поверх UIKit
откуда такая информация?
в интернетах пишут. раз. два - swiftui code is converted to uikit views behind the scenes. больше искать не стал. поищите, пожалуйста, сами.
возможность транслировать код из SwiftUI в UIKit и обратно тоже как бы намекает.
Ну и я собрал маленький пример. Скрины ниже.
Hidden text
Да, никто не запрещает Эплу полностью переписать внутреннюю реализацию без использования UIKit, но пока это не так. Планов по переписыванию я не встречал.
Да, на других платформах под SwiftUI будут другие фреймворки. Но смысл тот же - это всего лишь обертка.
Так что? Исправите статью под многочисленные комментарии к ней?
ну похоже на смешанную конструкцию, простое и новые вещи, типа Text, VStack, HStack и т. д. реализованы каким-то новым способом, а сложные вещи типа навигации, таблиц работают через UIKit, так как там все давно отточено и оптимизировано. Ну и наверное в RunLoop и весь флоу на UIKit схеме работает. Однако есть подозрение что постепенно Apple это все будет передеывать на новые рельсы.
В доке SwiftUI-introspect пишут, что парочка компонентов, все таки, не обертка
Какие техники и подходы можно применить для эффективного дебаггинга в SwiftUI, несмотря на ограничения инструментов?
Привет!?
Если мы не берем в расчет старые добрые способы в виде принтов и брейкпоинтов, можно попробовать использовать стороннюю библиотеку ViewInspector ну и конечно же SwiftUI Previews дает много возможностей, просто не всегда получается запускать превью корректно, особенно в большом проекте
в SwiftUI очень весело фиксить "новшевста" эпла, которые они привносят с минорной версией iOS. Допустим в 16.0 нормально работала клавиатура на вьюхе, в 16.1 уже поломана... и таких микро моментов полно и фиксить приходится обходными путями... Если в UIKit куда проще эпол моменты починить, то в SwiftUI не так.
Привет!?
Я согласен, что иногда обновления iOS могут приводить к проблемам с SwiftUI, поскольку это новая технология и она все еще развивается. Однако, в большинстве случаев, проблемы можно решить, используя обходные пути и дополнительные библиотеки. Также, я думаю, что с каждым обновлением iOS, SwiftUI становится все более стабильным и удобным в использовании. В целом, я считаю, что SwiftUI предлагает множество преимуществ и значительно упрощает процесс разработки приложений?
Примеры приведены сомнительные. Я уже не помню когда использовал UITableView для верстки хоть каких то компонентов, даже для списков лучше подходит UICollectionView с кастомным layout который будет в точности соответствовать требуемым макетам. Если я не ошибаюсь, коллекции в SwiftUI завезли совсем недавно, раньше были сухонькие списки, что ограничивает нас не только 13м iOS-ом, а ощутимо позже. Да, процент юзеров на старых iOS ничтожно мал, что можно и поднять минимальную версию в приложении, но вы же Ozon, логично предположить, что вам нужен максимальный охват.
Касательно "Modern Concurrency", то вам ничего не мешает его использовать с UIKit, но пихать такую логику в View компоненты выглядит сомнительным.
С мультиплатформенностью тоже не соглашусь. Изначально TvOS и WatchOS работали на UIKit, даже в MacOS какие никакие переводы делали. Точно могу сказать, что TvOS отлично работает с приложениями на UIKit, да надо накрутить немного другие события, но код будет один и тот же.
Коллекции aka LazyVGrid, уже довольно давно есть. iOS 14.0 - SwiftUI 2.0
Привет! ?
Я понимаю, что использование UICollectionView с кастомным layout может быть хорошим решением для создания макетов в iOS приложениях. С появлением SwiftUI, это стало еще проще и удобнее, он позволяет создавать списки всего за несколько строк кода, а также предоставляет множество встроенных компонентов
Тут скорее про то, что SwiftUI позволяет использовать Modern Concurrency в более удобной и эффективной форме.
Я понимаю вашу точку зрения относительно мультиплатформенности, и в некоторых случаях TvOS и WatchOS могут работать с приложениями на UIKit. Однако, мультиплатформенность может требовать создания различных интерфейсов для разных платформ, и в таком случае использование SwiftUI может быть полезным ?
С чатом GPT ответы генерите ?
В теории разработки информационных систем считается, что View-компонент должен быть платформенно зависимым. Попытки делать его платформенно независимым делают его тяжелым, сложным и не гибким в настройке и расширении.
Проще написать отдельный UI для TVOS, watchOS и iOS в горизонтальной и вертикальной ориентации, чем пытаться описать все это единым языком с лапшой условий.
По Modern Concurrency. Вам ничего не мешает добавить подобный синтаксис к ObjC и использовать его с ObjC.
А зачем в UIKit создавать элементы прямо в коде, это какой-то особый мазохизма? Есть же визуальный дизайнер форм, кстати в дизайнере можно и таблицы и списки делать, вообще без кода. Так же массив биндится с формой, если таблица то колонка биндится к словарю, а в массиве хранится список словарей. Все изменения в форме автоматически отражаются на экране, а если меняем данные на экране, все изменения отражаются в связанном массиве автоматом. И для этого не надо ни одной строчки кода. И код в результате будет, короче чем с SwiftUI. Вы дизайнером форм то в связке с UIKit пользоваться умеете?
С одной стороны визуальный дизайнер форм, а с другой большие команды разработки. Одно с другим практически не совместимо ?
PS: Мерж конфликты в xml, это своеобразный фетиш
Плюсую много раз про конфликты?
Эта проблема давным давно решена. Разделяй и властвуй. Не нужно весь UI приложения пытаться запихнуть в 1 xml-файл. Этих файлов может быть много. Тогда вероятность, что 2 разработчика полезут в один xml-файл резко сократится. А практики установления владения над кодом эту вероятность вообще к нулю сводят. Никаких проблем. Проверено на практике.
Возможно так, вероятность сократится, будет стремиться к нулю. Но гарантировать что вероятность этого нулевая, достаточно сложно. А когда это стреляет, то разработчик вынужден править код, написанный не на его основном языке. Обычно еще время сборки увеличивается, проверял лет 5 назад с xib и storyboards.
Проблема xib и storyboard еще в том что
1. системе их надо парсить, держать в памяти - время и ресурсы
2. связь с кодом (вызов событий или переходов на экраны) не гарантирует отсутствия эксепшенов и ошибок, чето переименовали - перестало просто работать, отсутствуют проверки на этапе компиляции короче
Так ведь:
xib – это файл для разработки и хранения в человекочитаемом виде. В bundle приложения он не складывается. В bundle приложения складывается скомпилированная версия в формате nib. Это по сути сериализованная версия объектов, на парсинг которой особо времени и не нужно. Ну, не больше, чем на сериализацию/десериализацию. Это гораздо быстрее, чем парсить человекочитаемый код. Ну, и это не намного дольше, чем создавать объекты из кода. Есть цифры, подтверждающие, что одно дольше другого? А насколько?
Xcode дает ворнинги при компиляции xib-файлов. По умолчанию это ворнинги и они не останавливают процесс билда. Но, кажется, что этот параметр можно менять и сделать ворнинги в xib-файлах ошибками, останавливающими процесс билда. Так что проверки на этапе компиляции все же есть.
Что касается вызова событий, то для этого есть Responder Chain и first responder. Этот механизм не вызывает исключений и не роняет приложение, если не находит в цепочке указанный селектор. Добавляем сюда интеграционные тесты на корректность дерева вьюх и контроллеров и проблема уходит. Ошибки в переходах тоже прекрасно закрываются интеграционными тестами.
С другой стороны, краши при вызове селектора, который не привязали в коде никак от IB не зависит. Это вообще не проблема IB. Это проблема отсутствия связи, которую и в коде можно неверно проставить или вообще не проставить. Полагаю, что и с переходами на экраны аналогично. И обе проблемы лечатся не переходом с IB на код, а интеграционными тестами.
Спасибо, что напомнили еще про 2 мифа, не имеющих отношения к реальности ^.^.
Привет!?
Для создания элементов в коде в UIKit есть несколько причин. Некоторые разработчики предпочитают создавать элементы в коде для более точной и гибкой настройки элементов. К тому же, возможностей, которые может предоставить визуальный дизайнер, может быть недостаточно для некоторых сложных проектов.
В некоторых случаях, код может быть более читаемым и проще для понимания, чем визуальный интерфейс.
Кроме того, SwiftUI предоставляет множество новых возможностей и улучшений в сравнении с UIKit. Использование SwiftUI может быть более выгодным для некоторых проектов?
Отличная работа проделана. Вы молодец. Но многие вещи все же подтягиваются под необходимый ответ. К комментариям выше добавлю следующие.
Однако, в отличие от Swift, Objective-C не поддерживает жирные структуры. Следовательно, нет способа написать пользовательский интерфейс с помощью SwiftUI и импортировать его в приложение, написанное на Objective-C. Это означает, что разработчики, которые хотят использовать SwiftUI, должны перейти на Swift и создать новое приложение с нуля, если хотят использовать весь потенциал фреймворка.
В корне неверно. SwiftUI полностью совместим с ObjC. У Элла есть документация, какие оберточки Вам нужно сделать, чтобы иметь возможность использовать SwiftUI в ObjC.
Про скорость верстки очень неоднозначный момент. Да, в простых синтетических примерах, где надо только фрейм поменять, тут SwiftUI нет конкурентов. Но как только мы переходим в область комплексного UI и UX, так сразу начинаются проблемки и преимущество в скорости верстки резко превращается в мощный такой минус, перекрывающий полученный до этого выигрыш.
Привет! ?
Спасибо большое за ваш отзыв! Для меня это очень важно!
Всё же без применения дополнительных оберток выглядит куда более уверенно, но тут опять таки всё упирается в задачу, наверняка, если у нас возникнет необходимость использовать легаси код вместе с SwiftUI, мы пойдем их писать.
Было пару моментов, когда сложные интерфейсы хотелось сделать именно с использованием UIKit, но это скорее исключение из правил, пока нам удается использовать решения на SwiftUI в нашем проекте, даже со сложным интерфейсом?
Извините, но статья получилась пустой. Все эти банальности давно известны, на дворе 2023 год.
Я работаю на проектах сразу на swiftUI и крайне рад этому. Важнее всего при разработке это скорость производства кода, с тормозами работы приложения вообще не сталкивался, при условии что код компилируется без каких либо предупреждений.
В том что структуры быстрее классов в частности на swift вообще странно, что поддается сомнению, да есть исключению и чатные случаи, но перевес в общем-то на стороне структур. Так же структуры удобнее и безопаснее для программиста в многопоточной среде, т.к. у каждого потока свой стек, но отдельная куча. Да платим за это оперативной памятью, но если не хранить там ничего лишнего, то все в рамках погрешности.
Привет! ?
У нас на проекте нет проблем даже со сложным функционалом, все новые экраны, даже высоконагруженые списки мы делаем на SUI. Также мы следим за Performance метриками и применяем оптимизации.
?Тут? можно посмотреть доклад моего коллеги Александра Свиридова о том, как мы в Озоне собираем и используем метрики для улучшения опыта пользователя.
От того, что мы заменили операторы языка на эквивалентные им функции с fluent api код менее императивным не стал. Декларативным был бы какой-нибудь такой код:
SealedDocument
is Document
is Sheet
sealed true
SignedDocument
is SealedDocument
signed true
UnSignedDocument
is SealedDocument
signed falseТут мы описываем что такое подписанный и не подписанный документы с печатями, которые надо получить, но не как это сделать.
С выходом Swift UI единственная проблема была в установке минимальной версии iOS 13, которая на тот момент являлась актуальной. Это сдерживало разработчиков какое-то время оставаться на UIKit.
Считаю, что сейчас прекрасное время, чтобы использовать Swift UI, ведь это охватывает большинство устройств на рынке. Как по мне, если у человека уже был опыт с Flutter или Jetpack Compose, то освоиться будет куда проще!
Очень напоминает историю с Flutter. Было бы неплохо, если б вы кроме плюсов этого замечательного "декларативного подхода" описали бы ещё и минусы.
Например как криво в некоторых случаях приходится обрабатывать данные, например если у нас есть сложная структура общего хранилища в приложении и нам надо, например, сначала обработать данные приходящие с сервера, что-то сделать, а только потом положить эти данные в общее хранилище. Задача не бох весь какая сложная, однако с определённого уровня сложности приложения чтобы это провернуть нужно городить достаточно корявый код.
Это, в принципе, можно решить грамотной архитектурой, но чем больше приложение, тем сложнее будут костыли и тем запутанней становится код отвечающий за работу с моделью, хотя представление останется вполне читаемым, это конечно плюс.
Ну и да, пример с .map тоже резанул, никакой это не декларативный подход. Лучше иллюстрирует что является декларативным подходом аналогия с математическими функциями.
Хорошая статья, полезный материал!
Спасибо за статью, все интересно и понятно описано
Спасибо за статью, я бы еще добавил про кроссплатформенность в SwiftUI. Можно создавать приложения для iOS, macOS, watchOS и tvOS, и это делает его более универсальным по сравнению с UIKit.
Императивный UIKit vs Декларативный SwiftUI