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

Нет. Условительное приведение экземпляра класса к типу протокола не создаёт новый объект: оно проверяет соответствие типа протоколу и меняет статический взгляд на тот же экземпляр. Поэтому изменения через исходную ссылку и через значение протокольного типа видны в одном объекте.

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

В Swift протоколы позволяют отделить интерфейс объекта от его конкретного класса. Для этого значение можно представить через existential-тип, например any Identifiable, скрыв конкретную реализацию от вызывающего кода.

Такой механизм нужен для полиморфизма: код работает с требуемыми возможностями, не завязываясь на конкретный класс. При этом переход к протокольному представлению не должен неожиданно менять идентичность ссылочного объекта.

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

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

На практике это опасно при передаче делегатов, моделей и объектов, состояние которых изменяется через разные протокольные представления. Условное приведение может завершиться nil, если динамический тип не соответствует протоколу, но успешное приведение не отделяет объект от исходной ссылки.

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

Оператор as? во время выполнения проверяет, реализует ли динамический тип объекта нужный протокол. При успехе Swift формирует значение протокольного типа, ограничивая доступный интерфейс требованиями этого протокола.

Для экземпляра класса сохраняется ссылка на тот же объект. Не вызываются конструктор, копирующий метод или пользовательское преобразование; меняется только статический тип значения, через который объект виден вызывающему коду.

protocol Switchable {
    var isOn: Bool { get set }
}

final class Lamp: Switchable {
    var isOn = false
}

let lamp = Lamp()
let device = lamp as? any Switchable
device?.isOn = true

print(lamp.isOn) // true

В примере lamp и device обращаются к одному экземпляру Lamp. При этом через device доступны только возможности, описанные Switchable; специфичные методы и свойства Lamp без обратного приведения недоступны.

Это отличается от приведения значения-структуры к протокольному типу: структура сохраняет value semantics, поэтому операции над извлечённым или скопированным значением не означают совместное изменяемое состояние, как у класса. Также as? не гарантирует успех: результатом является Optional протокольного типа.

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

Сервис получает объект UIViewController или доменную модель, которая иногда реализует необязательный протокол делегата. Нужно вызвать протокольный метод, не связывая сервис с конкретным классом.

Можно использовать принудительное приведение as!, но при ошибке конфигурации приложение завершится аварийно. Можно применять условительное приведение as?, получить nil и корректно обработать отсутствие соответствия; это безопаснее, но может скрыть ошибку, если соответствие считалось обязательным.

Выбранное решение — as? для действительно необязательной возможности и явная диагностика отсутствия соответствия. Объект при этом не копируется, поэтому изменения состояния через протокол сохраняются для всех ссылок на этот экземпляр.

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

Вопрос: Что именно ограничивается после приведения класса к протоколу?

Ответ: Ограничивается доступный статический интерфейс, а не сам объект и не его динамический тип. Если объект класса реализует дополнительные методы, они остаются в экземпляре, но недоступны через переменную протокольного типа без обратного приведения.
Вопрос: Может ли успешное приведение к протоколу изменить семантику ссылочного типа на семантику значения?

Ответ: Нет. Если внутри existential-значения находится экземпляр класса, обращения через него сохраняют ссылочную семантику: несколько представлений указывают на один объект. Само протокольное ограничение не превращает класс в независимую копию.
Вопрос: Что произойдёт, если объект класса не соответствует протоколу?

Ответ: Условительное приведение завершится значением nil, то есть результатом типа Optional протокольного типа. Новый объект не создаётся ни при успехе, ни при неудаче; оператор только проверяет совместимость динамического типа с целевым протоколом.