Почему в коде SwiftUI могут появляться фиолетовые ошибки во время выполнения?
Что проверяют
Понимаете ли вы, что фиолетовая метка в Xcode это не падение и не ошибка компиляции, а предупреждение времени выполнения от санитайзеров и от самого SwiftUI. Дальше смотрят, знаете ли вы типовые причины и не приучились ли их глушить.
Как отвечать
Фиолетовым помечаются runtime issues, их поставляют Main Thread Checker, Thread Sanitizer и рантайм SwiftUI. В SwiftUI чаще всего попадаются четыре.
Publishing changes from within view updates: состояние меняется прямо во время вычисленияbody, от которого этот жеbodyи зависит. Мутацию надо унести вonAppear,task,onChangeили в обработчик действия.Publishing changes from background threads:ObservableObjectобновили из фонового колбэка. Лечится пометкой модели как@MainActorили переносом публикации на главную очередь.Accessing StateObject's object without being installed on a View: к объекту обратились до того, как вью попала в иерархию, и вместо общего экземпляра создаётся лишний.Invalid frame dimension: в размеры пришёл NaN или бесконечность, обычно после деления на ноль при пустых данных.
Полезно рассказать, как их ловить. В Xcode включается остановка на runtime issue, и тогда в стеке видно, чей именно body мутирует состояние. Без этого предупреждение показывает лишь точку срабатывания, а не виновника.
Где спотыкаются
Считают фиолетовое косметикой, раз приложение не падает. За формулировкой стоит неопределённое поведение: на следующей версии SDK то же место даёт бесконечный цикл перерисовки или молча потерянное обновление.
Лечат симптом, оборачивая мутацию в асинхронный вызов на главной очереди прямо внутри body. Предупреждение уходит, потому что изменение переехало на следующий кадр, а лишняя перерисовка и мигание интерфейса остаются на месте.
Путают эти отметки с ошибками сборки и ждут, что их поймает релизная сборка или автотесты. Санитайзеры работают в отладочной сборке, часть проверок включается вручную, поэтому смотреть навигатор проблем нужно до отправки сборки в магазин.