iOS Developer Library


Core Data Framework Reference NSManagedObjectModel Class Reference

Deployment Target:

On This Page


An NSManagedObjectModel object describes a schema—a collection of entities (data models) that you use in your application.

The model contains one or more NSEntityDescription objects representing the entities in the schema. Each NSEntityDescription object has property description objects (instances of subclasses of NSPropertyDescription) that represent the properties (or fields) of the entity in the schema. The Core Data framework uses this description in several ways:

  • Constraining UI creation in Interface Builder

  • Validating attribute and relationship values at runtime

  • Mapping between your managed objects and a database or file-based schema for object persistence.

A managed object model maintains a mapping between each of its entity objects and a corresponding managed object class for use with the persistent storage mechanisms in the Core Data Framework. You can determine the entity for a particular managed object with the entity method.

You typically create managed object models using the data modeling tool in Xcode, but it is possible to build a model programmatically if needed.

Loading a Model File

Managed object model files are typically stored in a project or a framework. To load a model, you provide an URL to the constructor. Note that loading a model doesn’t have the effect of loading all of its entities.

Stored Fetch Requests

It is often the case that in your application you want to get hold of a collection of objects that share features in common. Sometimes you can define those features (property values) in advance; sometimes you need to be able to supply values at runtime. For example, you might want to be able to retrieve all movies owned by Pixar; alternatively you might want to be able to retrieve all movies that earned more than an amount specified by the user at runtime.

Fetch requests are often predefined in a managed object model as templates. They allow you to pre-define named queries and their parameters in the model. Typically they contain variables that need to be substituted at runtime. NSManagedObjectModel provides API to retrieve a stored fetch request by name, and to perform variable substitution—see fetchRequestTemplateForName: and fetchRequestFromTemplateWithName:substitutionVariables:. You can create fetch request templates programmatically, and associate them with a model using setFetchRequestTemplate:forName:; typically, however, you define them using the Xcode design tool.


Sometimes a model—particularly one in a framework—may be used in different situations, and you may want to specify different sets of entities to be used in different situations. There might, for example, be certain entities that should only be available if a user has administrative privileges. To support this requirement, a model may have more than one configuration. Each configuration is named, and has an associated set of entities. The sets may overlap. You establish configurations programmatically using setEntities:forConfiguration: or using the Xcode design tool, and retrieve the entities for a given configuration name using entitiesForConfiguration:.

Changing Models

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 Core Data Model Versioning and Data Migration Programming Guide). 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.

Editing Models Programmatically

Managed object models are editable until they are used by an object graph manager (a managed object context or a persistent store coordinator). This allows you to create or modify them dynamically. However, once a model is being used, it must not be changed. This is enforced at runtime—when the object manager first fetches data using a model, the whole of that model becomes uneditable. Any attempt to mutate a model or any of its sub-objects after that point causes an exception to be thrown. If you need to modify a model that is in use, create a copy, modify the copy, and then discard the objects with the old model.

Fast Enumeration

In OS X v10.5 and later and on iOS, NSManagedObjectModel supports the NSFastEnumeration protocol. You can use this to enumerate over a model’s entities, as illustrated in the following example:

  1. NSManagedObjectModel *aModel = ...;
  2. for (NSEntityDescription *entity in aModel) {
  3. // entity is each instance of NSEntityDescription in aModel in turn
  4. }
  • The localization dictionary of the receiver.



    var localizationDictionary: [String : String]?


    @property(strong) NSDictionary <NSString *,NSString *> *localizationDictionary


    Table 1 describes the key and value pattern for the localization dictionary.

    Table 1Key and value pattern for the localization dictionary.













    (1) For properties in different entities with the same non-localized name but that should have different localized names.

    Special Considerations

    On OS X v10.4, localizationDictionary may return nil until Core Data lazily loads the dictionary for its own purposes (for example, reporting a localized error).


    Available in iOS 3.0 and later.

  • Returns a Boolean value that indicates whether a given configuration in the receiver is compatible with given metadata from a persistent store.



    func isConfiguration(_ configuration: String?, compatibleWithStoreMetadata metadata: [String : AnyObject]) -> Bool


    - (BOOL)isConfiguration:(NSString *)configuration compatibleWithStoreMetadata:(NSDictionary<NSString *,id> *)metadata



    The name of a configuration in the receiver. Pass nil to specify no configuration.


    Metadata for a persistent store.

    Return Value

    YEStrue if the configuration in the receiver specified by configuration is compatible with the store metadata given by metadata, otherwise NOfalse.


    This method compares the version information in the store metadata with the entity versions of a given configuration. For information on specific differences, use entityVersionHashesByName and perform an entity-by-entity comparison.


    Available in iOS 3.0 and later.

  • A dictionary of the version hashes for the entities in the receiver, keyed by entity name. (read-only)



    var entityVersionHashesByName: [String : NSData] { get }


    @property(readonly, copy) NSDictionary <NSString *,NSData *> *entityVersionHashesByName


    The dictionary of version hash information is used by Core Data to determine schema compatibility.


    Available in iOS 3.0 and later.

  • The set of developer-defined version identifiers for the receiver.



    var versionIdentifiers: Set<NSObject>


    @property(copy) NSSet *versionIdentifiers


    Merged models return the combined collection of identifiers. The Core Data framework does not give models a default identifier, nor does it depend this value at runtime. For models created in Xcode, you set this value in the model inspector.

    This value is meant to be used as a debugging hint to help you determine the models that were combined to create a merged model.


    Available in iOS 3.0 and later.