🔨 Stanford CS193p лекция 3 Model & UI + Swift Type System
В новой лекции разбираются фундаментальные принципы работы SwiftUI через призму архитектуры модели и системы типов Swift — то, что определяет устойчивость и масштабируемость iOS-приложений.
Перемешивание UI и логики. Во многих SwiftUI-проектах View начинает обрастать обязанностями: хранением данных, обработкой логики, сетевыми вызовами. Это приводит к:
🟡Трудному тестированию
🟡Отсутствию переиспользования
🟡UI, зависимому от внутренних деталей хранения данных

Чёткое разделение Model ↔️ View
Связка Model и UI — центральная концепция лекции. SwiftUI ожидает, что:
🟡Model хранит истинное состояние и бизнес-логику.
🟡View — чистая функция состояния: она описывает интерфейс, но не владеет логикой.
Это делает приложение устойчивым к изменениям и легко тестируемым.

Swift Type System как фундамент архитектуры. Лекция подчёркивает важность системы типов Swift:
🟡Struct как основной строительный блок данных. Value-semantics уменьшают количество багов, связанных с состоянием.
🟡Enum + associated values. Мощный инструмент для моделирования состояний экрана: loading / success / error.
🟡Optionals. Встроенная безопасность, которая заставляет проектировать модель осознанно.
🟡Immutability по умолчанию. View остаются предсказуемыми, изменения происходят только в модели.

MVVM как естественный путь
CS193p фактически показывает MVVM-подход, но без перегибов:
🔵Model — данные и логика.
🔵ViewModel — источник правды для View, объявленный через @Observable / @StateObject.
🔵View — рендер состояния, без тяжёлой логики.

Выводы:
🔵Избегайте логики в View — переносите в модель или ViewModel.
🔵Используйте enum-состояния для сложных процессов (загрузка, ошибки, пустые состояния).
🔵Стройте данные на основе struct — меньше сайд-эффектов и легче тестировать.
🔵Используйте Optional осознанно: они должны отражать реальную модель данных.
🔵Делайте View чистой функцией состояния — UI становится стабильнее и проще.
#cs193p

🐥 Все не так с Codable
Выпустили статью про наши оптимизации JSONDecoder/Encoder. Очень советую к прочтению, получил огромное удовольствие при редактуре.

Почему Codable тормозит?
🔵Многие приложения используют Codable для API-ответов, UserDefaults, кешей и пр. — и именно от его скорости часто зависит старт/UI-ответ.
🔵Внутренние механизмы стандартной реализации делают много проверок conformances (соответствий протоколам), особенно через вызовы swift_conformsToProtocolMaybeInstantiateSuperclasses. Эти вызовы оказываются самой медленной частью сериализации/десериализации
🔵Причём чем больше моделей и ключей (CodingKeys) — тем хуже масштабируется производительность

Оптимизации в JSONDecoder/Encoder
🟢Мы проанализировали использующиеся проверки и смогли уменьшить накладные расходы при conformances, избегая лишних runtime-поисков
🟢Предложили универсальный `AnyCodingKey`, который снижает количество разных protocol-denoscriptors, экономя работу рантайма
🟢Благодаря этим подходам, в A/B-экспериментах на 80 000 пользователей сериализация и десериализация стали в ≈2× быстрее на ключевых квантилях

🎁 Оптимизация через макросы
Чтобы ещё сильнее ускорить, мы конвертировали модели на уровне генерации кода:
🔵Использование Swift-макросов для автоматической генерации init(from:)/encode(to:) без CodingKeys
🔵Это уменьшает нагрузку на рантайм и ещё сильнее снижает overhead сериализации/десериализации

Выводы
🟡Если у вас большие JSON-модели или массовый парсинг/запись — Codable может быть узким местом
🟡Оптимизация ключей, контроль CodingKeys и сокращение количества протоколов, через которые проходит парсинг — реально влияет на производительность
🟡В продакшн-приложениях важно измерять не только бизнес-логику, но почти «внутренности» стандартных API — часто именно там скрываются миллисекунды, влияющие на UX