It seems to me that NSStagedMigrationManager has algorithmic issues. It doesn't perform staged migration, if all its stages are NSLightweightMigrationStage. You can try it yourself. There is a test project with three model versions V1, V2, V3, V4. Migrating V1->V2 is compatible with lightweight migration, V2->V3, V3->V4 is also compatible, but V1->V3 is not. I have following output: Migrating V1->V2, error: nil Migrating V2->V3, error: nil Migrating V3->V4, error: nil Migrating V1->V3, no manager, error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V3, lightweight[1, 2, 3], error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V3, lightweight[1]->lightweight[2]->lightweight[3], error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V3, custom[1->2]->lightweight[3], error: nil Migrating V1->V3, lightweight[1]->custom[2->3], error: nil Migrating V1->V3, custom[1->2]->custom[2->3], error: nil Migrating V1->V4, error: Optional("Persistent store migration failed, missing mapping model.") Migrating V2->V4, error: nil Migrating V1->V4, custom[1->2]->lightweight[3, 4], error: nil Migrating V1->V4, lightweight[3, 4]->custom[1->2], error: Optional("A store file cannot be migrated backwards with staged migration.") Migrating V1->V4, lightweight[1, 2]->lightweight[3, 4], error: Optional("Persistent store migration failed, missing mapping model.") Migrating V1->V4, lightweight[1]->custom[2->3]->lightweight[4], error: nil Migrating V1->V4, lightweight[1,4]->custom[2->3], error: nil Migrating V1->V4, custom[2->3]->lightweight[1,4], error: Optional("Persistent store migration failed, missing mapping model.") I think that staged migration should satisfy the following rules for two consecutive stages: Any version of lightweight stage to any version of lightweight stage; Any version of lightweight stage to current version of custom stage; Next version of custom stage to any version of lightweight stage; Next version of custom stage to current version of custom stage. However, rule 1 doesn't work, because migration manager skips intermediate versions if they are inside lightweight stages, even different ones. Note that lightweight[3, 4]->custom[1->2] doesn't work, lightweight[1,4]->custom[2->3] works, but custom[2->3]->lightweight[1,4] doesn't work again. Would like to hear your opinion on that, especially, from Core Data team, if possible. Thanks!

I open this post to bring attention to overlooked UIManagedDocument. It still marked with @MainActor despite the fact that UIDocument is gonna be nonisolated in iOS 26.1. Here is what we will have with iOS 26.1 (the fix was there since, at least, beta 2): UIDocument was incorrectly annotated to be main actor only. This has been corrected. As a result you might see new warnings or errors show up in your Swift code using UIDocument. (149990945) Seems that UIManagedDocument should also have to be corrected the same way. Otherwise, in Swift 6 we will have crashes. Feedback report for this issue is FB20555456.

I have a macro that converts expression into a string literal, e.g.: #toString(variable) -> "variable" #toString(TypeName) -> "TypeName" #toString(\TypeName.property) -> "property" In Xcode 16.3 #toString(TypeName) stopped to work, compilation throws 'Expected member name or initializer call after type name' error. Everything works fine in Xcode 16.2. I tried to compare build settings between 16.2 and 16.3 but haven't noticed differences that may cause this new error. The following works in both Xcode versions: #toString(variable) -> "variable" #toString(\TypeName.property) -> "property" Seems like Xcode tries to compile code that shouldn't be compiled because of macro expansion. Does anybody know what new has appeared in 16.3 and, perhaps, how to fix the problem?

Hello! I discovered a bug on Catalyst about a three years ago but it still seems to be not fixed. My bug report number is FB9705748. The Internet is silent on this so I'm even not sure, perhaps it's only me. So to the problem. When you display UICollectionViewController or UIViewController that contains UICollectionView, interact with the collection view then dismiss the view controller, the displayed view controller isn't released if dismissal is done through navigation bar item. The problem occurs only when the run target is My Mac (Mac Catalyst). Everything is fine when you run on iOS or via My Mac (Designed for iPad). The sample project is uploaded to GitHub. It has a video that shows this strange behavior, see the log for 'deinit' messages. I did have some workaround to fix this but it stops to work, presumable on the new macOS. Also, chances are that it's not only UICollectionView which initiates the glitch, it's just that I only encounter it with collection views.

Under certain circumstances UIManagedDocument blocks the main thread: I encountered this with situation when two different external writers in quick succession request coordinated write on the document’s file. After the 1st writer finishes its work, UIManagedDocument starts the revert process, and if at the same time the 2nd writer requests coordinated write, it seems that the coordinator allows the 2nd writer to begin, but then everything hangs: on Main thread UIManagedDocument waits for coordinated read, while the 2nd writer never reaches its writer block. The problem occurs only on iOS, I get it on iPad. I have a sample project, one of the tests result, spindump from the failed test: https://www.dropbox.com/scl/fo/qm40ano3kz15lucjj1zx3/h?rlkey=2029ge5moou7ghaqqnklsp7us&dl=0 Open the project and start the test on iPad (there is only one test: testExternalWrite), the problem may occur inconsistently. I submitted a report in Feedback Assistant like a month ago—no reaction. If somebody has time to take a look and say something, thank you very much!