Describe lightweight vs heavyweight Core Data migration and a heavyweight example

WHAT THIS TESTS: This question evaluates whether you understand Core Data schema versioning and the boundary between automatic lightweight migration and manual heavyweight migration. Interviewers want to see that you know the framework can infer simple additive changes but that complex or destructive changes require an explicit mapping model or custom migration policy. They also care whether you recognize the operational cost of heavyweight migrations in production.

A GOOD ANSWER COVERS: First, define lightweight migration as the automatic path enabled by setting NSMigratePersistentStoresAutomaticallyOption and NSInferMappingModelAutomaticallyOption in the persistent store options. This path works when changes are additive and non-destructive, such as adding a new entity, adding an optional attribute, or adding a new optional relationship. Second, define heavyweight migration as any change that Core Data cannot infer automatically, which forces you to create a mapping model in Xcode or implement a custom NSEntityMigrationPolicy subclass. Destructive changes that trigger this include removing an attribute, changing an attribute type, adding a non-optional attribute without a default value, splitting one entity into two, merging entities, or transforming data in a way that requires logic. Third, discuss the practical implications: lightweight migrations run quickly and use little extra space, while heavyweight migrations may effectively duplicate the entire store and should be performed on a background queue to avoid blocking the user interface. Fourth, mention that SwiftData simplifies many migration scenarios but still respects the same underlying rules for complex transforms.

COMMON WRONG ANSWERS: Claiming that renaming an entity or property always requires heavyweight migration. In reality, Core Data supports lightweight renaming via the renamingIdentifier. Saying that adding a new entity or optional field requires heavyweight migration is also incorrect. Another red flag is suggesting you can simply delete the existing store and recreate it in a production app without acknowledging catastrophic data loss. Some candidates also incorrectly state that SwiftData eliminates heavyweight migrations entirely, when in fact complex data transforms still require thoughtful migration strategies.

LIKELY FOLLOW-UPS: How would you execute a heavyweight migration without blocking the main thread? What is a mapping model and how do you create one in Xcode? How do you handle a migration that requires splitting a single entity into two related entities with foreign keys? What performance considerations matter when migrating a store containing ten million records? How do you validate that a migration succeeded before swapping the new store in place?

ONE CONCRETE EXAMPLE: A classic heavyweight scenario is refactoring a Book entity that stores authorName as a string into a schema with a separate Author entity and a relationship. Core Data cannot automatically infer how to turn each unique authorName string into a distinct Author managed object and then wire the relationship from each Book to the correct Author. You must supply a mapping model and likely a custom migration policy that iterates the old Book entities, creates or deduplicates Author objects based on the string value, assigns the relationship, and cleans up the old attribute.