Hello, At work, we want to release a new version of our cross-platform desktop application this week. Unfortunately, I've had issues getting the dmg signed by the Apple notary service, which will delay the release until it's successful. However, I remade and successfully signed the previously released version (also dmg) with the same credentials, so I know it's not a problem with the file format or my account. I have tried the following to no avail: Lots of Googling Running xcrun notarytool submit with the -v option (verbose) to see more error messages Going to the URL given (appstoreconnect.apple.com/notary/v2/submissions/{submission_id}) and examining the file it downloaded (not much info, let alone helpful info) Contacting Apple developer support over the phone (they couldn't help with this particular issue, since it's "code-level support") The only big change we made this time was switching to Maven for our build tool and dependency management (we previously used Ant with manual dependency management). Does anyone here have any insight? Is there a list of known issues or dependencies that will cause a submission to be invalidated? Or, even better, any way to see why the submission is invalid? Thanks.

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires provisioning under an Apple Enterprise Developer account. This introduces considerable operational complexity, as it would require us to maintain separate signing and distribution paths alongside our existing Apple Developer Program membership. Before pursuing that path, we wanted to understand Apple's perspective on the following: Is there a supported or recommended approach for preserving Associated Domains entitlements when an app is re-signed by a third party (e.g., a cloud testing platform)? Are there any provisioning or entitlement configurations that would allow Universal Links to function correctly in re-signed builds without requiring an Enterprise Developer account? Does Apple have documented best practices for validating Universal Link–based flows in automated or cloud-based testing environments? Are there any alternative deep linking patterns that would be more resilient to re-signing while still meeting App Store and platform security requirements? Any guidance or recommendations from Apple on how to handle this within the bounds of the standard Apple Developer Program would be greatly appreciated. Thank you for your time.

We've noticed, that size of our ipa started to vary from time to time. We've found that all the difference was in the LC_CODE_SIGNATURE command under the _LINKEDIT segment of binary. The main reason of that change was the different number of hash slots due to different value of page size: 4096 on macOS SEQUOIA and 16384 on macOS TAHOE. So the size of the final binary was dependent on the machine, it was produced on. I didn't find out any information on why the default page size changed on TAHOE. Apple’s codesign supports a --pagesize argument. For regular builds that setting can be passed via OTHER_CODE_SIGN_FLAGS=--pagesize 16384. But it seems that xcodebuild export ...` completely ignores it: i've tried to pass invalid size (not the power of two), and the export still succeded. I've also managed to get xcodebuild logs via log stream --style compact --predicate 'process == "xcodebuild" OR process == "codesign"' --level trace They have no occurrences of --pagesize: 2026-03-24 13:43:27.236 Df xcodebuild[93993:a08c53] [IDEDistributionPipeline:verbose] invoking codesign: <NSConcreteTask: 0x8a1b21bd0; launchPath='/usr/bin/codesign', arguments='( "-f", "-s", 8C38C4A2CB0388A3DB6BAEFE438F20E044EE6CB2, "--entitlements", "/var/folders/w_/5t00sclx2vlcm4_fvly7wvh00000gn/T/XcodeDistPipeline.~~~T3Dcdf/entitlements~~~c2srXx", "--preserve-metadata=identifier,flags,runtime,launch-constraints,library-constraints", "--generate-entitlement-der", "--strip-disallowed-xattrs", "-vvv", "/var/folders/w_/5t00sclx2vlcm4_fvly7wvh00000gn/T/XcodeDistPipeline.~~~T3Dcdf/Root/Payload/App.app/Frameworks/FLEXWrapper.framework" )'> So here I have some questions: How is the default page size selected? Why the default page size may change between SEQUOIA and TAHOE? How to provide page size to xcodebuild's export or it's a bug that it doesn't look at the value of OTHER_CODE_SIGN_FLAGS?

Hi, I do have a strange behavior in my development environment on a Mac mini (M4) running 26.2 and Xcode 26.3. Everything was working as expected. My project had a stable state and I wanted to enable iCloud support. As result I could not run the app any more because code signing failed with the message that my profile does not include the above entitlement. On my notebook (M2) with XCode 26.3 everything is working. Im am using GIT and both computers have identical code. The code compiling and running on my notebook will not run any more on my Max mini. Any help to find what might have broken the code signing and how it could be fixed? Thanks in advance.

