that works, thanks.

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.

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

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.

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 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?

thanks, this helped

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?

did you get a solution to this?