Post

Replies

Boosts

Views

Activity

Reply to WeatherKit JWT token generation fails with WDSJWTAuthenticator Code=2 despite correct entitlement
+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.
Topic: App & System Services SubTopic: General Tags:
May ’26
Reply to WeatherKit JWT token generation fails with WDSJWTAuthenticator Code=2 despite correct entitlement
+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.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
May ’26