Краткий ответ

MainActor.run гарантирует, что переданное замыкание выполнится в изоляции главного актора. Вызывающая задача при необходимости приостанавливается и продолжает работу только после завершения замыкания.

Это гарантия акторной изоляции, а не обещание конкретного потока в терминах языка Swift. Главное следствие — доступ к состоянию, изолированному MainActor, выполняется последовательно относительно других обращений к этому актору.

Исторический контекст

Модель async/await, actors и глобальных акторов появилась в Swift Concurrency, чтобы безопасно координировать асинхронные операции без ручного управления потоками и блокировками. Для UI особенно важно было формально описать правило: изменение интерфейсного состояния должно происходить в единой изоляции главного актора.

MainActor.run решает локальную задачу перехода в эту изоляцию из асинхронного кода. В отличие от неструктурированного запуска отдельной Task, он позволяет дождаться завершения критического участка непосредственно в текущем управлении.

Постановка проблемы

Фоновая задача может получить данные из сети или базы данных, после чего попытаться изменить состояние экрана. Если такое изменение выполняется вне изоляции MainActor, несколько задач могут одновременно обращаться к UI-состоянию, что создаёт гонки данных и нарушает требования UI-фреймворка.

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

Подробное решение

MainActor — это глобальный актор. MainActor.run принимает замыкание, изолированное этим актором, и асинхронно передаёт выполнение в его исполнитель. Если вызывающая задача уже находится в изоляции MainActor, лишнего перехода может не потребоваться.

После await MainActor.run вызывающий код получает результат только после завершения тела замыкания. Поэтому обновление UI и последующая логика в вызывающей задаче имеют определённую последовательность: сначала завершается изолированный участок, затем выполняется следующий оператор.

Минимальный пример:

func updateTitle(_ value: String) async {
    let formatted = value.trimmingCharacters(in: .whitespaces)

    await MainActor.run {
        print("Обновление UI: \(formatted)")
    }

    print("Изолированный участок завершён")
}

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

MainActor.run не превращает длительную работу в безопасную автоматически: если внутри замыкания выполнять тяжёлые вычисления или синхронную блокировку, главный актор будет занят, а UI — терять отзывчивость. Также этот вызов не отменяет родительскую задачу сам по себе; отмена должна учитываться вызывающим кодом или проверяться внутри длительной операции.

Если требуется запланировать независимую операцию без ожидания её завершения, можно создать Task, изолированную MainActor. Но это уже отдельная неструктурированная задача с самостоятельным жизненным циклом, поэтому ошибки, отмену и момент завершения придётся контролировать отдельно.

Ситуация из практики

Экран запускает загрузку профиля в фоновой задаче. После ответа нужно изменить заголовок и индикатор загрузки, но сама загрузка может завершиться уже после ухода пользователя с экрана.

Вариант с прямым изменением UI из фоновой задачи опасен: он нарушает изоляцию главного актора. Вариант с отдельной Task на MainActor позволяет быстро запланировать обновление, но усложняет контроль: операция может выполниться после уничтожения экрана, а её ошибка и отмена не связаны с текущим ожиданием.

Выбор await MainActor.run подходит, когда обновление должно быть частью последовательности текущей операции. Загрузка и подготовка данных выполняются вне главного актора, затем небольшой участок обновления выполняется в его изоляции, после чего вызывающая задача продолжает работу. Это сохраняет безопасность данных и не оставляет бесконтрольной фоновой задачи.

Что кандидаты часто упускают

Гарантирует ли MainActor.run выполнение именно на физическом главном потоке?

Основная гарантия Swift — выполнение в изоляции глобального актора MainActor, а не абстрактное обещание конкретного OS-потока для любого окружения. На платформах Apple MainActor обычно связан с главным потоком UI, но корректный код должен опираться прежде всего на акторную изоляцию и требования конкретного UI-фреймворка.
Чем MainActor.run отличается от создания Task, изолированной MainActor?

MainActor.run является частью текущей асинхронной последовательности: вызывающий код ожидает завершения переданного замыкания и может обработать его результат или ошибку. Новая Task создаёт отдельную неструктурированную задачу; текущая функция не обязана ждать её завершения, а её отмену и ошибки нужно связывать с родительским жизненным циклом вручную.
Можно ли помещать в MainActor.run сетевой запрос или другое длительное ожидание?

Технически асинхронный код может ожидать внутри изолированного контекста, но это обычно плохое решение для UI-слоя. Даже если await освобождает исполнитель на время ожидания, сама логика и доступ к изолированному состоянию становятся частью главного актора. Практичнее выполнить сетевой запрос и подготовку результата вне MainActor, а внутри MainActor.run оставить только короткое обновление состояния.