did you get a solution to this?

have since had the opposite issue in ios17.5.1. had to remove all the .id()'s and only then it would work. maybe its fixed now?

thanks, this helped

I mean if I have 1 thread using await context.perform and another using context.performAndWait accessing the same core data object on the same context, will I get the concurrency issues that they are supposed to stop?

my understanding is the old performAndWait uses GCD and that we shouldn't be mixing the new swift concurrency model with gcd? So ive been migrating all my 'performAndWait' code over to swift concurrency. Does 'context.performAndWait' and 'await context.perform' play well together? if so no problem using performAndwait in body. Using 'await perform' in .task{} gives the warnings. I have SWIFT_STRICT_CONCURRENCY set to complete. and the com.apple.CoreData.ConcurrencyDebug complier flag set to 1.

I get the following warnings with this code (I put the func in a View) in Version 15.0.1 (15A507), iOS17.0 target: "Passing argument of non-sendable type '() -> ()' outside of main actor-isolated context may introduce data races", "Passing argument of non-sendable type 'NSManagedObjectContext.ScheduledTaskType' outside of main actor-isolated context may introduce data races". I have SWIFT_STRICT_CONCURRENCY set to complete. and the com.apple.CoreData.ConcurrencyDebug complier flag set to 1.

Also NSPersistenCloudContainer chokes if u try and load 500k+ or so records. u need to use CloudKit to manage that manually.

here are the limits I've been able to work out. these change but here's what im currently seeing. Batch sizes are limited to 400 records per batch update. You can send 40 requests per second. But there are some other limits so you can't do it sustained. For large loads, I've had best results by queuing requests so the next one isn't send till the previous one is successful. Ends up being about 1 batch request every 13 seconds sustained for records with a small amount of data in each.

that works, thanks.

further on this. I was able to stop the freezing on all of my use cases now with .id(UUID()). needed it on all NavigationLinks and some Lists where there was still freezing. not a full fix because setting .id(UUID()) on a List makes it reload every time it appears which is annoying for users when the list takes time to reload (as in my case). a couple of NavigationLinks needed a static id like .id("someid"), some needed .id(UUID()). not sure why. hopefully gets fixed in the sdk as some point.

effort sounds about right for someone who can already develop swift macOS apps. Some of those requirements are quite involved, and at first glance may only be possible (or not possible) with some cutting edge research/tech and may take significantly longer than expected as far as effort goes. If u want corporate style governance, you will need to pay corporate style prices if anyone is going to do that.

dont really need a server. can use CloudKit for this

same issue here in iOS16 RC

on FB10392936 they asked for some more info, but closed it before I could get the info for them - I had to run the process again - it takes a couple of weeks to run (hence the problem), before it corrupts the CloudKit db. ive updated it with the info they requested. any chance we can get it reopened?

thanks. I ended up implementing a custom queue in the first actor to manage and queue the 'async' calls to the second actor. A decent amount of code, would be nice if actors had some standard functionality to do something like this, as the custom queue has quickly become boilerplate code in almost all of my actors now.