Hi, I’m seeing WeatherKit fail on device with a JWT permission error even though the app appears to be signed correctly with the WeatherKit entitlement. Error: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Setup verified: iOS physical device, tested after clean install/reboot Tested on more than one physical device Bundle ID: com.elilindenDinematch.Al-Outfits Team ID: FYGW4LHN42 App ID has WeatherKit capability enabled Fresh provisioning profile includes: application-identifier = FYGW4LHN42.com.elilindenDinematch.Al-Outfits com.apple.developer.team-identifier = FYGW4LHN42 com.apple.developer.weatherkit = true Signed app binary entitlements also include com.apple.developer.weatherkit = true codesign -dv confirms TeamIdentifier=FYGW4LHN42 Cleared DerivedData and regenerated/reinstalled with a fresh profile Toggled WeatherKit capability off/on in Developer portal and regenerated profile The failure occurs when calling: let weather = try await WeatherKit.WeatherService.shared.weather(for: location) The request takes a few seconds before failing, which makes it seem like the WeatherKit daemon is reaching Apple’s auth service but being rejected during JWT generation. Has anyone seen WeatherKit entitlement propagation get stuck server-side for a specific Team ID + Bundle ID? Is there anything else I can verify locally, or does this require Apple to inspect the WeatherKit auth service registration for this App ID?

I'm hitting a kernel-side rejection on IOServiceOpen from a host app against my DEXT's IOUserService, before any code in my DEXT's NewUserClient runs. DEXT activation and USB matching succeed; only the user-client connection fails. What works DEXT activates and shows as [activated enabled] in systemextensionsctl list. DEXT matches IOUSBHostInterface for the target device and Start() runs to completion. Inside Start(), CopyInterface() returns successfully and CopyPipe() for the expected endpoints all succeed. Host app receives the matching notification for the DEXT's IOUserService and calls IOServiceOpen(service, mach_task_self(), 0, &connect). What fails IOServiceOpen returns kIOReturnError (0xE00002BC). My DEXT's NewUserClient override is never reached — verified by the absence of any breadcrumb log and by stepping through under lldb (no entry on the DEXT side). This reproduces both with: The original com.apple.developer.driverkit.userclient-access entitlement listing the host bundle ID. The dev fallback com.apple.developer.driverkit.allow-any-userclient-access = true on host + DEXT. (Background: the App ID portal has the bundle-ID list for userclient-access stored as a single newline-joined string instead of separate array entries — see Support Thread 822652 — so I've been using allow-any-userclient-access = true for now. The IOServiceOpen failure persists either way.) Diagnostics I can't get I'd like to confirm the kernel-side rejection reason, but DEXT os_log output is suppressed in Console and: sudo log config --process <dext-pid> --mode "level:debug" log: Unable to set mode for pid <dext-pid> I've tried by PID and by subsystem; both refuse. SIP is in its default state. Any pointer to the correct invocation (or a Configuration Profile to enable DriverKit verbose logging) would unblock me. Environment macOS 26.3.1 (build 25D2128) Xcode 26.3 (build 17C529) Host app: AppKit, sandboxed, Mac App Store distribution DEXT: matches IOUSBHostInterface on idVendor: 0x1452 (DNP) and (pending capability approval) 0x1343 (Citizen) Entitlements on host: com.apple.developer.driverkit, com.apple.developer.driverkit.userclient-access (or allow-any-userclient-access = true for dev) Entitlements on DEXT: com.apple.developer.driverkit, com.apple.developer.driverkit.transport.usb, com.apple.developer.driverkit.allow-any-userclient-access for dev Questions Is IOServiceOpen → kIOReturnError before NewUserClient always an entitlement/sandbox check failure, or are there other kernel-side reasons (matching score, IOService class hierarchy mismatch) that produce the same generic code? What's the correct way to enable DEXT os_log capture so I can see the rejection reason? Is there a known interaction between a malformed userclient-access array on the App ID (Forums Thread 822652) and the kernel's user-client authorization path that would persist even after switching to allow-any-userclient-access = true? Sample profiles, codesign output, and the exact matching dictionary available on request. Thanks.

I tried every possible but it just won't work on my device. The program runs well on the simulator by the way

