Что лучше: UIKit или SwiftUI?
Hello, World! Меня зовут Денис. Я IOS разработчик, пишу приложения для App Store. Хочу поделиться своим небольшим опытом на UIKit и SwiftUI.
Первый запуск
На WWDC19 Apple предоставила декларативный фреймворк SwiftUI. Новый фреймворк позволяет уменьшать время на написание UI-составляющей своих приложений.
- UIKit
- SwiftUI
- Отличия между фреймворками
- Возможно использовать UIKit в SwiftUI?
- Производительность
Что такое фреймворк UIKit?
UIKit — это фреймворк, позволяющий создавать пользовательские интерфейсы (UI), которые могут обрабатывать события касания и входные данные, управляя взаимодействиями между пользователем, системой и вашим приложением. UIKit разработан и выпущен на основе языка Objective-C.
UIKit можно создавать несколькими способами
- Использовать конструктор интерфейса. Interface Builder интегрирован в Xcode и позволяет редактировать .storyboard.xib
- Подход, ориентированный на код, при котором представления и ограничения компоновки определяются в Swift
Плюсы/минусы
+ Привычен и стабилен
+ Свобода действий над UI элементами
— Сложные UI элементы
Что такое фреймворк SwiftUI?
SwiftUI — фреймворк, который позволяет вам проектировать и разрабатывать пользовательские интерфейсы декларативно, с меньшим количеством кода. Был впервые выпущен в 2019 году с версией 13 iOS SDK.
- Xcode отображает визуальный редактор с любым файлом, содержащим представление SwiftUI, отображая живое представление создаваемого вами представления.
Плюсы/минусы
+ Прост в освоении
+ Можно смешивать с UIKit через UIHostingController
+ SwiftUI больше не нуждается в Interface Builder, был заменен на Canvas
+ HStack(элементы расположены горизонтально), VStack(элементы расположены вертикально), ZStack(элементы расположены друг над другом) — StackView
+ Абсолютная свобода и гибкость
— Еще молодой фреймворк
— Он поддерживает только iOS 13 и Xcode 11
Отличия между фреймворками
1) Чтобы код работал, вам просто нужно описать переменную body ( var body: some View<> ) , к которой вы должны вернуть представление. Тело — ваш контейнер, в который вы добавляете все остальные вложенные представления. В теле вы должны возвращать только один элемент: текст, изображение, кнопку. — все, что поддерживает View . В другом случае компилятор выдаст ошибку
2) Основные вещи, такие как UIScrollView и UITableView также доступны, но теперь они называются ScrollView и ListView
3) Создание пользовательского интерфейса программно (без раскадровки) в UIKit значительно сложнее по сравнению с SwiftUI. UIKit известен как императивный фреймворк, который просто означает, что вы указываете, как что-то сделать
4) SwiftUI является декларативной структурой. Вы объявляете код, а на canvas происходит ваши задумки (как я называю «прямой эфир»)
Возможно использовать UIKit в SwiftUI?
UIViewRepresentable — это протокол, предоставляемый фреймворком SwiftUI. Используя этот протокол, можно обернуть экземпляр представления UIKit, чтобы его можно было отображать с помощью SwiftUI. Пример:
Производительность
С точки зрения времени разработки SwiftUI обычно работает лучше, чем UIKit. Связано с тем, что иерархия представлений находится в структурах типа значений, хранящихся в стеке, что означает отсутствие дорогостоящего выделения памяти. Означает более высокую производительность в некоторых ситуациях
Итог
Подводя итог, SwiftUI использует совершенно иной подход к написанию кода, чем UIKit. Выбор за вами. Факт: SwiftUI понятен, легко читается и удобен в использовании. В будущем Apple начнет отказываться от UIKit.
Новое поколение iOS-разработчиков все чаще начинают свой путь именно со SwiftUI, а бывшие дизайнеры, благодаря данной технологии Apple, становятся еще и разработчиками.
SwiftUI лучше оптимизирован для новых устройств. Предоставляет более мощный код (элементы), что позволяет разработчикам создавать более совершенные приложения.
P.S. На рынке РФ пока мало компаний, которые перешли с UIKit на SUI.
Объекты окружения и стили SwiftUI
Окружение и стили SwiftUI являются двумя столпами официального фреймворка (декларативной структуры) от Apple. Не смотря на это, при первом запуске SwiftUI их совместное использование приводило к гарантированному падению приложения.
В частности, сбой происходил, когда мы использовали @EnvironmentObject внутри нашего определения стилей: когда безопасно использовать их вместе? Давайте выясним.
Заметка
Для нетерпеливых результаты в конце статьи .
Пример
Познакомьтесь с FSStyle , стилем кнопки, ожидающим объект среды ( FSEnvironmentObject ):
class FSEnvironmentObject: ObservableObject < @Published var title = "tap me" >struct FSStyle: ButtonStyle < @EnvironmentObject var object: FSEnvironmentObject func makeBody(configuration: Configuration) ->some View < Button(object.title) < >> >Исходя из определения, мы ожидаем, что все будет работать, пока мы вводим объект окружения в какой-то момент до того, как применить стиль. Например:
struct ContentView: View < @StateObject var object = FSEnvironmentObject() var body: some View < Button("tap me") < >.buttonStyle(FSStyle()) .environmentObject(object) > >..и все же, если мы запускали этот код в любой версии iOS до 14.5, он гарантированно давал сбой в 100% случаев с Fatal error: No ObservableObject of type FSEnvironmentObject found. .
Сбой происходит, как только объект окружения используется внутри метода makeBody (configuration: ) , и определение объекта, и исполнение makeBody (configuration: ) не имеют значения.
Есть два основных способа обойти ошибку: или привести стиль в соответствие с DynamicProperty (большое спасибо Линь Цин Мо за подсказку!), или вернуть View в методе makeBody (configuration: ) и заставить этот View читать объект окружения.
Теперь, когда мы увидели, в чем проблема, давайте узнаем, в каких версиях iOS и стилях встречается эта ошибка.
Тестовая установка
Мы хотим выяснить, в каких версиях iOS безопасно использовать все возможные стили (не только стили кнопок). Мы можем создать небольшое тестовое приложение и запустить его во всех версиях iOS, поддерживающих SwiftUI, и получить результат.
Продолжая на примере с ButtonStyle , вот полное приложение:
import UIKit import SwiftUI @UIApplicationMain class AppDelegate: UIResponder, UIApplicationDelegate < >class SceneDelegate: UIResponder, UIWindowSceneDelegate < var window: UIWindow? var object: FSEnvironmentObject = FSEnvironmentObject() func scene( _ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions ) < if let windowScene = scene as? UIWindowScene < let window = UIWindow(windowScene: windowScene) let contentView = ContentView().environmentObject(object) window.rootViewController = UIHostingController(rootView: contentView) self.window = window window.makeKeyAndVisible() >> > struct ContentView: View < var body: some View < Button("tap me") < >.buttonStyle(FSStyle()) > > struct FSStyle: ButtonStyle < @EnvironmentObject var object: FSEnvironmentObject func makeBody(configuration: Configuration) ->some View < Button(object.title) < >> > class FSEnvironmentObject: ObservableObject
Приложение состоит из одного экрана, на котором находится наш тестовый компонент/стиль.
- мы используем жизненный цикл UIKit, потому что мы хотим запускать тесты также и на iOS 13
- мы не используем @StateObject для объекта окружения, потому что данная обёртка свойств только для iOS 14+
- единственная разница между тестированием ButtonStyle и другими стилями заключается в определении тела FSStyle и ContentView , все остальное остается прежним
Настройка CI/CD
Мы будем тестировать двенадцать версий iOS, от iOS 13.0 до iOS 14.5, и все восемь стилей, поддерживающих настройку.
Тестировать каждую комбинацию вручную было бы довольно сложно, вместо этого мы можем позволить провайдеру CI/CD сделать всю тяжелую работу за нас. Подойдет любая установка CI/CD, вот как различные версии Xcode/iOS были распределены для этого исследования:
- macOS 10.14
-
- iOS 13.0, Xcode 11.0
- iOS 13.1, Xcode 11.1
- iOS 13.2, Xcode 11.2
- macOS 10.15
-
- iOS 13.3, Xcode 11.3.1
- iOS 13.4, Xcode 11.4.1
- iOS 13.5, Xcode 11.5
- iOS 13.6, Xcode 11.6
- iOS 13.7, Xcode 11.7
- iOS 14.0, Xcode 12.0.1
- iOS 14.1, Xcode 12.1
- iOS 14.2, Xcode 12.2
- iOS 14.3, Xcode 12.3
- macOS 11.4:
-
- iOS 14.4, Xcode 12.4
- iOS 14.5, Xcode 12.5
Поскольку в тестовом приложении есть только один экран, на котором сразу отображается тестируемый компонент, все, что нужно для прохождения теста, — это запустить приложение и не вылететь тотчас же. Вот результат:
Style ���� / iOS ����
�� = вылет, ✅ = пройдено. * Стиль доступен с iOS 14.
- все стили, кроме ButtonStyle , поддерживают @EnvironmentObject с iOS 14.0
- начиная с iOS 14.5, все стили, включая ButtonStyle , поддерживают @EnvironmentObject
Выводы
Причина, по которой комбинация styles + @EnvironmentObject не поддерживалась с самого начала, вероятно, останется внутри команды SwiftUI, однако это могло быть намеренно:
Глядя на то, как применяются стандартные стили SwiftUI, помимо нескольких параметров, передаваемых через Configuration , бОльшая часть изменяемых компонентов приходит из EnvironmentValues , например @Environment (\.IsEnabled) , @Environment (\.font) и @Environment (\ . controlProminence) .
В отличие от @EnvironmentObject , EnvironmentValues поддерживается (без вылета!) с iOS 13.0, поэтому я рекомендую их при добавлении динамики в наши пользовательские стили.
Невзирая на то, было ли это ошибкой или намеренно, как поставщик SDK, нам важно устранить неоднозначность и прояснить такие сценарии для разработчиков.
Насколько мне известно, это нигде не было задокументировано и не рассматривалось ни в одном примечании к выпуску: если разработчики это допустили, это находится во фреймворке.
Еще одно место, где это могло быть проблемой — это модификаторы View, однако и EnvironmentValues , и @EnvironmentObject поддерживаются (без �� ) из iOS 13.0.
Swift UI: от сомнений к успешному внедрению 25.10.2023 16:00
Всем привет, меня зовут Фарид Хусаинов, я тим-лид команды мобильной разработки Банки.ру. Мы делаем iOS-приложения компании Банки.ру, а именно — наше основное приложение и приложение, посвященное страхованию.
Два с половиной года назад мы приняли решение перевести наше мобильное приложение на SwiftUI. На тот момент это была смелая и рискованная идея, так как SwiftUI был новой технологией. Маленькое комьюнити, много багов и нехватка опытных разработчиков, работающих на этой платформе, делали этот шаг непростым.
Эту статью хотелось бы адресовать разработчикам, интересующимся SwiftUI, а также тим-лидам и представителям бизнеса. Она в меньшей степени посвящена разработке, а в большей — опыту взаимодействия с новой технологией в продакшене. Мы подробно рассмотрим, почему мы выбрали SwiftUI и как справлялись с различными вызовами на этом пути.
Что такое SwiftUI
SwiftUI — это фреймворк для декларативной вёрстки пользовательского интерфейса приложений в экосистеме Apple на языке Swift.
Декларативный подход на SwiftUI выглядит вот так:
На принтскрине один файл с достаточно простым кодом. Все легко можно прочитать и понять. Здесь мы видим, что нас попросили сделать столбик из каких-то элементов, отступ между которыми 50. Сверху в этом столбике находится текст, потом идёт кнопочка, которая при нажатии меняет это приветствие, у неё текстовая подпись и под кнопкой пустое пространство. И все это сдвинуто от верха экрана на 100 пикселей. Все понятно.
Почему мы выбрали Swift UI и как дошли до жизни такой: история SwiftUI.
Первый SwfitUI Apple выпустили вместе с IOS 13 в 2019 году. И на тот момент технология была довольно сырой. Я бы сказал, что даже нетипично сырой для Apple: было много багов. Удивляло также то, что в SwiftUI отсутствовали некоторые элементы, которые были в легаси фреймворке UIKit. К примеру, многострочное текстовое поле.
Но стоит отметить, что Apple сразу выпустили хорошую документацию. И самое главное, что в коробке с этим фреймворком пришёл ещё один фреймворк — Combine. Это реализация реактивного фреймворка, полностью написанного Apple и полностью встроенного в SwfitUI. То есть вся динамика и все, что происходит в SwfitUI, работает на Combine. И этот Combine оказался очень стабильным и сразу хорошо задокументированным. Естественно, его можно использовать отдельно, что мы и делали: в частности, у нас на нем работает сетевой слой.
В iOS 14 в 2020 году Apple исправили некоторые баги и добавили новые возможности. Также появилось больше документации: учебники, интерактивные уроки и так далее. Но некоторые баги по-прежнему сохранялись. И как раз на этом этапе мы выпустили приложение Banki.ru и решили, что все новые фичи мы пишем только на SwiftUI.
У нас получилась такая ситуация, что часть, написанная на аутсорсе, оставалась на UIKit, а то, что мы писали сами, создавалось уже на SwiftUI. На тот момент шаг был довольно рискованным, но мы верили, что Apple будет развивать технологию, и непреодолимых препятствий в будущем это не создаст. Спойлер: так и случилось.
Как мы и предполагали, в версии iOS 15 и 16 багов стало заметно меньше, добавились дополнительные возможности, реализовались новые компоненты.
К тому моменту SwfitUI уже мог называться stable-версией.
Когда начинать использовать новые технологии
Наш опыт показал, что новые инструменты стоит внедрять как можно раньше. Конечно, использование новых инструментов и подходов в продакшене — это всегда риски и поиск компромиссов. Многие разработчики и команды не готовы идти на это. Но мы видели потенциал SwfitUI с самого начала, верили, что за ним будущее, и хотели оказаться «на гребне волны». И наш подход принес результаты.
Тут хочется добавить, что мы, как сообщество, все-таки должны давать шанс новым технологиям. Ведь каждая из них проходит разные жизненные циклы. Если на начальном этапе развития не найдется энтузиастов, которые начнут использовать инструмент в своих проектах, он просто не будет развиваться. И никогда не будет достаточно готов к продакшену.
Например, даже Swift в свое время вызывал сомнения. Многие разработчики не верили в его потенциал и избегали его использования. Некоторые приняли этот язык только с четвертой версии. Так было и с многими другими технологиями, которые теперь являются стандартами отрасли.
Взаимодействие с бизнесом
При внедрении новых инструментов в рабочие процессы необходимо уделить внимание взаимодействию с бизнесом. Бизнес-сторона должна осознавать, что, хотя новые технологии могут приносить значительные выгоды в будущем, в настоящем приходится идти на некоторые компромиссы. Это вполне нормальная часть процесса.
Рассмотрим пример: в ранних версиях технологии не всегда можно в точности воплотить все элементы интерфейса, как они изображены на дизайн-макете. В таких случаях ключевую роль играет отличная коммуникация между разработчиками, дизайнерами, продуктовыми менеджерами и другими участниками команды. Необходимо совместно искать оптимальные альтернативные решения и адаптировать технологию к конкретным требованиям и ограничениям проекта. Это позволяет успешно интегрировать новые инструменты и максимизировать их потенциал, несмотря на временные компромиссы.
Плюсы SwiftUI
Переводя проект на SwiftUI, мы ожидали получить следующие преимущества:
Понятный код
SwiftUI не требует написания множеств строк кода. При этом весь код находится в одном месте. Все отступы называются отступами, а пустые пространства — пустыми пространствами. Это позволяет нам без проблем решать мерж-конфликты и проводить код-ревью.
Превью
Вместе со SwiftUI появились превьюшки. Это такая картинка, которую наш редактор кода может показать отдельно. То есть мы можем нажать на конкретную кнопочку и увидеть нашу вьюшку с какими-то нашими тестовыми данными, которые мы
захотели в данном случае увидеть. Это позволяет отслеживать все наши изменения прямо в реальном времени. Ничего не надо компилировать, что делает жизнь разработчика гораздо проще.
Отсутствие сторонних фреймворков
Также вместе с SwiftUI из коробки идет Combine. Поэтому нам не приходится добавлять сторонние фреймворки. Таким образом, мы повышаем безопасность нашей кодовой базы.
Хочется подчеркнуть, что особенность этого подхода — его декларативность. Работая таким способом, стоит понимать, что мы описываем не действия, а взаимосвязь между определенными сущностями: между нашими данными и тем местом, в котором они отображаются. Это может потребовать изменения нашего способа мышления и привести к более абстрактному пониманию процесса.
Проблемы SwfitUI
Конечно, работа с любой новой технологией в продакшене подразумевает некоторые проблемы. Расскажем, с чем мы столкнулись на нашем тернистом пути.
Баги
Баги в Apple-фреймворках действительно могут быть неприятными, так как компания не раскрывает свой исходный код, и исправить проблему могут только сами разработчики Apple. Это требует активного уведомления и убеждения Apple в необходимости исправления. Обычно исправления багов доступны только в следующей версии iOS, что может занять достаточно много времени, порой год или даже больше.
Необходимость «костылить»
Из-за этой ситуации нет другого выхода, кроме как находить временные решения. Вам приходится налаживать обходные пути, создавать собственные реализации элементов, которых нет в Apple-фреймворках, и настраивать их так, чтобы они выглядели и функционировали как нативные элементы, но на платформе SwiftUI.
Показательный пример необходимости костылить — это «ромашка» на экране ниже. Этот элемент пользователь видит на долю секунды, когда тянет экран вниз, чтобы перезагрузить. Но именно этот незначительный, казалось бы, элемент принес нам много головной боли.
Мы переделывали его на протяжении всех обновлений IOS.
В IOS 13 не было нативного компонента для этой ромашки, мы делали свою эмуляцию.
В IOS 14 мы смогли через обходные пути кое-где включить нативную реализацию.
В IOS 15 нам представили нативный элемент, но оказалось, что он не работает в некоторых условиях. Пришлось искать условия, где он не работает, и использовать на них нашу реализацию. А для условий, где он работает, мы использовали нативный. Таким образом, мы выстроили огромный многоэтажный костыль.
Зоопарк устройств для тестирования
И каждый раз при обновлении операционной системы для тестирования начинается горячая пора. Нужно проверить все приложение, чтобы не возникло никаких сюрпризов.
При этом в идеальной картине мира нам не достаточно держать пару устройств на последней версии iOS и этим довольствоваться. Все-таки желательно иметь весь стек, начиная с устройств с iOS 13, потому что в каждой версии операционной системы есть свои особенности, и нам их необходимо учитывать. Но это слишком энергозатратно, поэтому оптимальный подход — уделять максимальное внимание именно последним версиям. Тем более что большинство пользователей iOS обновляются оперативно. А на более старых версиях полную идентичность и функциональность приложения мы гарантировать, к сожалению, не можем.
Запасной вариант
После изучения недостатков и багов SwiftUI мы пришли к выводу, что все эти проблемы решаемы, хотя и требуют творческого подхода. Далее я расскажу о некоторых методах, которые мы применяли, чтобы справиться с этими вызовами в нашей работе.
Возможности решения багов оказались довольно обширными, потому что, по сути, SwiftUI — это всего лишь надстройка над UIKit. Зная это, через код можно докопаться до исходных элементов.
Кроме того, SwiftUI позволяет создавать UIViewRepresentable-оболочки над компонентами из UIKit, если они отсутствуют в SwiftUI. Эти оболочки позволяют использовать UIKit-компоненты в вашем интерфейсе так, как если бы они были обычными компонентами Swift UI. В частности, в большинстве мест приложения текстовые поля под капотом — UIKit-компоненты, завёрнутые в Swift UI-обертку — ввиду того, что их SwiftUI-аналог не обладает всеми фичами, необходимыми нам.
Третий вариант — это оставлять целые экраны на UIKit, а новые — писать на SwiftUI. Например, у нас в одном приложении с успехом существует главный экран на UIKit. Однако, почти все остальные экраны уже мигрировали на SwiftUI, и это происходило часто незаметно. При этом иногда даже наши продакт-менеджеры не знали, что мы в прошедшем спринте переписали целый экран на SwiftUI.
Таким образом, мы можем последовательно и безболезненно переводить все старые экраны на SwiftUI, и в конечном итоге у нас будет однородная архитектура на одном UI-фреймворке, что и является нашей целью.
Порог входа, поиск разработчиков
Переход на SwiftUI поставил перед нами проблему поиска разработчиков. Очевидно, что с появлением SwiftUI не все Swift-разработчики устремились его осваивать, ведь на тот момент компании его мало использовали, мотивации изучать его не было.
Но важно отметить, что SwiftUI — это достаточно простая технология, она обладает большим объемом документации и учебников, поэтому осваивается буквально за неделю. То есть если к нам приходит разработчик, который подходит нам по всем параметрам, но не знает SwiftUI, то через недельку он уже будет пилить кнопки.
Самое главное требование к кандидату — понимание реактивного подхода к интерфейсу, при котором изменения данных автоматически отображаются в интерфейсе без необходимости явного управления.
Поэтому достаточно, чтобы разработчик был знаком с каким-либо реактивным фреймворком, поскольку весь SwiftUI работает на основе Combine. Фактически не важно, с каким реактивным фреймворком кандидат знаком, так как подходы к реализации реактивности остаются схожими как на Swift, так и на других языках, таких как Java. Поэтому, если у вас есть опыт с RxSwift или ReactiveCocoa, освоение Combine будет относительно простым. Возможно, даже не потребуется полное освоение, так как можно использовать справочные материалы для перевода знаний о том, какая концепция в Swift соответствует той же концепции в Combine.
Рынок
И конечно, в связи с этим можно задаться вопросом: как обстоят дела на рынке, есть ли нужные нам кандидаты?
Когда мы только решили переходить на SwiftUI, всех кандидатов на нашу вакансию можно было поделить на три условные группы:
- Люди, которые ни за что не были согласны писать на SwiftUI. Они считали использование SwiftUI на продакшене безумием. Таких кандидатов было мало, они отказывались прямо на собеседовании.
- Скептически настроенные разработчики. Я сам был из таких, когда приходил на проект, но меня уговорили попробовать.
- Группа энтузиастов. Они тоже считали, что технология не готова к продакшену, но уже интересовались и хотели попробовать этим позаниматься.
С течением времени ситуация сильно поменялась и сейчас уже никто с ходу не отказывается узнав, что у нас SwiftUI в продакшене.
Скептиков тоже как-то поубавилось. В основном, кандидаты готовы попробовать с этим поработать, интересуются, как технология у нас применяется.
Появилась ещё интересная категория — это кандидаты, которые прямо на входе говорят, что принципиально хотят работать только со SwiftUI.
Вот такие перемены мы наблюдаем на рынке в последнее время.
Выводы: стоило ли оно того
Какие выводы мы сделали после 2,5 лет со SwiftUI в продакшене:
Если не мы, то кто?
Начав использовать SwiftUI, мы стали энтузиастами новых технологий. Как показала наша практика, это было верным решением. Ведь чем раньше начать использовать новый подход в проекте, тем более целостным и единообразным он будет. И в будущем у вас не возникнет желания переписывать тонны кода с UIKit на SwiftUI. А новым разработчикам будет легче приступать к работе и вливаться в проект.
Всегда есть пути к отступлению
Мы с самого начала считали, что нерешаемых проблем у нас не будет, и мы всегда найдем решение. Какие-то пути к отступлению найдутся: мы можем использовать legacy-подходы или искать другие варианты. А если опций совсем не остается, то можно договориться с коллегами и нарисовать экран немного иначе.
Взаимодействие с бизнесом
Это вывод следует из предыдущего. Внедряя новый инструмент в работу, нужно обязательно подготовиться на уровне взаимодействия с бизнесом. Бизнес должен быть готов к тому, что некоторые элементы дизайна на данной версии технологии могут быть реализованы иначе. То есть открыт к диалогу с разработчиками.
Сокращение времени на верстку
Если говорить о выгоде, то можно утверждать, что да, мы получили профит. Время, затрачиваемое на верстку, значительно сократилось.
Проще архитектура
В SwiftUI все делится на два слоя: на визуальный слой и на данные. Они довольно прозрачно связываются. Таким образом, структура проекта становится более логичной. Соответственно, не нужно писать какие-то вещи, которые будут это все связывать, и таким образом упрощается архитектура приложения. Оно становится более целостным, без использования сторонних фреймворков
А как же баги?
От багов никуда не деться, с ними приходится постоянно справляться.
Зачастую мы не можем обратиться к каким-то сторонним источникам, потому что у технологии еще молодое комьюнити, и адекватное решение бывает очень трудно найти.
Поддержка Apple
Но при этом явно видно, что подход активно продвигается Apple. В частности, они сами начали писать на SwiftUI некоторые нативные приложения, которые мы получаем вместе с телефоном из коробочки. К примеру, калькулятор, виджеты, интерфейс для часов написаны на SwiftUI
Очевидно, что Apple будут продвигать дальше эту технологию.
И из этого ещё вытекает то, что они продвигают SwiftUI как единый фреймворк для всех вариантов своей платформы. И когда мы пишем интерфейс, то можем ожидать, что он будет одинаково работать на телефонах, на часах, на телевизорах и на десктопах. Это значит, что приложение Banki.ru мы чисто теоретически можем запустить на маке.
Конечно, мы рисковали, начиная работу с SwiftUI. Многие разработчики сомневались в его перспективах. Были проблемы и баги. Но все оказалось решаемым.
Мы изучали ошибки, создавали свои методы работы. Мы освоили реактивный подход с использованием Combine, а также выстроили хорошую коммуникацию с коллегами на случай поиска альтернативных решений.
Спустя два с половиной года наше приложение на SwiftUI успешно функционирует и продолжает развиваться. Оно стало более удобным в поддержке. В целом, можно сказать, что переход на SwiftUI оказался успешным для нашей компании.
Учебное пособие по SwiftUI: создание приложений с помощью новой среды пользовательского интерфейса Apple
SwiftUI — это следующее поколение UIKit от Apple, которое встраивается в каждое приложение для iOS, разработанное в 2019 году.
Но SwiftUI все еще находится в стадии разработки, поэтому API еще не всегда являются окончательными. Это означает, что лучше всего использовать последнюю версию API, чтобы все работало гладко.
Тем не менее, SwiftUI выходит очень скоро, а это значит, что разработчикам придется изменить свой дизайн.
Поэтому мы подумали, почему бы не создать несколько простых практических руководств, которые покажут вам лучшие способы реализации SwiftUI в ваших проектах?
Их можно прочитать бесплатно, и мы уверены, что они помогут вам начать работу с приложением SwiftUI.
Что такое учебные пособия по SwiftUI?
Новый фреймворк SwiftUI от Apple меняет правила игры в разработке пользовательских интерфейсов. SwiftUI — это совершенно новая среда разработки пользовательского интерфейса от Apple, разработанная, чтобы помочь вам быстро и легко создавать высококачественные приложения.
Удивительно, но это намного больше, чем просто новый фреймворк UIKit.
Самое приятное то, что вам больше не нужно использовать XCode или Interface Builder для разработки ваших приложений. Вместо этого вы можете создать свой интерфейс, используя код Swift.
Это важный шаг вперед, потому что SwiftUI — это будущее iOS-разработки. Тем не менее, есть еще несколько вещей, которые вам нужно знать о фреймворке, прежде чем вы начнете его использовать.
Что предлагают учебные пособия по SwiftUI?
Обучение SwiftUI может сделать вас мастером разработки приложений; тем не менее, некоторые вещи, которые вы узнаете, включают:
1. Основы SwiftUI
Это простое руководство по SwiftUI. Вы узнаете, что такое SwiftUI и что он может сделать для вас. Это бесплатно, и это отличное место для начала, если вы новичок в SwiftUI.
Например, вы узнаете, что такое представление, как реализовать представление SwiftUI и как сделать так, чтобы ваше приложение выглядело великолепно.
Например, базовый шаблон для приложения SwiftUI:
Вы узнаете, как создать свое приложение с помощью этого простого функционального шаблона.
2. Собираем полноценный проект
Вы сможете создать полноценное приложение с помощью SwiftUI. Вы узнаете, как использовать UIKit, SceneDelegate и Storyboard. Сделайте простую кнопку. Как скомпоновать список и панель навигации поверх всего.
Привязки и формы станут важной частью SwiftUI, и вы узнаете о них. Как использовать их, чтобы сделать ваш пользовательский интерфейс более отзывчивым.
3. Добавление медиа
Есть много вещей, которые вы можете сделать со SwiftUI. Но вы, скорее всего, будете использовать его для отображения мультимедиа, что является самым простым способом начать использовать SwiftUI. Анимация, изображения и видео — отличные способы отображения мультимедиа, но вы также можете делать гораздо больше.
Самый простой способ добавить мультимедиа в ваше приложение — использовать камеру. Для этого вам нужно добавить UIView в контроллер представления вашего приложения и добавить в него следующий код:
import SwiftUI struct ContentView : View < var body : some View < VStack
>. background ( Color. black ) > >
Здесь мы добавляем UIView к нашему представлению. Мы также добавляем к нему изображение, назвав его «image_source».
Функция Image() возьмет изображение из переменной image_source и отобразит его.
4. Работа с набором предварительно отформатированных документов
При создании приложения SwiftUI вам потребуется работать с набором предварительно отформатированных документов. Например, создайте UIImageView, который отображает предварительно отформатированный UIImage, или UITextField, который отображает предварительно отформатированную строку.
Вам также потребуется создать набор UIViews, предварительно отформатированных с помощью SwiftUI. Вы будете создавать серию UIStackViews, UITableViews и UIAlertViews.
5. ListView и GridView
SwiftUI представил ListView и GridView, которые представляют собой новые концепции для обработки списков и сеток. Узнайте, как использовать их в SwiftUI и в своих собственных приложениях.
6. Инструменты
Получите больше от своих приложений с помощью XCode. Например, вы можете получить доступ к полной иерархии приложения, чтобы увидеть, как построен пользовательский интерфейс. Вы также можете использовать XCode для создания пользовательского перехода и навигации между представлениями.
Часто задаваемые вопросы
В. Насколько близко код соответствует предварительному просмотру?
SwiftUI использует генератор кода для создания предварительного просмотра. Код генерируется из пользовательского интерфейса, который вы настроили в XCode.
Вы не сможете изменить код, иначе предварительный просмотр будет другим.
В. Каковы возможности SwiftUI?
SwiftUI — это среда разработки пользовательского интерфейса для iOS. Это полноценная структура, построенная с нуля. Он основан на принципе «однонаправленного потока данных».
Это фреймворк с открытым исходным кодом. Он построен на Swift, новой технологии Apple. язык программирования. Он предназначен для создания быстрых и отзывчивых приложений. Он использует новый UIKit.
В. В чем разница между SwiftUI и UIKit?
SwiftUI — это новый фреймворк пользовательского интерфейса, построенный на основе фреймворка UIKit. UIKit — это стандарт iOS фреймворк для создания пользовательских интерфейсов.
Это самая мощная и универсальная структура пользовательского интерфейса на планете. Он позволяет создавать богатые, отзывчивые и высококачественные пользовательские интерфейсы.
Но UIKit ограничен платформой iOS и доступен только для iOS 12.0 и более поздних версий. Итак, SwiftUI — это будущее iOS-разработки.
Итог
В заключение, вы не можете сразу перейти к проекту и начать создавать приложения с помощью SwiftUI.
Если вы хотите использовать SwiftUI в своих проектах, вам нужно сначала создать основу. Так чего же ты ждешь? Идите вперед и изучите SwiftUI сегодня!