Same here, all apps in my account.

Same here, since yesterday.

Also filed as FB10058545, but I am hoping that maybe I'm just doing something wrong? I tried adding ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES, that didn't help. It seems that the problem is that libswiftCloudKit.dylib inside a simulator is wrongly linked (while other *.dylib in a same folder are binaries, not links.)

It seems now that even build manually archived on my macbook and uploaded are now stuck on "Processing", so I can't release any new version of app.

Thank you, looking forward to a fix.

Hello, the issue is still happening - here is how it looks: https://imgur.com/a/LmAAdK5 (Note that all phases of archive have finished, and the running time of build (6+ hours) - usual time is 20-30 minutes for a clean build)

Same here, I have decoded the JWT token and ensured it contains the exact same items as the sample token at https://developer.apple.com/documentation/weatherkitrestapi/request_authentication_for_weatherkit_rest_api { "alg": "ES256", "kid": "ABC123DEFG", "id": "DEF123GHIJ.com.example.weatherkit-client" } { "iss": "DEF123GHIJ", "iat": 1437179036, "exp": 1493298100, "sub": "com.example.weatherkit-client" } The key and service id used to work on friday, and then since then I am getting 403 error for every request. The response from WeatherKit API is like this: {"timestamp":"2022-09-13T07:19:17Z","status":403,"error":"Forbidden","message":"Access Denied","path":"/api/v1/availability/47.87/-94.28"} Reported as FB11495570

Thank you! This is it - the problem was that at https://developer.apple.com/account/resources/identifiers/list → my app, I had to check WeatherKit not just in Capabilities tab, but under App Services as well! During the beta I had only Capabilities checked, and that seemed to work until Friday, when apparently the check for App Services was activated. Everything is working now for me :).

iOS 16.0 RTM, still happening with a plain SwiftUI Toggle.

Thank you, I installed the profile, and holding the side buttons caused the watch to lock up for a few seconds (UI stopped responding) and then it restarted - no idea if that is what should happen (latest GM WatchOS 9.1). However, even after an hour on charger, no logs appeared in iPhone analytics settings. I found out though, that the only way of getting the complications to refresh again, was to: Delete all complications of my app from all the watchfaces (!!!) And only then setting them up again. I verified this on two different watches with WatchOS 9.1 (by installing the previous app store version, and then a TestFlight update over that). Without a moment when none of my app's complications aren't active on any of the watchfaces, the new (extensionless) watchfaces won't refresh. Only replacing a single complication for another app's one, and then back, won't help, until I remove all of them at once. You can imagine how thrilled I am to tell this to my users. This is not how a migration should work. Feel free to reproduce this and file a radar, I am not wasting any more of my time with this. I will try tomorrow deleting the whole CLKComplicationDataSource, and trying WidgetKit only. I really hope there is a better migration story there.

Update: From a quick test it seems that ClockKit widgets can't be updated to WidgetKit widgets at all. Even if they share the same kind, the old widget just disappears when updating from a clockkit version to the widgetkit version of the app. I am now making a 'Sorry, you will need to redo all your watchfaces because that's how Apple wants it' update screen.

Same here, this seems to have been happening since the WatchOS 9 release for StoreKit 1 API, but today I finally diagnosed it. When ran in a debug build on a real WatchOS 9.1 watch, this is the error message: 2022-11-18 22:47:26.140173+0900 Weathergraph Watch Extension[438:63411] <SKReceiptRefreshRequest: 0x16515030>: Finished refreshing receipt with error: Error Domain=ASDErrorDomain Code=507 "Invalid container for application: file:///private/var/containers/Bundle/Application/4D199ED0-A419-44DD-BAB6-4C418926BD30/Weathergraph.app/PlugIns/Weathergraph%20Watch%20Extension.appex/" UserInfo={NSDebugDescription=Invalid container for application: file:///private/var/containers/Bundle/Application/4D199ED0-A419-44DD-BAB6-4C418926BD30/Weathergraph.app/PlugIns/Weathergraph%20Watch%20Extension.appex/, AMSServerErrorCode=0}

I added my info to FB11788741 (StoreKit 1 seems broken on WatchOS 9 & 9.1 - all purchase restores fail with StoreKit error 0) I sent previously.

Meanwhile I had to add this workaround for broken product purchase/restore on the watch: do the purchase or restore on the iPhone that syncs up the purchases to iCloud and later on the restore on the watch also fetches the purchases from the iCloud and uses those I cannot migrate to StoreKit 2, as I have WatchOS 7 and iOS 14 as a baseline.

According to https://speakerdeck.com/kateinoigakukun/the-new-linker-in-xcode-15, it seems that in my case xcode doesn't call the new ld-prime linker, I have no idea why, though.