There is also a chance that it's not reproducible when running the app from Xcode. My two friends confirmed that this issue occurs in my app but there is a small chance that it happens only when you publish the app. You can check my app: https://apps.apple.com/us/app/smog-poland/id1367444922. WatchOS app is paid (in-app), but you can add widgets without activating the app. If you go to widget configuration you should see the fallback labels in Polish.

Hi, thank you for willing to help! I prepared a minimal project: https://github.com/wojciech-kulik/watchos-localization-issue . My real project is based on xcodegen, so I was able to recreate a very similar structure and dependencies to reproduce my case. However, I don't have Apple Watch, so I can't tell if it is reproducible in this sample project. On simulator it always work well. Please also note that if you open WidgetLocalizable file, you'll see that Xcode marks the text as unused.

I'm glad to hear that it worked for you :)!

Devs experience is unfortunately their lowest priority, so I wouldn’t expect any fix in this matter. For sure not ASAP.

xcrun xccov view --archive --file filepath xctestresultPath

I posted more details here: https://github.com/wojciech-kulik/xcodebuild.nvim/issues/201#issuecomment-2423828065

I found a similar issue: https://forums.developer.apple.com/forums/thread/756120 The full root cause and the workaround are described there... In my case also the problem is with xcodebuild command being stuck for 15-20s on "GatherProvisioningInputs" step.

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.