"Core Data stores are conceptually bound to the managed object model used to create them: since a model describes the structure of the data, changing a model will render it incompatible with (and so unable to open) the stores it previously created. If you change your schema, you therefore need to migrate the data in existing stores to new version."
To further clarify, though:
Since a model describes the structure of the data in a persistent store, changing any parts of a model that alters the schema renders it incompatible with (and so unable to open) the stores it previously created. If you change your schema, you therefore need to migrate the data in existing stores to new version (see Versioning). For example, if you add a new entity or a new attribute to an existing entity, you will not be able to open old stores; if you add a validation constraint or set a new default value for an attribute, you will be able to open old stores.
The simplest case during development is that you start out with a basic model, and incrementally add entities and properties as you go. This is relatively easy to do with the XML store type, since it just means additional entries in the text file.
Although this may be the case at the moment, given the statement above there is no guarantee it will always be true [that you can add to a schema and still read an old XML store].
by mmalc — Nov 16
Versioning
"Core Data stores are conceptually bound to the managed object model used to create them: since a model describes the structure of the data, changing a model will render it incompatible with (and so unable to open) the stores it previously created. If you change your schema, you therefore need to migrate the data in existing stores to new version."
To further clarify, though:
Since a model describes the structure of the data in a persistent store, changing any parts of a model that alters the schema renders it incompatible with (and so unable to open) the stores it previously created. If you change your schema, you therefore need to migrate the data in existing stores to new version (see Versioning). For example, if you add a new entity or a new attribute to an existing entity, you will not be able to open old stores; if you add a validation constraint or set a new default value for an attribute, you will be able to open old stores.
The simplest case during development is that you start out with a basic model, and incrementally add entities and properties as you go. This is relatively easy to do with the XML store type, since it just means additional entries in the text file.
Although this may be the case at the moment, given the statement above there is no guarantee it will always be true [that you can add to a schema and still read an old XML store].