Troubleshooting SwiftData integration

Use the following table to diagnose common BlackBerry Dynamics SwiftData integration problems. Errors use the domain GDEncryptedIncrementalStoreErrorDomain with GDSecureDataStoreErrorCode raw values. Catch uniqueConstraintViolation (10012) and migrationFailed (10010) explicitly when you save or create the container.

Problem

Recommended solution

The app stops responding or displays "No schema registered for entity…" on the first insert

A ModelContainer may have been built directly instead of through the factory. Always use GDSecureModelContainer.create(...). Bypassing the factory produces runtime errors on the first insert and silently ignores any migration plan.

Container creation fails or stops responding at launch

The container may have been created before the BlackBerry Dynamics authorization callback, so the secure container was not unlocked yet. Defer creation until after authorization. See Integrate SwiftData with your BlackBerry Dynamics app.

Schema or model mismatch error at configuration initialization

A @Model type reachable through a relationship may have been omitted from the models: array. List every model type, including relationship targets, or use the versionedSchema: initializer.

migrationFailed (10010) after an app update

A schema change may be too complex for automatic migration. Match the change against the guidance in Considerations for schema migration and add the indicated .custom stage. The underlying Core Data error is in userInfo[NSUnderlyingErrorKey].

uniqueConstraintViolation (10012) on save

A save may have violated @Attribute(.unique) on an update (colliding inserts are merged, not rejected). Resolve the conflict using the values in userInfo: GDUniqueConstraintEntity, GDUniqueConstraintAttributes, and GDUniqueConstraintValues.

ambiguousEntity (10008)

Two schemas that are active at the same time might declare entities with the same name. Prefix entity names per module (for example, MyAppUser and FrameworkUser), or do not keep the conflicting schemas active at the same time. Multiple containers on the same schema do not cause issues.

Queries are slow on large data sets

Review the @Query implementation. Over-fetching, including fetching more than the view needs, is the most common cause and can be addressed with standard SwiftData tuning. If the data set is large and a particular predicate or sort cannot be translated to SQL, SwiftData evaluates it in memory. Results remain correct, but evaluation is slower on large result sets. You can also tune relationshipPrefetchDepth on GDSecureModelConfiguration.

storeNotInitialized (10001)

A method was called on a closed or invalid store. Create the container again.

initializationFailed (10009)

The store could not be opened, or the container was not created through GDSecureModelContainer.create(). Check userInfo[NSUnderlyingErrorKey].

eraseStoreFailed (10011)

eraseStore(storeURL:) could not remove one or more files. Review details in userInfo. Release any live ModelContainer for that URL before calling eraseStore, then try again.