I'm distributing a macOS .pkg installer signed with Developer ID Installer and notarized via notarytool. On macOS 26.3 (Tahoe, Build 25D125), the package is rejected by Gatekeeper when downloaded from the internet. What works: pkgutil --check-signature → signed, Developer ID Installer, full chain (G2 intermediate + Apple Root CA) xcrun stapler validate → "The validate action worked!" xcrun notarytool info <id> → status: Accepted The .app inside the .pkg passes spctl -a -vvv → "accepted, source=Notarized Developer ID" What fails: spctl -a -vvv --type install mypackage.pkg → rejected, origin=Developer ID Installer Raw assessment: assessment:remote = true, assessment:verdict = false Double-clicking the downloaded .pkg shows only "Move to Trash" / "Done" (no "Open" option) syspolicyd log: meetsDeveloperIDLegacyAllowedPolicy = 0 (expected, since the cert is new), but no "notarized" match is logged Certificate details: Developer ID Installer, issued Feb 28, 2026, valid until 2031 OID 1.2.840.113635.100.6.1.14 (Developer ID Installer) — critical OID 1.2.840.113635.100.6.1.33 — timestamp 20260215000000Z Intermediate: Developer ID Certification Authority G2 (OID 1.2.840.113635.100.6.2.6) security verify-cert → certificate verification successful Build process: productbuild --distribution ... --sign <SHA1> (also tried productsign) Both produce: Warning: unable to build chain to self-signed root xcrun notarytool submit → Accepted xcrun stapler staple → worked Workaround: xattr -d com.apple.quarantine ~/Downloads/mypackage.pkg allows opening the installer. Question: Is spctl --type install assessment expected to work differently on macOS 26 Tahoe? The same signing and notarization workflow produces .app bundles that pass Gatekeeper, but .pkg installers are rejected. Is there a new requirement for .pkg distribution on macOS 26? Environment: macOS 26.3 (25D125), Xcode CLT 26.3

I enrolled in the Apple Developer Program as an Individual on March 16, 2026 (Team ID: CAZ8X23YWW). I've been trying to notarize a macOS Electron desktop app ever since. Every submission is immediately rejected with: Status code: 7000 Message: "Team is not yet configured for notarization" What I've done: Accepted all agreements on developer.apple.com Accepted all agreements on App Store Connect Created a Developer ID Application certificate (G2 Sub-CA) App is properly signed with hardened runtime Submitted a support ticket under "Distribution > Other Distribution Questions" on March 18 — no response after 4 days

In my application I validate the authenticity of my own binaries by checking that the Team Identifier in the code signature matches a predefined value. Currently I do not perform a full signature validation that verifies the certificate chain up to Apple’s root CA. When attempting to do this using SecStaticCodeCheckValidityWithErrors (or validateWithRequirement), the operation sometimes takes several minutes. During that time the calling thread appears blocked, and the system logs show: trustd: [com.apple.securityd:SecError] Malformed anchor records, not an array Because of this delay, I decided to rely only on the Team Identifier. My question is: Can it be assumed that if a Mach-O binary contains a Team Identifier in its code signature, then it must have been signed with a valid Apple Developer certificate? Or are there cases where a binary could contain a Team ID but still not be signed by Apple’s trust chain? Thanks for the help !

Sharing a solution for a problem that took me a while to figure out. Problem: During development of a macOS 26 app that uses ScreenCaptureKit, the screen capture permissions were being reset after every build. Each time I compiled and ran the app from Xcode, I had to re-authorize screen capture in System Settings. CGPreflightScreenCaptureAccess() would return false even though I'd just granted permission minutes ago. Root cause: I was using ad-hoc code signing during development. macOS ties screen capture permissions to the app's code signing identity. With ad-hoc signing, the identity changes on every build, so the system treats each build as a "new" app. Solution: Switch to an Apple Development certificate for debug builds. In Xcode: Build Settings → Code Signing Identity → Debug → set to "Apple Development" Make sure your development team is selected After this change, the signing identity remains stable across builds, and screen capture permissions persist. This might be related to the broader issue discussed in this forum about ScreenCapture permissions disappearing — if other developers are seeing permissions vanish, it's worth checking whether the code signing identity is changing between sessions.

Hi there, I signed up for Apple Developer Program a few hours back and am trying to sign and notarize a MacOs App. I am using this command xcrun notarytool history --apple-id "" --password "App-specific-password" --team-id "5XR5PM3Y5S" I keep getting this error. I have verified that the apple-id, password and team-id is accurate. This is surely something on Apple's side. Can you help resolve this ? Error: HTTP status code: 403. Invalid or inaccessible developer team ID for the provided Apple ID. Ensure the Team ID is correct and that you are a member of that team.

Since 2026-03-17 09:06 UTC, all notarization submissions for one of our teams are stuck in "In Progress" indefinitely. Submission logs return "not yet available", indicating Apple's backend has not started processing. Sample submission IDs: 789d40c4-ff83-469f-9b9b-2ac93183125e 2d4685ed-56ac-49db-8e38-63f0b15650c1 5dc3f242-0add-4725-8386-bb32f8383240 18+ submissions affected. Hundreds of successful notarizations before this date with no issues. Please advise or check backend queue status.

