Разработка

Apple не использует MVVM? MVVM — это неправильный архитектурный шаблон?

Если это делает ваш код SwiftUI чистым, поддерживаемым и масштабируемым — это правильная архитектура.

Опубликовано

2 дня назад

21.01.2026

Автор:

AppTractor

«Apple не использует MVVM».

«MVVM — неправильный архитектурный шаблон».

«MV — это то, как это должно быть сделано».

Слышали подобные утверждения раньше?

Я точно слышал — особенно в Твиттере (или как он там сейчас называется). В сообществе SwiftUI идёт непрекращающаяся борьба за то, какая архитектура «правильная». И знаете что? Я почти поверил в эту точку зрения… пока недавно не посмотрел официальный обучающий ролик Apple.

И тут внезапно. Прямо посреди этого безупречного кода Apple оказалась ViewModel — делающая то, что у неё получается лучше всего: управление логикой, хранение состояния и поддержание чистоты и лаконичности представления SwiftUI.

Взгляните на этот шедевр из обучающего ролика:

Да, это прямо @State var viewModel: StickerViewModel. Apple не просто одобряет ViewModel — они активно используют их, чтобы научить новичков создавать приложения.

Но подождите, разве SwiftUI не «декларативный»?

Да, это так! SwiftUI — это декларативный, реактивный и все эти модные словечки. Но это не значит, что мы должны запихивать всю логику внутрь View, как всю начинку в индейку на День благодарения.

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

Теперь спросите себя:

Должно ли представление знать, как получать фотографии?
Должно ли оно обрабатывать бизнес-правила, такие как «если фотография неактивна, показать плейсхолдер»?
Должно ли оно управлять логикой отображения экрана?

Абсолютно нет.

В тот момент, когда ваше View становится мастером на все руки, его тестирование, отладка и масштабирование превращаются в кошмар. Вот тут-то и приходит на помощь ViewModel — как тихий незаметный ниндзя, который делает грязную работу, чтобы ваше представление могло просто… ну, показывать то, что нужно.

MVVM против MV против «Просто здравый смысл»

Давайте быстро расшифруем аббревиатуры:

MV (Model-View): всего два слоя. Представление напрямую взаимодействует с моделью. Чисто для простых вещей, неряшливо для чего-либо сложного.
MVVM (Model-View-ViewModel): Вводит ViewModel в качестве посредника для изоляции логики/состояния. Отлично подходит для ясности и тестируемости.
MVOCDTFC (Model-View-Other-Crazy-Design-That-Fits-Context): Ладно, я это придумал — но иногда архитектура действительно зависит от сложности вашего приложения и вашей команды.

Вот в чем загвоздка:

Архитектура — это не догма. Это всего лишь инструмент.

Используйте ее для разделения задач, упрощения тестирования и масштабирования кода.

Вы можете написать плохой MVVM. Вы можете написать красивый MV.

Но сам шаблон — не злодей, им может быть только ваша реализация.

Мнение читателя: Представления в SwiftUI — это не то, что вы думаете

Один меткий комментарий читателя действительно точно отражает суть SwiftUI:

Чтобы иметь ViewModel, сначала нужно заиметь View… но в SwiftUI представления не существует! Это просто фрагменты данных (значения, а не объекты), которые сравниваются (фреймворком, а не вами) для создания физического представления. Ваша задача — объявить, как данные сопоставляются с физическими представлениями (функция body) и вызывать действия (чистые функции, а не методы). Важно отметить, что состояние не принадлежит структуре представления — структура неизменяема. Фактическое состояние (и другие динамические свойства) управляются фреймворком. Вы просто знаете, как их использовать, через wrappedValue и projectedValue.

Это блестящее резюме.

SwiftUI не предоставляет вам долгоживущие представления, как UIKit. Вы не храните состояние и не управляете жизненными циклами. Вместо этого SwiftUI постоянно переоценивает представление в зависимости от состояния. Фреймворк управляет тем, когда и как сохранять состояние и отображать представления.

Так что же это значит для MVVM?

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

Спасибо комментатору за то, что он обратил на это внимание. Иногда один комментарий может сказать то, что требует объяснения в десятке абзацев.

Давайте упростим с помощью аналогии

Представьте себе ваше представление SwiftUI как официанта в ресторане.

Вы бы ожидали от официанта:

Приготовления еды?
Пополнения запасов?
Составления меню?

Нет. Это работа шеф-повара (он же ViewModel). Работа официанта — представить что-то клиенту и передать ему данные — просто и понятно.

Ваше представление должно представлять данные, а не вычислять их.

А как насчет тестирования?

С MVVM вы можете легко писать модульные тесты для логики ViewModel, не запуская предварительный просмотр SwiftUI или симулятор. Речь идет не только о поддержании порядка — речь идет о возможности быстрее выпускать качественный продукт и исправлять ошибки до того, как они попадут в продакшн.

Честно говоря: даже Apple не придерживается архитектуры

Давайте будем реалистами: Apple не навешивает ярлыки на свои архитектуры. Они делают то, что работает, в зависимости от контекста.

Но когда Apple использует ViewModel в своих образовательных материалах — например, в фрагменте кода StickerCarousel — это явный сигнал. Они говорят:

Используйте то, что работает. Но подумайте о разделении ответственности.

И именно это мы и должны делать.

Заключительные мысли

Забудьте о ярлыках. Сосредоточьтесь на:

Ясности: Может ли кто-то другой прочитать и понять ваш код?
Разделении ответственности: Четко ли распределены обязанности?
Тестируемости: Можете ли вы писать тесты без загрузки пользовательского интерфейса?

Назовите это MVVM, MV или «Компонентно-ориентированной пиццо-архитектурой». Если это делает ваш код SwiftUI чистым, поддерживаемым и масштабируемым — это правильная архитектура.

Поэтому в следующий раз, когда кто-то скажет: «Apple не использует MVVM», просто улыбнитесь, покажите им скриншот из учебного пособия и скажите:

«Вы уверены в этом?»

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.