iOS Makes Me Hate
3.94K subscribers
1.16K photos
169 videos
15 files
1.33K links
Авторский канал про iOS разработку. Путь продуктовых самураев в MAANG.

Самое больше iOS сообщество практиков: https://boosty.to/lionbond/

Автор: @lvbond Senior iOS Yandex, ex-Avito, VK
Download Telegram
🌿 Deep dive AttributeGraph: Внутреннее устройство и жизненный цикл

Мы уже объясняли такую ментальную модель как View Tree, но под капотом нет такого понятия. Есть только AttributeGraph. Разница между деревом (tree) и графом (graph) в том, что в графе зависимости могут течь в любом направлении. Это значит, что визуально структура UI напоминает дерево, на самом деле под капотом используется граф зависимостей, где узлы могут иметь взаимные зависимости.

Как мы уже помним, чтобы писать более производительный код на SwiftUI, мы должны понять этот фреймворк. Apple скрыл внутренности как это работает, хоть некоторые и пытались зареврс инжинирить. Вокруг этой темы нет документаций. Материалы отличаются только по уровню практических ресерчей от комьюнити. Единственное, что мы можем — опытным путем изучить работу этого механизма.

AttributeGraph — это граф с расширенной моделью атрибутов. Ключевая особенность — это не просто связи между узлами, а система распространения изменений атрибутов. SwiftUI — декларативный UI. А чтобы декларативный UI работал эффективно, нужен быстрый механизм обнаружения изменений.


AttributeGraph — это не уникальная концепция. Очень похожая есть и в React с его виртуальным DOM'ом и других технологиях.

Ключевые понятия AttributeGraph:
🌟Nodes — Либо входное значение (@State, @Binding, @Environment). Либо вычисляемое значение, зависящее от других узлов.
🌟Edges — “стрелка зависимости между Node”. Edge показывает какой узел зависит от какого. Когда один узел изменяется, какие другие нужно пересчитать.

Схема работы AttributeGraph в SwiftUI выглядит так:
1. Создание узлов данных (Nodes): Когда ты описываешь @State, @Binding, @ObservedObject, SwiftUI: создаёт отдельные Node объекты для каждого состояния.
2. Первая вычислительная фаза — Построение зависимостей (Edges). Когда SwiftUI вычисляет body SwiftUI включает режим записи зависимостей: Каждый доступ к данным регистрируется как: graph.addEdge(from: variableNode, to: viewNode). Это происходит автоматически во время первого прохода по body
3. Реакция на изменение данных — Инвалидирование (Invalidation Phase). Система помечает изменённые узлы и пересчитывает только нужные значения.
4. После пересчёта SwiftUI перерисовывает только те элементы интерфейса, которые реально изменились.

Вдохновившись серией выпусков от objc.io решил сделать примерную реализацию графа. Детальней в скриншотах, но потом сделаю большую статью в ноушене. В будущих постах сделаем связь между узлами и других особенностей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
147
17
🛍Приглашаем на большой митап Яндекса по мобильной разработке!

На Я.Субботниках технические специалисты Яндекса рассказывают об устройстве сервисов, над которыми они работают. В этот раз собираемся в двух городах — Москва и Санкт-Петербург!

Что ждёт участников:
🟠5 докладов про iOS и Android;
🟠PeerLab: разбор кейсов из реальной практики с экспертами;
🟠Afterparty и нетворкинг

Среди тем докладов этого года: секреты адаптации мобильного приложения под ТВ, стратегии ускорения старта и observability-система для BDUI. Полное расписание ищите на сайте.

➡️ Регистрируйтесь и приходите слушать доклады, задавать вопросы и обсуждать кейсы
Please open Telegram to view this post
VIEW IN TELEGRAM
4
🌟🌟Топовые статьи по архитектуре SwiftUI, навигации, валидации, SwiftData и не только

Разработка приложений в больших командах — отдельный вызов и опыт. Когда твоя команда и продукт небольшой, то многим можно пренебречь. Но уже с увеличением аудитории и команды объемы производства кода увеличиваются, а значит и импакт от оптимизаций тоже растет.

Попалась подборка интересных статей про архитектуру SwiftUI приложений в больших командах. Мы уже писали о некоторых статьях, но есть и новые.

🌟Building Large-Scale Apps with SwiftUI
Подробное руководство по модульной архитектуре для масштабных SwiftUI-приложений. Как разбить проект на независимые модули и упростить сопровождение.

🌟SwiftData Architecture – Patterns and Practices
Практики проектирования архитектуры с использованием SwiftData. Управление моделью данных, работа с хранилищем и зависимости.

