🔢 Структура SwiftUI-проекта, которая не разваливается с ростом. Стандартная структура от Xcode - это ловушка. ContentView.swift, пара папок, и вот уже через три месяца вы не можете найти, где лежит экран настроек, потому что он затерялся среди 50 других файлов в одной куче. Чтобы проект жил долго и счастливо, нужна система. И желательно с первого дня. Главная ошибка - группировка по типам: Самое популярное, но неудачное решение: папки Views, Models, ViewModels. Вроде логично, но когда в Views оказывается 40 файлов, а в Models - 20, вы начинаете тратить время на поиск. Хуже того, связанные сущности разбросаны по разным местам. Чтобы понять, как работает авторизация, нужно открыть три папки и собрать пазл. Фичевая организация - спасательный круг: Гораздо удобнее группировать код по функционалу. Каждая фича - отдельная папка, внутри которой лежит все необходимое: вьюхи, модели, вью-модели, кастомные компоненты, специфичные для этой фичи. Если нужно поправить экран профиля, вы идете в папку Profile и видите все, что к нему относится. Никаких блужданий по проекту. Что вынести за пределы фич: Не все должно жить внутри фич. Есть вещи, которые используются по всему приложению: 🔵Core: сеть, хранилище, базовые сервисы. Один экземпляр на все приложение, инициализируется один раз. 🔵UI Components: переиспользуемые кнопки, поля ввода, лоадеры. Чтобы не писать один и тот же стиль в каждом экране. 🔵Theme: цвета, шрифты, отступы. Единое место, где живет дизайн-система. 🔵Extensions: полезные расширения для стандартных типов. 🔵Resources: ассеты, локализация, шрифты. ViewModel с человеческим лицом: Каждая вью-модель должна быть аккуратной и предсказуемой. Несколько правил: 🔵@MainActor - чтобы не думать о потоках при обновлении UI. 🔵private(set) для публикуемых свойств - никто не должен менять состояние извне. 🔵Зависимости через инициализатор - чтобы можно было подменить их в тестах. 🔵Методы, которые четко отражают действия пользователя. Навигация без боли: Для простых приложений хватает встроенного NavigationStack с navigationDestination. Когда экранов становится много, стоит задуматься о координаторе. Один класс, который управляет всей навигацией в приложении - это сильно упрощает жизнь, особенно когда нужно передавать данные между экранами или обрабатывать диплинки. Главное - последовательность: Любая структура работает, если ей следовать. Хуже всего кога часть кода лежит по фичам, часть - по типам, часть - вообще в корне. Выберите один подход и придерживайтесь его от начала до конца. Новые разработчики в команде скажут спасибо. 🔗 Ссылка на подробную статью 💡 Вывод: Организация проекта - это не про «красивую структуру», а про скорость разработки и стоимость поддержки. Когда на поиск нужного файла уходит 10 секунд вместо 5 минут, когда новая фича не ломает старую, когда код понятен даже тем, кто видит его впервые - это и есть правильная архитектура. А начинается она с правильной структуры папок. ➡️ Подписаться на канал Мобильный трудоголик