WeatherKit JWT auth fails with Code=2 — entitlement confirmed in signed binary, all config verified, persists for weeks

I have a persistent WeatherKit authentication failure that could be server-side JWT minting not being enabled for my App ID. Every WeatherService.shared.weather(for:) call fails with: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" The console shows the request reaching Apple's auth service and failing only at the JWT generation step. Account / app:

Team ID: 634Q7K5DN8 Bundle ID: com.davidfrauenhofer.TripVault App: shipping on the App Store (this is an update adding a WeatherKit forecast) Device: iPhone 13 Pro, physical device (not simulator) Signing: Xcode automatic

Everything I've verified locally:

codesign -d --entitlements - on the installed binary confirms com.apple.developer.weatherkit = true, with application-identifier = 634Q7K5DN8.com.davidfrauenhofer.TripVault and matching com.apple.developer.team-identifier. WeatherKit is enabled on the App ID under both the Capabilities and App Services tabs, saved and confirmed. App ID Prefix equals my Team ID (634Q7K5DN8) — no legacy prefix mismatch. Fresh provisioning profiles downloaded; clean build folder; app deleted and reinstalled. Active Apple Developer Program membership; no pending agreements in App Store Connect. Valid coordinates passed (confirmed in logs). This has persisted for several weeks across many rebuilds and reinstalls so i should have cleared any propagation windows.

Request to the WeatherKit team: Could someone verify whether JWT minting is enabled server-side for this Team ID / Bundle ID, and whether there is a stuck or incomplete WeatherKit registration for this App ID? Given the entitlement is confirmed present in the signed binary and all client-side configuration is correct, I believe this requires inspection of the auth-service registration on Apple's side. Happy to provide any additional logs or identifiers.

Answered by DTS Engineer in 898191022
the new project works.

OK, cool.

I don’t see any difference between your two App IDs (634Q7K5DN8.com.davidfrauenhofer.TripVault which in NG, 634Q7K5DN8.com.hof.WeatherTest which is OK) from my view of our systems. I’m not sure why WeatherKit is failing in the NG case. I’m gonna recommend that file a bug about this.

Once you’re done, post your bug number and I’ll do some more digging.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Same here. I'm certain it's nothing on my end.

The vast majority of WeatherKit authentication issues I see are caused by folks failing to enable the WeatherKit app service on their App ID. See this post.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn. I have both enabled — WeatherKit is checked under both the Capabilities tab and the App Services tab on the App ID (com.davidfrauenhofer.TripVault, Team 634Q7K5DN8), saved and confirmed. I'd verified this before posting. To rule out the client side entirely, codesign -d --entitlements - on the installed binary confirms com.apple.developer.weatherkit = true, with application-identifier = 634Q7K5DN8.com.davidfrauenhofer.TripVault and matching team-identifier. Fresh provisioning profiles, clean build, deleted/reinstalled on a physical device. App ID Prefix equals the Team ID. This has persisted for several weeks. Given both tabs are enabled and the entitlement is confirmed in the signed binary, is there a way to verify whether JWT minting is actually provisioned server-side for this Team ID / Bundle ID? I'm wondering if there's a stuck or incomplete WeatherKit registration on the backend for this App ID that wouldn't be visible from my side.

Figured i'd attach some screenshots too. I appreciate the help!

Thanks for those screenshots. The state you’re seeing there matches the state I’m seeing in our internal systems, which is good (-:

If you create a new test project, with a different App ID, and enable WeatherKit on that, does it reproduce the problem?

I’m asking this for two reasons:

  • It’ll tell us whether this is an App ID issue or a team issue. I’ve never seen the latter, but I want to rule it out.
  • When you create the test project, you can add the minimum amount of code required to reproduce the issue. That’ll confirm that that this problem has nothing to do with your code.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Great test — the new project works. WeatherTest (bundle ID com.hof.WeatherTest, same team 634Q7K5DN8) fetched weather successfully on the first try on my physical device: "Success: 82.18°F" for the Jackson Hole coordinates. It worked almost immediately, well within any propagation window. Hopefully this helps isolate it. I believe my code is fine and WeatherKit JWT minting works for my team. The failure is specific to the TripVault App ID (com.davidfrauenhofer.TripVault). That one App ID has failed with Code=2 for several weeks despite both tabs enabled and the entitlement confirmed in the signed binary, while a sibling App ID on the same team works instantly. Since you mentioned TripVault's configuration matches what you see in your internal systems, could there be a stuck or incomplete WeatherKit registration on the backend for that specific App ID? Happy to provide anything else useful.

the new project works.

OK, cool.

I don’t see any difference between your two App IDs (634Q7K5DN8.com.davidfrauenhofer.TripVault which in NG, 634Q7K5DN8.com.hof.WeatherTest which is OK) from my view of our systems. I’m not sure why WeatherKit is failing in the NG case. I’m gonna recommend that file a bug about this.

Once you’re done, post your bug number and I’ll do some more digging.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I appreciate the help once again. I just submitted a bug report - FB23888627

Hi Quinn — I'm hitting this exact Code=2 failure, but in my case it looks team-level rather than a single stuck App ID.

Team ID: Q2UJCHMHJ7. In-app WeatherKit (WeatherService.shared.weather(for:)), physical iPhone 14 Pro.

The difference from the original poster: I tested TWO App IDs on my team — com.newtendrelstudios.KazeDiorama (WeatherKit enabled since July 12) and a fresh com.newtendrelstudios.KazeWeather — and BOTH fail with Code=2. I also ran Apple's own sample ("Fetching weather forecasts with WeatherKit," WWDC22 10003), signed with my team and App ID, reduced to a single weather(for:) call, and it fails identically — so it's not my code.

Verified on my side: entitlement com.apple.developer.weatherkit is present in the provisioning profile and in the signed on-device binary (codesign -d --entitlements -); WeatherKit enabled under both Capabilities and App Services, persists across login; App ID Prefix equals the Team ID; membership active; reproduced on cellular with no VPN/Private Relay/custom DNS.

Since even a fresh App ID on this team fails (unlike the sibling that worked here), I suspect a stuck WeatherKit auth-service registration at the team level for Q2UJCHMHJ7. Could you check whether JWT minting is provisioned server-side for this Team ID? I also have Developer Support case 102947846095 open on this, and I've filed FB23939578 with the full details (including a sysdiagnose). Happy to provide logs, identifiers, or a screen recording. Thanks!

AssuredBuyer, I looked at our side of your Q2UJCHMHJ7.com.newtendrelstudios.KazeDiorama App ID and it shows that the App ID has the WeatherKit capability enabled but not the WeatherKit app service. See this post for some screenshots of how things should look at your end.

Please check the app service for Q2UJCHMHJ7.com.newtendrelstudios.KazeDiorama and reply back here with the results.


davidfr22, I’ve no news to share, but rest assured that I haven’t forgotten you.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I appreciate the update nevertheless and the effort/attention. I was able to get weather working on a different app that i'm currently building an update for which is encouraging to know I can get it to work in a real app i've built!

WeatherKit JWT auth fails with Code=2 — entitlement confirmed in signed binary, all config verified, persists for weeks
 
 
Q