CoreData lightweight migration fails on iOS 26 only — "no such column: Z_110GROUPITEMS1"

We've spent several days diagnosing a CoreData migration crash that is iOS 26-specific and reproducible 100% of the time. Posting here in case others have hit this and because we believe it's an Apple bug worth documenting.

Upgrading from our App Store build (CoreData model v10) to our latest TestFlight build (model v11) crashes on iOS 26 with:

NSCocoaErrorDomain / Code 134110 no such column: "Z_110GROUPITEMS1"

The same upgrade path on iOS 17 and iOS 18 works perfectly.

What v10→v11 changes

• Two new entities added alphabetically early in the alphabet

• One new optional boolean attribute on an existing entity

• One new optional to-many relationship on the same existing entity

All changes are lightweight-migration compatible. We use shouldMigrateStoreAutomatically = true and shouldInferMappingModelAutomatically = true

Here's what we observed

Adding two entities alphabetically shifts Z_ENT numbers for all subsequent entities. A central entity (EntityA) moves from Z_ENT 110 (v10) to Z_ENT 112 (v11). It has many-to-many relationships with four other entities (EntityB, EntityC, EntityD, EntityE), all using the same inverse relationship name: groupItems.

Because multiple join tables reference EntityA via the same inverse name, CoreData appends a disambiguation suffix (1, 2, etc.) to column names in each join table. In v10, the relevant join tables are Z_110ENTITYB and Z_110ENTITYC, each with a column named Z_110GROUPITEMS + a suffix.

-com.apple.CoreData.SQLDebug 3 prints:

ALTER TABLE Z_112ENTITYB RENAME COLUMN Z_110GROUPITEMS1 TO Z_112GROUPITEMS1

But the actual column in a fresh iOS 26 v10 store is Z_110GROUPITEMS2. Column not found → crash.

iOS 17/18 is consistent: both code paths use suffix 1 for Z_110ENTITYB and 2 for Z_110ENTITYC. Migration succeeds.

To confirm

We opened the SQLite store from a fresh iOS 26 v10 install and inspected the schema:

CREATE TABLE Z_110ENTITYB (
    Z_110GROUPITEMS2 INTEGER,
    Z_112ENTITYB INTEGER,
    PRIMARY KEY (Z_110GROUPITEMS2, Z_112ENTITYB)
);

Then we manually renamed Z_110GROUPITEMS2 → Z_110GROUPITEMS1 and Z_110ENTITYC.Z_110GROUPITEMS1 → Z_110GROUPITEMS2 in the SQLite file. Re-ran the app — migration succeeded.

The suffixes are literally swapped between what iOS 26 creates on fresh install vs. what iOS 26's migration engine expects.

Our database has over 50 entities and we never before faced such an issue. This is not the first lightweight migration we are releasing after iOS 26 and that's what puzzled us. Why now?