🫠 Прощай, Swift

Сегодня второй рабочий день в роли Техлида. Два дня уже не программировал, ломает.

А если серьезно, то теперь буду лидить разработку Райффайзен Онлайн - iOS приложения для физических лиц. Невероятно крутая возможность сделать значительный ап своих навыков. Тут и стратегия, и архитектура, и инициатива.

На фоне этого я хочу переформатировать канал. И если раньше я старался держать его только в рамках iOS-разработки, то теперь попробую рассказывать чуть шире. Будет больше постов о том, что не менее важно для мобильного разработчика, чем его код: физическое здоровье, усталость, быт, организация рабочего процесса.

Про разработку конечно не буду забывать, RaifMagic, о котором говорил выше все еще остается в моем ведении. Время от времени буду наливать смузи и кодить на SwiftUI.

#видеозаписи #МобильныйВторник

Открываем новую видеозапись выступления:
Кирилл Шумаков, Василий Усов — Молот и наковальня iOS-разработчика

YouTube | VK Видео

🍷Отличный повод выйти из техлидского запоя и запилить пятничный пост после полугода шокового состояния от новой должности

Для информации, Педро - основатель Tuist. Ну а что такое Tuist для iOS, думаю, рассказывать не нужно.

Ну а мои ребята - 💪🏼. Беспощадно контрибьютят в Tuist и интегрируют его решение в проекты Райфа.

Когда структуры в Swift — не твои бро

Один из лучших докладов на Mobius 2025 Autumn. Очень люблю, когда докладчик копает глубоко, объясняет хорошо и разочаровывает меня в Swift.

💡Основное:

- Структуры не всегда ускоряют работу приложения, а не редко замедляют ее и увеличивают размер бинаря.
- Карта линковки (Link Map) позволяет посмотреть из каких сущностей состоит итоговый бинарь,
- С помощью LinkMap можно узнать размер сущностей, вырезанные символы, которые не используются в итоговом бинаре и являются кандидатами на удаление из кода, анализировать краши без DSYM.
- Для сохранения Link Map в файл необходимо включить настройку Build Setting → Linking - General → Write Link Map File. Файл будет сохранен в Derived Data с именем {Имя_таргета}-LinkMap-normal-arm64.txt.
- Имена символов манглированы, нужно деманглировать с помощью swift demangle '{Имя_символа}'
- Чем больше вложенность структур друг в друга, тем больше будет итоговый размер структуры. Обычно особенно проблемными являются компоненты дизайн-системы.
- Использование экзистенциальных контейнеров дополнительно увеличивает размер за счет создания сервисных методов witness table. То есть, если компилятор не может рассчитать конкретный тип, а ходит через протокол - ситуация ухудшается. Вот почему нужно использовать some/generic везде, где это возможно.
- Флаги оптимизации -O никак не влияют на рост размера структур.
- Необоснованный рост может быть в КБ, десятки и сотник КБ, и даже МБ для особо больших структур.
- Накладные расходы на поддержку работы структур от 2 КБ превышают расходы на использование ссылочных типов
- Добавление indirect для enum зачастую лечит проблемы, когда в качестве associated value используется "дрянная структура".
- Для определения того, какие структуры наиболее важны для такого рефакторинга можно построить граф вложенности структур (на основе Xcode index Store) и определить метрику центральности графа (Betweenness)

🧠 Мысли после доклада:

- А что там со SwiftUI? Вьюшки с кучей проперти-врапперов разгоняют размер и снижают скорость? Имеет ли смысл дробления вьюшек на более мелкие не только ради переписовок, но и облегчения размера?
- А что с NonCopyable структурами? Они не копируются и возможно в них нет такого большого количества сервисного кода.
- Как именно выглядят дженерики в итоговом файле - требует дополнительного изучения.

🔗 Ссылки:

- Видео (если у вас есть билет на конференцию)