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

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

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

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

Проблема возникает на границе этих моделей: структура может содержать ссылку на экземпляр класса. Внешне копируется значение-структура, но вложенный объект при этом остаётся общим.

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

Предположим, что две копии конфигурации или состояния должны быть независимыми. Если одно из полей структуры — класс, простое присваивание структуры не гарантирует независимость этого поля.

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

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

При копировании структуры Swift копирует каждое её поле согласно семантике этого поля. Значимые типы, например другие структуры и перечисления, копируются независимо. Ссылочные поля копируют ссылку, то есть адрес или логическую ссылку на тот же экземпляр класса.

Следовательно, после копирования структура и её копия независимы как контейнеры: изменение самого ссылочного поля в одной структуре не обязано менять поле в другой. Но изменение внутреннего состояния общего экземпляра класса будет видно через обе структуры.

final class Profile {
    var name: String
    init(name: String) { self.name = name }
}

struct UserState {
    var profile: Profile
}

let first = UserState(profile: Profile(name: "Анна"))
var second = first
second.profile.name = "Ольга"

print(first.profile.name) // Ольга

В примере копируется структура UserState, но first.profile и second.profile указывают на один объект Profile. Если требуется независимое состояние, нужно явно создать отдельный объект или заменить вложенный класс на структуру, когда это соответствует модели данных.

Copy-on-write не возникает автоматически для произвольных классов. Стандартные коллекции Swift могут оптимизировать копирование внутренним разделением хранилища и создавать его копию только перед изменением, но обычное поле-класс такой гарантии не получает.

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

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

В приложении состояние экрана представляли структурой, содержащей класс MutableCache. Разработчик сохранял снимок состояния перед переходом на следующий экран, рассчитывая восстановить прежний кэш независимо от дальнейших изменений. После обновления кэша на новом экране сохранённый снимок тоже менялся.

Рассматривались три варианта:

заменить кэш на структуру. Это делает копирование понятным и безопасным, но может быть невыгодно для большого изменяемого набора данных;
оставить общий класс. Это минимизирует расходы на копирование, но сохраняет общее изменяемое состояние и не подходит для независимых снимков;
реализовать явное копирование или собственную стратегию copy-on-write. Это сохраняет эффективность, но усложняет код и требует корректно синхронизировать момент отделения хранилища.

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

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

Меняется ли сама ссылка при изменении свойства объекта через одну копию структуры?

Нет. В типичном случае меняется состояние общего экземпляра класса, а не ссылка как значение поля. Поэтому другая структура продолжает указывать на тот же объект и видит обновлённое состояние.
Станут ли две структуры независимыми, если заменить ссылочное поле в одной из них?

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

Нет. Константность структуры запрещает изменить её собственные изменяемые поля через это значение, но ссылочный объект имеет отдельную идентичность и может оставаться изменяемым. Чтобы запретить изменение состояния объекта, нужно проектировать сам класс с неизменяемым интерфейсом или использовать другой тип доступа и владения.