Post

Replies

Boosts

Views

Activity

New unexpected compile behavior in Xcode 16.3
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?
5
1
292
Apr ’25
NSStagedMigrationManager shortcomings
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!
5
0
308
Feb ’26
UIManagedDocument hangs the main thread
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!
2
0
787
Aug ’23
A glitch with retained view controllers on Catalyst
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.
2
0
429
Feb ’25
UIManagedDocument and Swift 6
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
123
Nov ’25
Archiving Catalyst project that embeds macOS tool
Hi! I have a Catalyst app that embeds command line utility. So the project has two targets: Catalyst target, this target depends on #2 and embeds it into its bundle. macOS target, the command line tool. Both targets have package dependency to the same package. I used this to embed the CMD tool. Everything builds, runs and works fine until I try to archive the project. Archiving stops early with such error: error: Multiple commands produce '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' What I have tried to fix archiving: Changing PkgTestCMD target to be on Catalyst/iOS instead of macOS. This works but I'm not sure how to properly run CMD tool with iOS SDK (if this correct at all): I need the main thread to be 'unblocked' and be active while background tasks exist. Adding an aux framework that act as container for the package. Doesn't work. Splitting targets into different projects, making workspace and cross-project reference. Doesn't work. My understanding is that archiving attempts to produce .o files for both Catalyst and macOS simultaneously, due to PkgTest being Catalyst and PkgTestCMD being macOS targets. How to archive such a project? Is there a way to separate archiving of CMD and main app? Maybe separate .o files into different directories. Simple building and running the project works, why archiving doesn't want to? I have a test project for the issue: PkgTest. main branch is the source project, DepFramework contains attempt #2, Workspace—#3. Thank you!
2
0
155
4w
New unexpected compile behavior in Xcode 16.3
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?
Replies
5
Boosts
1
Views
292
Activity
Apr ’25
NSStagedMigrationManager shortcomings
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!
Replies
5
Boosts
0
Views
308
Activity
Feb ’26
UIManagedDocument hangs the main thread
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!
Replies
2
Boosts
0
Views
787
Activity
Aug ’23
A glitch with retained view controllers on Catalyst
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.
Replies
2
Boosts
0
Views
429
Activity
Feb ’25
UIManagedDocument and Swift 6
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
0
Views
123
Activity
Nov ’25
Archiving Catalyst project that embeds macOS tool
Hi! I have a Catalyst app that embeds command line utility. So the project has two targets: Catalyst target, this target depends on #2 and embeds it into its bundle. macOS target, the command line tool. Both targets have package dependency to the same package. I used this to embed the CMD tool. Everything builds, runs and works fine until I try to archive the project. Archiving stops early with such error: error: Multiple commands produce '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' What I have tried to fix archiving: Changing PkgTestCMD target to be on Catalyst/iOS instead of macOS. This works but I'm not sure how to properly run CMD tool with iOS SDK (if this correct at all): I need the main thread to be 'unblocked' and be active while background tasks exist. Adding an aux framework that act as container for the package. Doesn't work. Splitting targets into different projects, making workspace and cross-project reference. Doesn't work. My understanding is that archiving attempts to produce .o files for both Catalyst and macOS simultaneously, due to PkgTest being Catalyst and PkgTestCMD being macOS targets. How to archive such a project? Is there a way to separate archiving of CMD and main app? Maybe separate .o files into different directories. Simple building and running the project works, why archiving doesn't want to? I have a test project for the issue: PkgTest. main branch is the source project, DepFramework contains attempt #2, Workspace—#3. Thank you!
Replies
2
Boosts
0
Views
155
Activity
4w