Post

Replies

Boosts

Views

Activity

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?
2
0
140
1w
Crash: Unbalanced call to dispatch_group_leave()
Experiencing an increased amount of crash reports with the latest release of the app. I've spent some time online understanding the meaning of Unbalanced call to dispatch_group_leave() however, I am struggling to pinpoint what's the source of the problem inside the codebase. I wish you can help me with these crash logs. Will calling a closure from inside CoreData context's perform() will eventually result into this crash and cause leave() to get called multiple times? The main code was there for long time, the only recent change was to wrap some code around CoreData context perform() or performAndWait() to avoid concurrency issues. 2023-05-20_10-42-03.5467_+0100-e8b3d9b142b8fd3d11c72abc01ad2fbcfbe92aee.crash 2023-05-22_20-57-32.2620_+0400-5d4c76afe1e42937cf09035d3034fb33ec40f0c9.crash 2023-05-21_19-36-18.3480_+0100-c01f62a2b78cae616c6202940f06220b7ea3b760.crash 2023-05-16_15-29-43.3962_+0100-ebb44a6156a3771271acfdd459546fe1271eb370.crash
1
0
1.4k
May ’23
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?
Replies
2
Boosts
0
Views
140
Activity
1w
Crash: Unbalanced call to dispatch_group_leave()
Experiencing an increased amount of crash reports with the latest release of the app. I've spent some time online understanding the meaning of Unbalanced call to dispatch_group_leave() however, I am struggling to pinpoint what's the source of the problem inside the codebase. I wish you can help me with these crash logs. Will calling a closure from inside CoreData context's perform() will eventually result into this crash and cause leave() to get called multiple times? The main code was there for long time, the only recent change was to wrap some code around CoreData context perform() or performAndWait() to avoid concurrency issues. 2023-05-20_10-42-03.5467_+0100-e8b3d9b142b8fd3d11c72abc01ad2fbcfbe92aee.crash 2023-05-22_20-57-32.2620_+0400-5d4c76afe1e42937cf09035d3034fb33ec40f0c9.crash 2023-05-21_19-36-18.3480_+0100-c01f62a2b78cae616c6202940f06220b7ea3b760.crash 2023-05-16_15-29-43.3962_+0100-ebb44a6156a3771271acfdd459546fe1271eb370.crash
Replies
1
Boosts
0
Views
1.4k
Activity
May ’23