🌟The Ultimate Guide to Validation Patterns in SwiftUI
Подходы к валидации пользовательского ввода: как сделать формы безопасными, удобными и повторно используемыми.

🌟Introduction to Communication Patterns in SwiftUI
Как компоненты SwiftUI обмениваются данными — через @Binding, @Environment, ObservableObject и другие способы.

🌟Global Sheets Pattern in SwiftUI
Управление модальными окнами (sheets) из любого места приложения. Упрощает отображение экранов без жёсткой связи между модулями.

🌟Navigation Patterns in SwiftUI
Обзор современных навигационных подходов: StackNavigation, Routing, NavigationPath и как избежать “адской” вложенности.
Please open Telegram to view this post
VIEW IN TELEGRAM
143
Забирает ли AI радость от работы

Большинство знакомых мне людей сходятся на том, что AI точно повышает продуктивность индивидуального разработчика – код пишется и рефакторится быстрее, а задач закрывается больше. Для тех, кого мы привыкли называть "продуктовыми разработчиками" – людей, кого в первую очередь драйвит результат их работы, создаваемый продукт, и его влияние на бизнес и мир вокруг – это просто прекрасно и бьет в их факторы мотивации.

Но помимо них в индустрии есть довольно большой сегмент тех, кто любит сам процесс написания кода, и получает удовольствие от самостоятельного решения инженерных задач. Использование AI, конечно, оставляет инженерные задачи, перемещая их на более высокий уровень – ты должен думать не столько о том, как реализовать нужный алгоритм, сколько о том, как спроектировать систему. Но для многих этого будет недостаточно – ведь и раньше не каждый хотел расти в архитектора.

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

Разработчики — неидеальные люди. За тоннами статей и документаций всегда стоит практика, которая срывает покров реальных проблем.

Не все, что описано, работает как ожидается. А многое может быть вообще не описано.

Для меня гораздо полезнее разборы тех вещей, которые не прочитаешь в исходниках, документациях и тп. Например, очень часто бывают баги или даже краши, когда воспроизводятся только под определенной версии iOS, swift’а или даже Xcode.

Позже разберем какие-нибудь отдельные из репы.

Кстати, скоро попробую собрать похожее с Swift Concurrency. Недавно обожглись и с ним 🥲
Please open Telegram to view this post
VIEW IN TELEGRAM
112
This media is not supported in your browser
VIEW IN TELEGRAM
Сорри, пока майские чисто деградируем под мемы
14
Wake the fuck up, Samurai
148
В it нет «правильных» или «неправильных» законов и правил

Следующий месяц мы продолжим погружаться в непростые и практичные вещи в SwiftUI, поэтому обещаного традиционного голосования с темой на месяц не будет. Демократия закончилась 🥲

Нередко слышу инженеров, которые ищут тех, кто будет с полуслова их понимать. Тем, кому не нужно объяснять почему здесь нужно использовать SOLID принципы или долго выбирать правильное решение, а моментально на каком-то экстрасенсорном уровне приходить к одному решению. Считаю это фантастикой. Ведь любая разработка это всегда поиск решений и изучение разных требований, которые никто не найдет в абсолютном молчании или согласии. Эффективный процесс принятий решений — это всегда большой труд.

Начнем этот месяц с разбора темы «правильных путей». Автор делится мнением, что нет никаких правильных архитектур и решений. Многие вещи зависят от целей и контекстов.

🌟контекст имеет значение

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

🌟нет серебряных пуль

У каждых решений есть свои недостатки и плюсы.

🌟субъективные предпочтения

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

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

SwiftUI vs UIKit
Автор рассматривает дебаты между сторонниками SwiftUI и UIKit. Он отмечает, что SwiftUI отлично подходит для простых проектов, но может быть менее эффективным для сложных приложений, где UIKit предоставляет больше гибкости. Таким образом, выбор между ними должен основываться на требованиях конкретного проекта, а не на общих предпочтениях.

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

Принятие этой идеи способствует профессиональному росту и более эффективной работе в команде.
Please open Telegram to view this post
VIEW IN TELEGRAM
11
Кодстайл в крупномасштабном проекте на примере SwiftUI

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

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

Статья подчеркивает важность командной работы и согласованности в больших проектах. Хорошо продуманное руководство по стилю кода:
🌟Упрощает совместную работу.
🌟Облегчает обучение новых разработчиков.
🌟Повышает качество и стабильность продукта.

Здесь много очевидных вещей, но если ищите чеклист для вдохновения для своей команды, то отличный пример
Please open Telegram to view this post
VIEW IN TELEGRAM
8