My application will create a virtual touchpad. The problem I encountered is: click on the Product menu, select Archives, then select the Distribute App, then click on Drill Distribution, then click on Distribute, and then a prompt appears: Provisioning profile "Mac Team direct Provisioning Profile:"com.xxx.xxx"doesn't match the entitlements file's valuefor the com.apple.developer.driverkit.userclient-access entitlement. But My Identifiers Selected the:DriverKit Allow Any UserClient (development) Do I need toRequest a System Extension or DriverKit Entitlement Select "Virtual HID" in here? https://developer.apple.com/contact/request/system-extension/

Hello, We recently resubmitted our Family Controls (Distribution) request with a much more detailed explanation after our previous declined. Our entire app (including an extension) depends on this capability, and right now we’re completely blocked from launching. Months of work are stuck at this final step and it’s honestly becoming very stressful with no visibility on the timeline. If anyone has experience with the approval timeline after resubmitting, or if someone from Apple could help look into it, it would truly mean a lot. 4C6XLQWZQY Y5JJ7GT6BP 3ZBSC333WU Thank you

Unable to Verify App An internet connection is required to verify trust of the developer "Apple Development: John Doe (ABCXYZ123)". This app will not be available until verified. I've been getting this constantly over the last few weeks. It has been a real struggle to get anything done. Sometimes it goes away on its own after I try to launch the app a few times, but currently it's just staying down and I can't do any work. Apparently there were issues with some Apple server ppq.apple.com before. They seem to be back, because trying again right now: ping ppq.apple.com PING use1-ppq-ext-prod.apple.com (17.33.200.235): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ^C --- use1-ppq-ext-prod.apple.com ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss ping apple.com PING apple.com (17.253.144.10): 56 data bytes 64 bytes from 17.253.144.10: icmp_seq=0 ttl=60 time=9.776 ms 64 bytes from 17.253.144.10: icmp_seq=1 ttl=60 time=8.726 ms ^C --- apple.com ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.726/9.251/9.776/0.525 ms This is incredibly disruptive. Surely there must be a way to disable this online verification? This is a development device that never leaves my desk and never installs any software except the things I build locally from my Mac (which I have trusted on the device).

Yestoday， I got problem createdDate: 2026-03-17T09:06:38.486Z id: d1c679af-5f41-437b-9ca1-4c96047a58fb name: easyclaw.app.zip status: In Progress -------------------------------------------------- createdDate: 2026-03-17T03:30:38.278Z id: fe1bb550-7f42-41c8-8d38-40ac7f9e7c91 name: easyclaw.app.zip status: Accepted And retry today monring，waiting again： Successfully received submission history. history -------------------------------------------------- createdDate: 2026-03-18T02:17:44.322Z id: 141b0dcb-d0fe-464e-9167-3a15e59aec87 name: easyclaw.app.zip status: In Progress

I have been code signing my py2app Python applications for over 5 years. Recently, my application notarizes and staples with no errors. However, when I try to verify the signature I get the above error. I do not see any errors in the appropriate notary log file. Can't figure out how to post the log file. The associated ID is: eb78c6b0-cdd2-414f-9dd3-24315a27d457 Can anyone point me to an appropriate reference ?

I’m looking for guidance from anyone who has experienced a similar situation. I’m a new Apple Developer Program organization member, and this was my first attempt to notarize a macOS app distributed outside the Mac App Store. What happened: My notarization submissions started failing with statusCode 7000 and the message: “Team is not yet configured for notarization.”. I created a support ticket and received the following reply: “We have escalated this issue to our internal team for further investigation and review.” This was more than 2 months ago, and I have not received any further updates since. About 3 weeks later macOS began rejecting my signed app: codesign --verify --deep --strict --verbose=4 succeeds (reports valid signing identity) spctl -a -vv --type exec returns CSSMERR_TP_CERT_REVOKED Around the same time, I also lost access to the Apple Developer portal. When signing in at developer.apple.com/account, I am redirected to the account access support form instead of the dashboard. My app has not been released to users. If there is an issue with my build, signing, entitlements, or packaging, I am fully willing to fix it immediately. What I cannot understand is the lack of any substantive response from Apple Developer Program Support for over 2 months. What I’m trying to understand: Has anyone encountered this combination of issues: statusCode 7000, Developer ID trust/revocation problems, Blocked developer portal access? Is there any documented appeal, review, or remediation process? If Apple believes a team has violated a policy, how is the developer supposed to find out what needs to be fixed? I’m not asking Apple to bypass security checks. I’m asking for a clear explanation and a path to resolve any issue, if one exists. Any help would be greatly appreciated. Thank you.

