Post not yet marked as solved
If you build an app using Xcode and the app can write to iCloudDrive, then it will have it's own record in in the list. It will does not use the Xcode one.
I am not aware of specific new problems with Catalina but it is important to be realistic about the situation before Catalina.
I have worked with xcode projects on iCloud for some time. It is a perfectly reasonable way of continuously duplicating a project that you are working on to an offsite location and particularly useful when traveling and wanting a backup of your changes on storage that isn't travelling with you.
But it is insane to imagine that you can edit the project on multiple machines without breaking something. Though you may get away with it for a while, particularly if the machines are always likely to be fully synced before a change is made.
Sorting out incompatible changes made to two source copies and then synced together is not something that iCloud Drive or any other distributed file system can do. That is what GIT and a skilled GIT user are for. And to make it worse if you are using GIT you are not just corrupting your project structure and content by syncing together two incompatible sets of changes to both the product structure and the source files, but you are syncing together two incompatible sets of changes to the GIT representation too.
"Likely to be fully synced..." can only mean that you are likely to get away with it for a while. Do it for long enough and it will bite your leg off.
Post not yet marked as solved
Because it implies deleting data from other people's iCloud accounts.However IF, and it's a big IF, you could be confident that ALL data had been deleted by all users THEN it might be reasonable for you to be able to delete the container.
Thanks enormously.I am indeed watching changes in contentOffset. The pointer to scrollViewDidScroll() makes a lot of sense.
OK, this solved by problem but tylerf's post below is clearly pretty much definitive.
I have posted a reply above but am replying separately to your "same problem" because I would be interested to know whether my solution solves the problem for you, since it relies on a reasonable but undocumented side effect.
UITableView beginUpdates / end updates is not documented as a locking mechanism but one of grouping updates for smooth animation.Despite that, it appears that it does some locking.Although my code is making no changes, accessing the value of visibleCells, wrapping the code in a beginUpdates / endUpdates pair allows it to complete without the "Attempted to access the table view's visibleCells while they were in the process of being updated" error.
UITableView beginUpdates / end updates is not documented as a locking mechanism but one of grouping updates for smooth animation.Despite that, it appears that it does some locking.Although my code is making no changes, accessing the value of visibleCells, wrapping the code in a beginUpdates / endUpdates pair allows it to complete without the "Attempted to access the table view's visibleCells while they were in the process of being updated" error.
