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

dynamic заставляет Swift использовать динамическую диспетчеризацию члена через механизм Objective-C runtime, а не обычный для Swift статически определяемый или табличный вызов. Это позволяет runtime перехватывать, заменять или наблюдать такие методы, но добавляет ограничения совместимости и небольшие накладные расходы.

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

Обычная диспетчеризация Swift оптимизирована под производительность и анализ на этапе компиляции. Однако платформенные механизмы Cocoa, включая KVO, метод-св swizzling и некоторые сценарии Objective-C-совместимости, требуют найти реализацию метода во время выполнения.

dynamic появился как явный способ отказаться от обычного Swift-маршрута вызова там, где необходима работа через runtime. На практике его чаще применяют вместе с @objc и наследованием от NSObject.

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

Если метод объявлен обычным способом, компилятор может использовать прямой или табличный вызов и оптимизировать его, например встроить тело метода. Изменение реализации через Objective-C runtime в таком случае не обязано повлиять на уже скомпилированные Swift-вызовы.

Неправильное применение dynamic ухудшает оптимизируемость и усложняет понимание кода. Само ключевое слово не предназначено для того, чтобы просто разрешить переопределение в подклассе: обычные переопределяемые методы класса и без него используют необходимую для наследования диспетчеризацию.

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

У обычного метода класса Swift выбирает реализацию с учётом статического типа, таблицы виртуальных методов и доступных оптимизаций. При вызове через ссылку на базовый класс переопределение в подклассе обычно всё равно работает, но это не означает, что вызов проходит через Objective-C runtime.

dynamic требует динамического поиска реализации при каждом соответствующем вызове. Поэтому runtime может учитывать замену метода, Objective-C-сообщения и механизмы наблюдения. Член, предназначенный для такого использования, должен быть доступен Objective-C runtime; на практике это выражают атрибутом @objc, который для dynamic обычно подразумевается контекстом языка.

import Foundation

final class Screen: NSObject {
    @objc dynamic func refresh() {
        print("обновление")
    }
}

let screen = Screen()
screen.refresh()

В этом примере refresh зарегистрирован как динамический Objective-C-совместимый метод. Сам результат вызова не меняется, но способ поиска реализации допускает вмешательство runtime.

dynamic не делает метод автоматически переопределяемым: для наследования класс и член должны удовлетворять обычным правилам доступа и override. Кроме того, динамический вызов не отменяет проверку типов и не превращает произвольный Swift-член в универсальный runtime-объект.

Компромисс состоит в выборе между гибкостью и оптимизацией. Для обычной бизнес-логики предпочтительнее стандартная диспетчеризация Swift; dynamic оправдан, когда конкретный API действительно использует Objective-C runtime, KVO, swizzling или совместимый с ним фреймворк.

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

Команде нужно наблюдать изменения свойства модели средствами KVO. Вариант с обычным Swift-свойством может не предоставить Objective-C runtime необходимую информацию, поэтому наблюдение окажется неработоспособным или зависимым от деталей компиляции.

Можно отказаться от KVO и добавить собственный callback: это проще контролировать и лучше соответствует чистому Swift, но требует изменения API и ручного управления подписками. Можно использовать протокол делегата: он типобезопасен, однако обычно поддерживает только одного основного наблюдателя.

Выбран вариант с NSObject и @objc dynamic для небольшого слоя совместимости с Cocoa, а остальная логика оставлена на обычных Swift-протоколах и свойствах. Это ограничивает область runtime-зависимости и сохраняет оптимизации там, где они не нужны.

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

Достаточно ли dynamic для переопределения метода в подклассе?

Нет. dynamic меняет способ диспетчеризации, но не отменяет правила наследования. Метод должен быть доступен для переопределения, а реализация подкласса должна быть помечена override; если член или класс объявлен final, переопределение запрещено.

Всегда ли dynamic нужен для полиморфного вызова через базовый класс?

Нет. Обычные методы классов поддерживают переопределение и динамический выбор реализации в рамках Swift-диспетчеризации. dynamic нужен не для базового полиморфизма как такового, а для гарантированного обращения к runtime-механизму, например при интеграции с Objective-C.

Можно ли применять dynamic к любому Swift-члену, включая структуру?

Нет. dynamic связан с динамической диспетчеризацией членов классов и Objective-C runtime. Структуры и перечисления не являются объектами Objective-C runtime, поэтому такой механизм к ним неприменим; для них используются обычные Swift-вызовы, обобщения, протоколы или замыкания.