If this is intentional, it’s a really bad decision, I made my own receipt validation just to get rough semi-realtime sales without waiting :/

I am not sure if the problem was ever resolved, but it definitely happens on iOS 18 & macOS Sequoia

It seems that when I build for iOS 14.1, the new linker is not used. I had to switch the project to iOS15+, and then it started linking. EDIT: Nope - once I removed the "-Wl -ld_new" (renamed from -ld_prime) flags to let the Xcode 14 build the project without error, I get "Unknown option: -make_mergeable" error again in Xcode 15 beta 8, suggesting that Xcode 15 for some reason decides to not use the new linker without being forced to :(.

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.

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.

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.

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}

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.

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.

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

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 :).

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

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)

Thank you, looking forward to a fix.

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.