While testing Flutter applications on macOS 26 beta with Xcode 26 beta, iOS builds consistently fail during Flutter.framework codesigning with: "resource fork, Finder information, or similar detritus not allowed" Investigation suggests newer Xcode beta versions now reject additional extended attributes beyond com.apple.FinderInfo during codesigning. Flutter tooling currently removes only: xattr -r -d com.apple.FinderInfo Replacing it with: xattr -cr successfully resolves the issue. Environment: macOS 26.4.1 beta Xcode 26.4.1 beta Apple Silicon (ARM64) Flutter 3.41.9 Flutter issue: https://github.com/flutter/flutter/issues/186372 Apple Feedback Assistant report: FB22756923 Interested to know whether other developers on Xcode 26 beta are seeing similar stricter codesigning validation behavior.

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

Hello Apple Developer Support Team, This is my first app submission. I submitted my app on 18 May 2026, and since then all notarization submissions have remained in “In Progress” for an unusually long period without completing. Environment macOS 26.2 Notarization tool: xcrun notarytool submit Team ID: HRZ4D6R846 Developer ID signing identity is valid and correctly detected Timeline Issue started on 18 May 2026 Multiple submissions have remained in “In Progress” for 24–72+ hours Current count: 3+ submissions stuck in progress Checks already completed Verified the Developer ID Application certificate is valid and properly installed. Verified app signatures using: codesign -vvv --deep --strict Checked Apple Developer System Status, which currently shows all services as operational Re-submitted using fresh builds and credentials, but the behavior remains unchanged Could you please confirm whether there is any known notarization processing issue on Apple’s side during this period, and advise on the following: How to unblock the currently stuck submissions Whether the “In Progress” submissions should be cancelled and re-submitted Thank you for your assistance. Best regards, Rishikesh Galande

Hello, Adding our case to the long-running thread on this issue (https://developer.apple.com/forums/thread/118465). Our team is the latest to be hit by statusCode 7000 "Team is not yet configured for notarization", and we'd like to (a) document the data points in case it helps Apple correlate cases and (b) ask the community whether anyone has seen a faster resolution path than what's been reported here over the past 6 years. Our situation Team ID: A92X4FJ5HU Last successful notarization: 2026-05-18 11:23:26 UTC First rejection: 2026-05-18 17:19:15 UTC (~6 hours later, no apparent trigger on our side) Total rejections since: 22 submissions across 9 days, 100% rejected with statusCode 7000 Open support case: 102900780153 What we have already verified Apple Developer Program membership Active (Renewal Sept 17, 2026) Apple Developer Program License Agreement: Accepted Apr 15, 2026 Free Apps Agreement: Active (Apr 15, 2026 — Sept 16, 2026) Paid Apps Agreement: Active (Mar 17, 2026 — Sept 16, 2026) Banking and tax information complete Developer ID Application certificate valid (notBefore 2025-10-12, notAfter 2027-02-01) What we tested Variable Result API key A (Admin role, created 2025-10) Rejected, statusCode 7000 API key B (Admin role, created 2026-05-22) Rejected, statusCode 7000 Same Issuer ID, both keys Same rejection Bundle ID com.matrixai.app (one product) Rejected Bundle ID com.flowith.os.beta (different product) Rejected Locally-rebuilt clean DMG Rejected Pre-existing already-signed DMG Rejected The rejection happens server-side after upload completes — authentication, signing, hardened runtime, and timestamp are all confirmed correct (codesign verifies cleanly, both keys authenticate). The submission is accepted by the notary service, then rejected with statusCode 7000 after a few minutes of "In Progress". Sample submission IDs (all rejected, statusCode 7000) ac52531f-1b9e-4210-8123-54afea90f66f (2026-05-27 10:20 UTC) baba6420-e245-4597-b229-ec5af4b309c5 (2026-05-27 10:23 UTC) 72118f71-9f1d-4ce9-8068-3eca5017104d (2026-05-27 09:49 UTC) Question to the community I've read this entire thread (all 4 pages, 6 years of reports) and the related threads (749857, 813624, 825906, 827589, 130479, 130494, 741721, 809228). The consistent answer from DTS is "this is a Developer Program Support issue, escalate via official channels", but the threads also document wait times of 1 day to 3+ months with no SLA and no transparency. A few questions: Has anyone in 2025 or 2026 had this resolved in under 2 weeks? If yes, what (if anything) on your side accelerated it? Did anyone identify a specific account-level signal (recent agreement re-acceptance, banking change, AppID/Bundle ID conflict, recent role/Account Holder change, recent device verification, etc.) that correlated with the trigger date? Is there any escalation path beyond Case → DPS → "engineers are working on it" loop? Several users on this thread report 39 days, 3 months, 4 separate cases — and DPS still cannot give an ETA. I understand the official answer is "wait for Developer Program Support". Posting this here primarily so Apple has more correlated data points for the engineering team that owns notarization, and so other developers who hit this in the future can find one more datapoint. Thanks.