SwiftUI больше не будущее, он готов прямо сейчас

Очевидно, что в последние годы SwiftUI привлекает все больше внимания разработчиков iOS. Несмотря на то, что он выглядит многообещающе, его первоначальные недостатки и, что самое главное, ограниченность в работе (начиная с iOS 13), пока заставили сообщество не применять это в продакшене. После нескольких опросов я знаю (и полностью понимаю), что в следующие 2 года немногие команды выберут этот относительно новый фреймворк для создания готовых приложений. Но я считаю, что через 2 года его использование в продакшене резко возрастет. Вот несколько моментов, в которых я объясняю это.

SwiftUI меняет правила игры

Это наступит тогда, когда другие платформы (особенно гибридные), использующие декларативные стили, пройдут большой путь, и платформа Apple не сможет слишком долго оставаться вне игры. В целом, разработчики iOS, такие как мы, также должны идти в ногу с этой тенденцией.

Чтобы изменить образ мышления с императивного на декларативный, потребуется много времени и усилий. Поэтому в течение следующих 2 лет, пользуясь временем, когда SwiftUI еще не стал основной платформой разработки, мы должны с ним познакомиться.

Скорость программирования и производительность кода у SwiftUI намного больше и он намного удобнее, чем UIKit. Получая описание экрана от клиента, по моим оценкам, создание его с UIKit это занимает 8 часов, тогда как со SwiftUI около 2 часов.

Тем из вас, кто считает, что UIKit все еще есть место в будущем, обратите внимание на аналогичную историю с Obj-C и Swift. Спрос на рабочие места, связанные с Obj-C, остается и останется, поскольку есть проекты, SDK существуют уже давно и требуют сопровождения. Но если вы хотите делать новые вещи только со знанием Obj-C, то вы не можете идти в ногу со временем. Не говоря уже о недостатках Obj-C по сравнению со Swift, которые заставляют вас тратить больше усилий на программирование. Похожая история и у SwiftUI и Interface Builder.

Текущие ошибки не имеют большого значения

Некоторые разработчики говорят: SwiftUI содержит ошибки, он незрелый и недокументированный. Я полностью согласен. Но давайте подумаем об этом немного больше. Неужели он настолько плох? Мой ответ — вовсе нет.

Незрелость: это нормально. Все, что только что запущено, будет содержать ошибки. Но если вы будете ждать, пока фреймворк станет идеальным, чтобы начать учить его, то будет очень поздно.

Нет документации: мы разработчики iOS и, наверное, слишком привыкли к тому, как плохо Apple пишет документацию. Но сейчас у сообщества это получилось очень хорошо (возьмите, например, Пола Хадсона). Так что меня это совсем не беспокоит.

Последнее, но самое важное: теперь будет суть всей статьи. Я знаю, что в SwiftUI много ошибок, но, честно говоря, они не носят систематического характера. Эти ошибки фрагментарны, они не являются блокирующими или фатальными.

Я думаю, что наиболее важной проблемой является навигация, когда мы работает с таб барами или меню. Но даже при этом мы все же находим обходные решения (правда, на это требуется больше времени и усилий).

Эти недостатки не могут скрыть того факта, что SwiftUI — это будущее программирования для iOS.

SwiftUI постоянно улучшается

Я был последователем SwiftUI с тех пор, как он был еще на стадии бета-тестирования, и, оглядываясь назад, я могу сказать, что он действительно набирает обороты. Не только появляются новые функции, но и улучшаются длинные, трудные для понимания API. Конечно, SwiftUI по-прежнему не может охватить все компоненты, которые нам нужны, поэтому с ними мы должны использовать обертку, по-прежнему беря основное содержимое из UIKit. Но я считаю, что с каждым выпуском Apple будет постепенно преобразовывать все нативные компоненты в собственные элементы SwiftUI, такие как Map, ProgressView и т.д.

Кроме того, сообщество разработчиков, использующих SwiftUI, растет, и я считаю, что когда придет время, SwiftUI будет достаточно сильным, чтобы занять свое место в больших проектах.

Подходящая архитектура

Это было одной из больших проблем для меня на ранних этапах, когда стиль программирования отличался от того, что я делал раньше.

Хорошая новость в том, что есть команда, у которой есть готовая архитектура для SwiftUI. Это выдающаяся архитектура — и я почти уверен, что она вам понравится. Она решила проблемы, с которыми сталкивается ванильный SwiftUI. Это Composable архитектура команды PointFree. В следующих статьях я собираюсь глубоко погрузиться в эту архитектуру, ее положения, а также реальные практики.

Кроме того, платформа Combine расширяет парадигму привязки состояний, заимствуя концепции из RxSwift. Это революция для платформ Apple, и мы, разработчики iOS, не можем быть более счастливы.

Заключение

Я полностью понимаю причины, по которым на данный момент очень немногие осмеливаются делать ставку на SwiftUI, но не случайно Apple постоянно занимается поисковой оптимизацией для этого фреймворка.

Когда процент iOS 13 достигнет более 95% пользователей (в настоящее время более 85%), тогда SwiftUI больше не будет просто «доступной альтернативой», а станет главным вариантом при запуске нового проекта. Поверьте, этот день настанет довольно скоро.

Я очень рано обратился к SwiftUI и создал с ним пару сложных приложений, поэтому, если у вас есть какие-либо вопросы или опасения по поводу этого фреймворка, не стесняйтесь высказывать свои мысли.

Источник