WeatherKit JWT token generation fails with WDSJWTAuthenticator Code=2 despite correct entitlement

Question

Created 2w

Replies 2

Boosts 0

Participants 3

I enabled the WeatherKit capability on my App ID (com.saimcan.darkweather, Team 6SWSD6V4ZC) about 12 hours ago. The entitlement is embedded in the binary and the provisioning profile authorizes it, but every request fails at the JWT generation step.

Error from the logs:

Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)"

Relevant log excerpt (iOS 26.4 Simulator, same result on a physical device):

[AuthService] Calling process is 3rd party process and has the correct entitlement ... accepting the connection
[AuthService] Received proxy request for generating a jwt token. url=https://weatherkit.apple.com
[WeatherDataService] Starting to generate JWT token request. bundleIdentifier=com.saimcan.darkweather
[AuthService] Signed successfully
[WeatherDataService] Make new JWT token request. requestIdentifier=...
[AuthService] Failed to generate jwt token ... Code=2

What I have verified:

Active Apple Developer Program membership (renewed through April 2027)
All agreements accepted
WeatherKit capability enabled on the App ID
codesign -d --entitlements confirms com.apple.developer.weatherkit in the built binary
embedded.mobileprovision also includes com.apple.developer.weatherkit
App Group (group.com.saimcan.darkweather.shared) correctly bound to both the app and widget App IDs

Since "Signed successfully" is logged, the device-side auth plumbing is working. The rejection appears to be server-side. Could someone from the WeatherKit team check whether JWT minting is enabled for this Team ID / Bundle ID?

Team ID: 6SWSD6V4ZC Bundle ID: com.saimcan.darkweather

Boost

Answer 1

zhihong-tang OP

6d

+1, hitting the exact same issue with a different Bundle ID and Team:

Bundle ID: com.clearsky.BabyJournal
Team ID: 333T6GHJA9
Started: ~36 hours ago, after changing DEVELOPMENT_TEAM and rebuilding with -allowProvisioningUpdates

Same symptoms as OP:

[AuthService] Calling process is 3rd party process and has the correct entitlement ... accepting the connection
[WeatherDataService] Starting to generate JWT token request. bundleIdentifier=com.clearsky.BabyJournal
[AuthService] Signed successfully
[AuthService] Failed to generate jwt token ... Code=2

Tested 5 times across 19+ hours. Every test produces an identical HTTP 401 from weatherkit.apple.com/v3/token with Content-Length: 0 and upstream code 40100. Only the CDN edge node varies (load balancing) — every other dimension of the response is identical, which strongly suggests a stable backend deny rule rather than a transient issue or in-progress propagation.

I have verified all 5 client-side layers are correct:

project.yml DEVELOPMENT_TEAM = 333T6GHJA9 ✓
.entitlements declares com.apple.developer.weatherkit = true ✓
Embedded provisioning profile contains <key>com.apple.developer.weatherkit</key><true/> (verified via security cms -D -i) ✓
codesign -dvv shows TeamIdentifier=333T6GHJA9 ✓
JWT request payload bundleIdentifier=com.clearsky.BabyJournal (captured from unified log) ✓

I also tried the standard Capability toggle remediation (uncheck → Save → re-check → Save) twice, including a two-round version. No effect — backend still returns the same 401 19+ hours later.

Sample requestIdentifier: 5377094B-9161-450A-AE56-0CA837CC2666 (May 7, 11:06 UTC+8)

This appears to be more than a single phantom reject — multiple developers seeing the identical pattern (you 2 weeks ago, me yesterday) suggests a systemic issue with newly-enabled WeatherKit Capabilities not being properly registered in the backend entitlement DB, possibly triggered by recent changes to the WeatherKit auth backend.

Could anyone from Apple WeatherKit or DTS look into this? Happy to provide additional diagnostic data (full unified log, more requestIdentifiers, codesign output) if helpful.

1

Answer 2

philipto OP

2d

I have the same issue right now. I enabled WeatherKit several days ago, and it still doesn't work.

0