I confirmed on real device that this issue is reproducible using the sample project I included. This is a pretty nasty bug because it means that localization doesn’t work at all for widget configuration intents.

Another thing that proves it's watchOS bug - when you open the same widget configuration intent from Watch app on iOS, it displays texts correctly, but when you open that intent on watchOS it shows either localization keys or default/fallback value if provided.

I created a DTS ticket: 19597420. I think it's watchOS bug, there isn't much you can do wrong here - you just provide a localization key and add it in "xcstrings" file, just like all other translations in the app. And it works in the simulator, but for some reason the real device can't see translations inside the widet configuration intent. Maybe there is something wrong with the "Archive" step and it's not really about simulator vs real device.

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!