Explain Copy-on-Write in Swift and implement it for custom structs

WHAT THIS TESTS: This question probes your understanding of value semantics versus reference semantics, and specifically how Swift achieves performant value semantics for large collections. The interviewer wants to see that you know Swift arrays and dictionaries do not copy their entire backing store on every assignment, and that you can manually implement the same optimization for a custom struct that wraps a reference type. It also tests whether you understand the runtime uniqueness check and the thread safety implications of CoW.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, define Copy-on-Write as a strategy where multiple value-typed instances share a reference to a buffer until one mutates it, at which point a real copy is made. Second, explain that Swift collections like Array and Dictionary use a reference-counted buffer and on mutation call isKnownUniquelyReferenced to determine if the buffer has more than one owner. Third, describe the implementation steps for a custom struct: create a private final class to hold the payload, store that reference in the struct, provide reads directly through the reference, and in any mutating method first check isKnownUniquelyReferenced on the backing instance; if it returns false, create a new instance with copied data and assign it before modifying. Fourth, note that this preserves value semantics from the callers perspective while avoiding unnecessary allocations.

COMMON WRONG ANSWERS: A common wrong answer is claiming that all structs in Swift automatically exhibit CoW behavior. In reality, only standard library collections and types you explicitly build do this. Another red flag is forgetting the uniqueness check and mutating the shared reference directly, which corrupts every other value that points to the same buffer. Some candidates also suggest using a struct instead of a class for the backing storage, which defeats the reference sharing mechanism entirely. Finally, mentioning manual retain counts or deep copy on every assignment shows a misunderstanding of the optimization goal.

LIKELY FOLLOW-UPS: The interviewer may ask how CoW interacts with multithreading, specifically that isKnownUniquelyReferenced is only reliable when no other thread could be retaining the object, so you should discuss why mutation and uniqueness checks should happen on the same thread or within proper synchronization. They might also ask for the performance tradeoff, namely that the first mutation after sharing costs O(n) to copy, while subsequent reads and writes on a unique reference are O(1). Another follow-up is asking how to test CoW behavior, such as using withUnsafeMutablePointer or simply observing reference counts and allocation metrics.

ONE CONCRETE EXAMPLE: Imagine a custom struct named Buffer that wraps an array of integers. Inside Buffer you define a final class Storage with a var elements property. The struct holds a private var storage property. A subscript reads storage elements directly. A mutating append method first checks if isKnownUniquelyReferenced returns false on storage; if false, it sets storage to Storage with elements copied from storage elements to detach from any shared reference, then appends. This ensures that var a equals buffer; var b equals buffer; b append one does not mutate a, and no copy occurs until b append is called.