I'm referring iOS, but this happens on all platforms and projects. This is a well-known issue that incremental builds using xcodebuild are significantly slower than builds using Xcode. I can't share my projects, but you can easily reproduce it on any Xcode project. I already have a ticket for that: FB15478221. I put there all necessary details to reproduce the issue.

Replied below

I can confirm the trick with recreating records after the sharing is stopped works well. But the error "Invalid Arguments" (12/2006); server message = "Only shared zones can be accessed in the shared DB"; op = EB5068F104AA2536; is generated always when the sharing is stopped (even without the workaround). Something is broken with the SDK.

I think users will blame me, not Apple for wiping out their data :D. That's the problem.

Yes, I think your scenario is correct. I think it is a bug that after sharing is stopped records are not moved back to the default CoreData zone and the zone is not removed. So the next time I try sharing it, the SDK most likely checks if it's already in a shared zone and tries to share the same zone with other objects as well.The workaround would be to delete shared objects once the sharing is stopped. Then we can recreate them back in the default zone using core data. It's seriously ALPHA ver!

I reproduced this issue several times. A couple of manual changes and the CloudKit sync is dead. The app receives notifications but the scheduler doesn't fetch changes. Not even the app restart helps. After restarting new changes are fetched but it doesn't fetch any new remote updates when the app is in the foreground. Only going background and back triggers the import. Something is seriously broken with the scheduler's stability.

I provided additional logs in the ticket. Basically sysdiagnose logs show that the app/cloudkit receives the push notifications with updates, schedules the import, and then nothing happens until I manually put the app into background and back. Unfortunately, logs don't reveal any information on how the import is scheduled. Unless the "delay" field means how much in the future it is scheduled, in my case it's always 0, so it should be instant. When it's temporarily not broken,it happens instantly

The second link, the chapter "Schedule an import" basically confirms the problem that I described. Still, it's not acceptable that the app stops synchronizing while it's in the foreground. In this case, the user is clearly awaiting the synchronization. Of course, I don't mean some programmatically generated spam of updates. I was testing it manually and manual edits on macOS should be reflected on the iOS side while the app is in the foreground. After a couple of tests, it's heavily throttled.

I had this issue again with Action Extension and Share Extension. I deleted provisioning profiles both on Apple Developer account and on my Mac, toggled CloudKit off & on in Xcode and restarted my iPhone (test device). It helped. Hopefully, it's going to work instantly with the production version.

Otherwise, not even switching keyboards updates the database. Any ideas how to make CloudKit synchronization reliable within the keyboard extension?

Now I don't see the issue with bundle id, but the keyboard doesn't receive automatic updates when the CloudKit database is changed remotely. If the keyboard writes any changes, they are immediately visible on other devices, but it doesn't work vice-versa. I mean sometimes it works, but then it stops. What's even more interesting I discovered, that I can trigger the fetch by showing task manager (swiping bottom bar to see all aps) and going back to the app, the database is immediately fetched.

Does it mean that CloudKit is not supported in extensions like share, action, or keyboard? It would degrade the user experience because the user would have to open the main application to refresh data on the keyboard. I keep getting this error: https://developer.apple.com/forums/thread/760791#760791021

And now it stopped working again... something is smelly with that iCloud sync

I ended up resizing the icon from the template to fill the whole space, without empty paddings, keeping the rounded corners, and now it is perfect :). I also noticed that at least 60%-70% apps on the App Store have the same problem. I guess they all just used the provided template and fell into the same trap as me :). That's why the template should be updated.

Not really, there is also paymium: https://developer.apple.com/app-store/business-models/