Техно Лёха

Как мы подружили SwiftUI и дизайн-систему

Примерно полтора года назад мы с командой решили что хотим в SwiftUI. Но оказались в ситуации: вроде бы все знают что это, но ни у кого нет особо опыта в продакшене.
И возник главный вопрос: «а с чего начать то»?
У меня к тому моменту уже был опыт в SUI и я пришёл к техлиду с желанием помочь внедрять в проект. Обсудив, решили что нужны «строительные блоки» - с помощью которых любой разработчик сможет написать фичу на SwiftUI. Видишь макет - понимаешь из чего собрать на SUI.

Почему Atomic Design:
За основу взяли методологию Atomic Design (картинка). Идея простая: мельчайшие блоки интерфейса - это атомы и молекулы: токены цветов, лейблы, картинки, кнопочки. Начинаем с них и постепенно собираем всё остальное.

Что сделал на старте:
Написал обёртки для базовых вещей: Color, Text, Image. Это позволило использовать существующие токены дизайн-системы прямо в SwiftUI - через extension'ы и кастомные ViewModifier'ы. Разработчик берёт знакомые названия из UIKit-мира и пишет на SUI без переучивания.
Параллельно написал документацию по переезду и рассказал на гильдии - а потом ещё и ещё несколько раз. Организовал встречу, на которой делились опытом у кого его было больше (ребята из Drinkit). Решали проблемы о которые спотыкались, обсуждали как вообще хотим писать на SUI.

Синхронизация с дизайнерами:
Много общались с дизайнерами: показывали как устроен SwiftUI, прям иногда вместе код смотрели. Они уже знали что Figma умеет генерировать какой-то код - стало проще говорить на одном языке.

Что в итоге:
Когда базовые молекулы были готовы - перешли к компонентам новой дизайн-системы. И все компоненты уже полностью на SwiftUI.
За это время вся команда получила практический опыт. Когда дошли до компонентов - разработчики уже понимали SwiftUI. А это важно, потому что компоненты ДС у нас пишут не отдельные люди, а вся команда вместе.
Про то как организовали сам процесс разработки компонентов - подробно написал Серёга у себя в канале.

BlurHash

Опенсорсный алгоритм от Wolt, который умеет из картинки сгенерировать строчку текста (хэш), а затем из этой строчки можно сгенерировать плейсхолдер картинки. Как использовать: можно отображать красивый плейсхолдер вместо серого квадратика, пока загружается картинка с сервера. Огромное количество мест, где можно применить - я затащил в чат, получилось красиво.

Реализация алгоритма есть на все популярные языки программирования. Вот тут экстеншен на UIImage для кодирования и декодирования.

Поиграться и посмотреть, как это выглядит, можно на сайте

Логи Xcode

В Xcode 16 появилась возможность вот так удобно:
1) Скрывать логи всего, что не нужно. Например, скрыть засоряющие системные логи.
2) Показывать только нужные логи. Например, логи на констрейнты.

А также подстроить параметры отображения каждого лога.

Можно прям правой кнопкой по логу тыкать и выкидывать его из списка

Для комментов
А то у поста выше нет возможности оставлять комменты

Ускорение билда на 25%

Самая долгая часть при билде приложения пиццы — это компиляция ассетов. Поэтому хочется запускать процесс билда как можно раньше и сделать так, чтобы он не зависел ни от чего.

Предистория:
Почему ассеты все оказались в одном модуле?

Однажды мы решили, что было бы удобно хранить все картинки в одном месте, чтобы они не дублировались и было удобно с ними работать: не забывать из какого правильного бандла их брать.

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

Тулинг:
В Xcode можно посмотреть схему билда через Build Assistant, но зависимости там вообще не отследить. Поэтому я использовал Build Graph, который Миша Рубанов недавно выложил в open source.

Как было:
В приложении пиццы ассеты лежали внутри модуля с UI-компонентами — DUIKit.
Этот модуль подключается ко всем фичевым модулям приложения.

Из-за этого фичевые модули не могут начать билдиться, пока не соберётся модуль с компонентами. А так как модуль компонентов содержит в себе все ассеты, получается цепочка:

ждём компиляции ассетов → билдим DUIKit → собираем фичевые модули.

Если посмотреть на схему билда, видно «дырку» с ожиданием. Это отлично заметно в Xcode (рис. 1).
Открываем через Build Graph и видим (рис. 2):

доходим до билда DUIKit
ждём, пока соберутся все ассеты
продолжаем билдить фичевые модули

Как стало:
Я вынес все ассеты (картинки, иконки, цвета) в отдельный модуль — DesignSystemAssets — и заимпортил его в DUIKit.

На графике видно, что теперь ассеты не зависят ни от чего и могут билдиться сильно заранее (рис. 3).
График стал выглядеть иначе — ассеты иногда начинают собираться чуть ли не первыми (рис. 4).
Вот так теперь выглядит схема в Xcode (рис. 5).

Что в итоге:
После выноса ассетов локальный билд на MacBook с M3 Pro ускорился примерно с 2 минут до 1,5 минут.

Это около 25% ускорения только за счёт вынесения ассетов.
На CI c примерно 4 минут до 3 минут

Для разработчиков:
• быстрее локальный билд
• меньше времени на ожидание сборки
• быстрее проверка фичей и багфиксов
Для бизнеса:
• быстрее проходит CI
• меньше минут тратится на CI — экономия денег
• быстрее доставка фичей в прод

Channel photo updated

Channel created