From what I can tell, it seems that this is something standard that we have to deal with; however, what is annoying and frustrating is I paid good money to have this service work. My application is for important internal use at our company, and this is causing major issues and starting to make me look pretty bad, frankly. On top of that, there is no feedback at all, no reason given. Notarizing darwin binaries... Conducting pre-submission checks for aria.zip and initiating connection to the Apple notary service... Submission ID received id: ec041209-5652-4772-8689-e9e654432da8 Successfully uploaded file id: ec041209-5652-4772-8689-e9e654432da8 path: /Users/shaneholloman/git/sources/uicnz/aria/dist/darwin-arm64/aria.zip Waiting for processing to complete.

Since this evening (March 10, 2026), I'm unable to launch any developer-signed app on my physical device (iPhone 16 Pro Max, iOS 26.4 beta 23E5223k). The error is: "Unable to launch [app] because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user." On the device itself, it shows: "Unable to Verify App - An internet connection is required to verify the trust of the developer." What I've tried: Created a new Apple Development certificate Deleted and reinstalled the app Restarted the device Tested on both Wi-Fi and cellular Confirmed Developer Mode is enabled Removed all third-party CA certificates from the device Verified the code signature is valid (codesign -dv shows correct Authority chain) The root cause: https://ppq.apple.com is currently returning 502 Bad Gateway. I confirmed this both from my Mac (curl -s -o /dev/null -w "%{http_code}" https://ppq.apple.com → 502) and from Safari on the device. This affects all developer-signed apps, not just a specific project. Is anyone else experiencing this? Is there an ETA for the fix? Environment: Xcode 26.3 (17C519) macOS 26.3.1 (25D2128) iPhone 16 Pro Max, iOS 26.4 (23E5223k)

Hello, I am following up on several notarization requests in order to understand the process better. I submitted my first notary request yesterday and it took several hours to complete (where I submitted two other requests along the way thinking they may be stuck). They were all accepted after ~3 hours had passed since the first request was made. In that time I discovered a bug and had to rebuild/codesign, and submitted to notarize again. I've now had two requests with the new build (.zip file) "in progress" for ~18 hours. The bug fix I made between builds was innocuous and I'm wondering if my jobs are getting flagged due to recent account lockouts when I was first setting up my organizations' developer account. I've seen several replies here in the forum from DTS Engineers - hi Quinn :), so I'm aware of the possibility of 'rare' in-depth analysis, however I've experienced it in 100% of my requests. What is causing my requests to always require in-depth analysis and is there anything I can do to prevent it? My notarytool history is below for reference. Thank you in advance. createdDate: 2026-03-15T22:59:23.053Z id: 9c7ecc81-daf4-4cae-afe9-7f8186067f79 status: In Progress -------------------------------------------------- createdDate: 2026-03-15T21:10:04.576Z id: a1df8b50-c897-49f5-ad0d-f2264a03f145 status: In Progress -------------------------------------------------- createdDate: 2026-03-15T20:41:24.946Z id: 640e7cd6-035f-437b-9eab-9a3db415911a status: Accepted -------------------------------------------------- createdDate: 2026-03-15T18:40:26.944Z id: 00b9e907-04eb-4561-8353-dae7520202e0 status: Accepted -------------------------------------------------- createdDate: 2026-03-15T17:16:48.426Z id: 3163ba2b-e3c8-4216-ae8a-bac351b82f8a status: Accepted

All of my notarization submissions have been stuck at "In Progress" for up to 10 days. I have 6 submissions spanning from March 4 to March 11, 2026, and none of them have completed or returned any errors. Affected submissions: dbf20b57-0073-444a-b09a-ac6747b7398e (submitted Mar 4) — In Progress d5886683-be64-455c-805d-cd8b12bbcd35 (submitted Mar 4) — In Progress 10bfa709-da17-49cf-9c89-63f93b5fb756 (submitted Mar 4) — In Progress e8d0866e-43f8-4a18-8129-64e6c5d3895a (submitted Mar 9) — In Progress f9526f25-5650-4c45-98ae-d778c58a2ffa (submitted Mar 9) — In Progress 82ec211f-9179-41fd-afe0-937c9b2c2750 (submitted Mar 11) — In Progress Running `notarytool log` returns "Submission log is not yet available." Team ID: CB4U5M6U9H It is an Electron-based app built with electron-builder. Steps taken to ensure compliance: Signed with a valid Developer ID Application certificate Hardened runtime enabled (hardenedRuntime: true) Proper entitlements configured (com.apple.security.cs.allow-jit, com.apple.security.cs.allow-unsigned-executable-memory, com.apple.security.cs.disable-library-validation) Entitlements inherited for child processes via entitlements.mac.inherit.plist Electron Fuses configured to disable Node.js CLI flags in production (resetAdHocDarwinSignature enabled) App submitted as a zip archive via notarytool submit I've tried resubmitting multiple times across different builds, but all submissions remain stuck. I also have an open support case (102836201208) that was escalated to Senior Advisors on March 11, but have not received any update. Could someone from the notarization team please investigate?