Hello Apple Developer Community, I'm running macOS 27.2 on Apple Silicon with Python 3.13.17 installed from the official python.org installer. I am investigating an inconsistency in macOS code-signing and trust verification. What I have observed: In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed. In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED. The Mac's date and time are configured automatically. The exact cause of the difference between execution contexts remains unknown. My questions: What could cause macOS trust evaluation to differ between execution contexts? Which read-only diagnostics could identify the cause? How can I investigate this without modifying Keychain trust settings, disabling system security or purchasing a paid developer membership? I can provide sanitized diagnostic logs if needed. Thank you for your help!

I am struggling with uploading my Mac-only app to TestFlight. I used to do this with Xcode 13.4.1 for a while without trouble, but now I have built the app with Xcode 27.1 and am getting issues such as ITMS-90885 and ITMS-90288 and I cannot figure out how to make it work. I have now at least realized that I seem to need to create a new provisioning profile because the one was using is missing some entitlement(s). To create a new profile, I need to create also a new certificate at https://developer.apple.com/account/resources/certificates/add But there's already my first hurdle: There are two types that allow upload the to MAS: "Apple Distribution" and "Mac App Distribution". Which one should I choose? I even googled for help but found nothing more than what the above website says. It's not clear what the difference is when I only want to submit to the MAS, and whether choosing the wrong one may already be part of the problem I'm having now with uploading my app. Can someone please explain in more detail if they're having exclusive behavior when using them to upload Mac apps to the MAS and TestFlight?

Hello, All of our notarization submissions except one are stuck in "In Progress" with no terminal state. I would appreciate it if someone could confirm whether they are still queued, or whether something on our side is blocking them. Team ID: 7MK3979GD2 Account: individual, newly enrolled; Developer ID Application certificate issued 2026-10-29 Tool: xcrun notarytool submit with an App Store Connect API key (Team Key, Admin role) Auth/upload work fine: notarytool info returns "In Progress"; notarytool log says the log is not yet available. Submissions (all times UTC): created submission id file status 1 2026-10-29T23:59:53Z 10b84260-955d-4ed5-a7ad-aa7484228427 GsGPT.zip In Progress 2 2026-10-30T01:24:44Z 2fa44ce1-345e-467b-8ea9-97362be6f45f GsGPT.app.zip Accepted (~2.5 min) 3 2026-10-30T01:28:09Z 097fee47-6fec-4645-b4af-f8250820dc8f GsGPT-mac-arm64-8.31.0.dmg In Progress 4 2026-10-30T09:21:25Z 9f4ec58b-d116-4e84-b859-9281ec0e5b92 GsGPT.app.zip In Progress 5 2026-10-30T11:05:58Z d0b9cebb-7795-4699-94b7-2c040fd06028 GsGPT.app.zip In Progress Notes: Submission #2 was accepted in about two and a half minutes, and its log reports "status": "Accepted", "issues": null. All submissions come from the same account, the same certificate and the same build job, so I believe the signed content is compliant. I have not resubmitted the same content. Later attempts are different artifacts from the same pipeline (app zip and DMG). App: GsGPT, an Electron-based macOS desktop app (bundle id cc.ekoaku.gsgpt, version 8.31.0, arm64), signed with Developer ID Application with hardened runtime, to be distributed outside the App Store as a notarized, stapled DMG. I understand that first notarizations from a new account may undergo additional screening. The oldest stuck submission has now been waiting over 13 hours, so I would just like to know whether these are still being processed or have been held. Could you please confirm the current state of Team 7MK3979GD2's submissions and let me know if anything on our side needs action? I am happy to provide any logs or additional details. Thank you very much for your time.

Hi Apple team, I have a recently created dev account and submitted two different 20-30 mb .apps for notary through the notary tool. I have read that this should only take minutes at this size of an app but both have been stuck in progress for almost 24+ hours. Below are the UUIDs of the notary submissions. Also I tried re-submitting but these are also stuck in progress. Successfully received submission history. history -------------------------------------------------- createdDate: 2025-09-26T11:46:32.643Z id: 9714758e-e216-496d-80f8-422f77011ebe name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T21:48:46.161Z id: c2a81300-c903-4277-8ef3-70205a690c76 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T18:24:36.205Z id: 42742be1-c7e5-4483-a2c5-95e89086d070 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T16:35:09.059Z id: a404256e-40c2-4dca-97fc-983e70ea4b7b name: <>.zip status: In Progress

We have developed a driver for our WiFi HaLow chipset, but are unable to progress beyond development because our entitlement request has stalled. We have received development entitlements, but these "require provisioning support" The original request was: Entitlement name: DriverKit, DriverKit USB Transport, and DriverKit Networking Business need: Distributing drivers for Morse Micro Wi-Fi HaLow Network Adapters Request date: 7 August 2026 Request ID: C7HYK62R73 When I followed up by email, I was asked to have the Account Holder (rather than a mere admin) reiterate the request to devprograms@apple.com, which I did. That was Follow-up number: 102965131843 The request from the Account Holder was on 21 September. When I followed up on 14 October, I was told to have the Account Holder follow up. None of the responses have asked for any additional information, nor have they offered any insight as to what may be blocking the request beyond the fact that I'm not the Account Holder. No responses have been sent to the Account Holder at all. What's blocking this? We're seeing increasing pressure from major accounts to support macOS, and are powerless to do so.

My macOS app notarized in 22-24 seconds on every release for months under my previous Developer ID team. I often shipped several releases a day, even with minor changes. Since moving to a new Developer ID team (FPRW433858) on Oct 25, every submission of the same app is held for hours: 85da38d3-1874-458a-9bb5-e4656c770037 (Oct 25 19:09 UTC): still In Progress when my CI job hit its 6-hour limit; accepted later. e4bf6e71-58dc-4710-abc0-ba0b459b099f (Oct 29 17:02 UTC): Accepted after 1h56m. Log: "issues": null, "Ready for distribution". Useless because GitHub CI crashed on it. 0c21d8be-cd60-45c0-b990-f7ebb616201a (Oct 29 19:02 UTC): In Progress, 1.5+ hours and counting. Same source, same build pipeline, same Sparkle framework, hardened runtime, inside-out signing. The only change is the team. The build is clean, and you have accepted it twice. I've read the "some uploads are held for in-depth analysis" answers. That is not an answer I can work with. A bugfix release now takes hours or fails outright on CI time limits (6h on github), for an app you have already accepted twice under the new Dev ID and countless times under the old Dev ID. I need concrete answers: Is team FPRW433858 flagged for in-depth analysis, and why? When does that end? After how many accepted submissions, or on what date? Is there anything I must do on my side? If so, what exactly? If nothing on my side causes this, please clear the team or escalate it to someone who can. I cannot accept to wait hours/days on app releases that are straightforward otherwise.

Hello, New to Apple's system and structure for certs and signing. I've been working with their team to get access for developers on my team to access the correct Certs and sign what they need to so we can push our latest builds out, since this is needed by our CI/CD pipeline. How can I give access to members of my team so they can do the code saying they need to and access the certs they need to? the certs are for dmg and pkg installers on macos.

Could someone help expedite our pending DriverKit USB distribution review request? Our driver works under development signing, but approval is blocking a TestFlight pilot for our accessibility product. Request: 8AR5R3NKZD Submitted October 18, 2026 (still "Submitted") Team: 7U9T57JPF7 Capability: DriverKit USB Transport – VendorID USB: VID 6790 (0x1A86), PID 29987 (0x7523) Support case: 103013236358 Thank you!

I'm seeing a problem with custom Installer plugins on macOS 27 beta 5 and beta 6. I have a .pkg containing a custom Installer plugin. The plugin is properly signed, and if I check it manually from Terminal, codesign is happy with it and doesn't report any errors. However, when I install the package by double-clicking the .pkg in Finder, the plugin is not loaded. I see this in the logs: amfid: /private/tmp/com.apple.installer.../KLNagentInstallPlugin.bundle/Contents/MacOS/KLNagentInstallPlugin not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" So apparently the plugin fails signature validation after Installer extracts it into /private/tmp, even though the same plugin passes codesign validation. This package/plugin worked on earlier macOS versions. So far, I've reproduced the issue on macOS 27 beta 5 and beta 6. Has anyone else run into this? Did anything change in macOS 27 regarding signing or validation of custom Installer plugins? I've also filed this via Feedback Assistant - FB24415432.

When attempting to access the (Certificates Identifiers & Profiles) page, I receive the message "Unable to find a team with the given Team ID to which you belong". Even while set as a developer or as an admin I still receive the same message above.

App Store Connect rejects my iOS Flutter app with error 90035: “Code failed to satisfy specified code requirement(s).” The error affects the main app executable, App.framework, and Flutter.framework. Environment: macOS 26.5.2 Xcode 26.6 Flutter 3.44.8 Individual Apple Developer Program membership The Release archive and App Store IPA build successfully. The exported IPA is signed with an Apple Distribution certificate and contains the correct TeamIdentifier. However, verification reports: Runner.app: valid on disk Runner.app: does not satisfy its designated Requirement The certificate Common Name contains a non-ASCII character: “Ç”. The generated designated requirement appears to represent this character using a decomposed Unicode form. I suspect a Unicode-normalization mismatch between the certificate Common Name and the embedded designated requirement. I am also unable to create a local Apple Distribution certificate: Xcode Manage Certificates reports: “The data couldn’t be read because it isn’t in the correct format.” The Apple Developer certificate portal reports “An unexpected error occurred” after I upload a valid CSR. Has anyone encountered this issue when an Apple Distribution certificate Common Name contains a non-ASCII character? Is there a supported way to regenerate the cloud-managed certificate or have Apple repair the team’s certificate state? I can provide sanitized codesign output if an Apple engineer needs additional diagnostic information.

I have requested two entitlements for my driver: "DriverKit USB Transport - VendorID" and "DriverKit UserClient Access" I have submitted them in Sep 20, and got no response or ETA on it. It's the only thing blocking the release of my driver. Request ID: C9ULM24X2U Team: F34U2UUGXX Status: Submitted What can I do to expedite this?

Hi, My NEURL Filter configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was approved on August 5, 2026, but it turned out to be attached to the wrong Apple Developer Team — an old individual account (S5VDH23BBZ) I no longer have access to, instead of my actual organization team, KRKJ76BC7W (SCOTTO), which owns and signs the app (bundle ID com.dropbet.DropBet). I contacted Developer Support, who said they couldn't transfer it and suggested replying to the original approval email — I did (on 08/08, then several times) with no response. I then tried resubmitting the same configuration under the correct team (KRKJ76BC7W), but the portal rejected it with: "A configuration with the same PIR Server Domain already exists." So a fresh submission is technically impossible while the original stays attached to the wrong account — the only real fix is transferring or re-attaching the existing approved configuration to KRKJ76BC7W. Has anyone dealt with this kind of Team ID mix-up before, or know who on the Network Extension / NEURL Filter team could help reassign an approved configuration? Happy to provide any additional details. Thanks in advance.

I would like to identify a supported, minimally scoped diagnostic method for a code-signature verification failure, without changing certificates, trust settings, or system protections. The command execution environment reported macOS 27.0.1, build 26A434. The following command was run against the standard system executable: /usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf It returned exit status 1 with: CSSMERR_TP_NOT_TRUSTED In architecture: arm64e.x1 The designated requirement displayed for the file was: identifier "com.apple.printf" and anchor apple The signature display reported Authority=(unavailable). Following TN3161, the CMS data was inspected structurally: it contained three certificate structures, whose recorded validity periods included the observation date. This was not a cryptographic or trust validation, and I do not treat the file as authenticated. My question is how to distinguish a certificate/trust rejection from inability to complete evaluation in the command's execution context. The documentation for SecStaticCodeCheckValidityWithErrors describes detailed errors, and kSecCodeInfoTrust describes access to the trust object used in code-signature evaluation. Is either a supported diagnostic route for this system executable and architecture? If so, please identify the required flags, prerequisites and minimum non-sensitive result fields. In particular, I do not want to change the strict or architecture coverage merely to obtain a passing result. No diagnostic using those APIs has been implemented or run. I am not asking to re-sign the system file, install certificates, reset trust settings, disable protections, or bypass validation. I would prefer an initial diagnostic that does not require private Keychain contents, broad system logs, or a full diagnostic archive. I understand that a diagnostic result or a successful information query would not by itself authorize execution or prove that the environment is safe.

Hello, We transferred an app from Team A to Team B. The app is live on the App Store, and every build currently in circulation was signed by Team A. Team B has not released any update — no App Store release and no TestFlight distribution — and the app may stay in that state for a considerable time. The distribution certificate and provisioning profile that Team A used to sign the build which is live right now will expire. We would like to confirm that this has no effect on sign-in and no effect on payments for the version that users already have installed from the App Store. Reasoning that applies to both The App Store re-signs the app as part of the distribution process, and the delivered build contains no embedded provisioning profile (TN3125), so neither Team A's certificate nor Team A's profile exists on the device. "Certificates overview" also states that an expired App Store distribution certificate does not affect existing App Store apps, and only prevents uploading new builds signed with it — which the transferor can no longer do in any case. Sign-in Login tokens live in the keychain under an access group whose name is prefixed with Team A's App ID Prefix. Our reading is that certificate and profile expiry has no bearing on keychain access at all, because the access check compares the group string in the binary's entitlements against the item's kSecAttrAccessGroup, and the signing certificate is not an input to that comparison. Is that correct? Payments Our reading is that payments are unaffected on both sides: StoreKit transactions — purchases, renewals, refunds — are handled by Apple's servers and do not depend on the app's signing certificate or provisioning profile; our server-side receipt validation relies on the app-specific shared secret, a 32-character hexadecimal string with no relationship to any certificate, so receipt validation keeps working. Is that correct, or does something break here? One consequence we would like confirmed If Team A ever needed to publish another build under its own account, we assume it would first have to issue a new, valid certificate and provisioning profile — that is, expiry does not affect the installed app, but it does affect Team A's ability to publish anything further. Is that right? Thanks!

Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that. There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test: – Installed through VPP on supervised devices running watchOS 26.1. – Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2. This strongly appears to be a VPP signing issue because we even did the following experiment: Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2. Verify that both apps launch successfully. Use an MDM command to install from VPP over the existing installations Verify that the watch app fails to launch (the iOS app is unaffected) My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.

It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

I’m developing an ARM64-native Wine + FEX compatibility runtime on Apple Silicon, without relying on Rosetta 2. According to the August 2026 Wine-devel discussion, the following entitlement is intended to be available to free developer accounts: com.apple.developer.cross-architecture-support-unmanaged However, I have encountered the following issues: My Xcode Personal Team does not offer a “Cross-architecture Compatibility Framework” capability. Certificates, Identifiers & Profiles is inaccessible to my free developer account. I cannot obtain a provisioning profile authorizing this entitlement. I contacted Apple Developer Support. They explained that entitlement requests generally require an Apple Developer Program Account Holder, but were unable to confirm whether this particular entitlement is currently requestable or where to request it. Could an Apple engineer clarify: Is the unmanaged entitlement currently available to free Personal Teams? What is the official App ID, provisioning profile, and code-signing procedure? Does this entitlement require additional approval from Apple? If it is unavailable, is there an officially supported alternative for development of an ARM64-native Wine loader? My goal is to use the native macOS cross-architecture features while keeping SIP and other security protections enabled. Relevant Wine-devel discussion: https://list\.winehq\.org/hyperkitty/list/wine\-devel%40list\.winehq\.org/thread/CKG5CEN2BE5VRXZ7O7NX4YUSBH3247WH/ Thank you.

Is the com.apple.developer.kernel.increased-memory-limit entitlement working as of iOS 15 Beta 3. As of right now if I try to add this entitlement on Beta 3 or below, the Automatic Signing fails. How much extra memory would be provided for an Application or its extension with this entitlement?

Dear Apple Developer Support Team, I am reaching out for assistance with two pending DriverKit entitlement requests. This is my first experience developing an application within Apple's ecosystem, and I recognize that my use case is somewhat unconventional. I may not have reached the appropriate support channel, so I would appreciate your guidance or assistance in directing this request to the correct team. We are currently evaluating the feasibility of adopting iPads for an internal enterprise application that communicates with our proprietary USB devices. These devices use the standard USB Communications Device Class (CDC), exposing a virtual serial port (UART). They work reliably on Windows, Linux, and macOS. To my surprise, I discovered that iPadOS does not provide general-purpose access to standard USB CDC serial devices. Based on my research, the recommended approach appears to be implementing a custom driver using DriverKit. We also use macOS as our primary development and debugging environment, so we would like to maintain a consistent DriverKit-based implementation across both platforms in macOS only for development. On September 30, 2026, I submitted the following entitlement requests: 1. Request GW966578ZB — DriverKit UserClient Access Requested entitlement: com.apple.developer.driverkit.userclient-access 2. Request 3HN2GMDFN5 — DriverKit / USB Transport Distribution Authorization Requested entitlements: com.apple.developer.driverkit com.apple.developer.driverkit.transport.usb Unfortunately, I have not received any response or status update on either request in the three weeks since submission. At this stage, our work is strictly a proof of concept (POC). We are not requesting public distribution or App Store publication. Our immediate objective is to validate the technical feasibility of communicating with our USB devices from iPadOS before committing to Apple's platform for our enterprise solution. The lack of progress on these requests has effectively blocked our evaluation for three weeks, making it difficult to assess whether iPadOS is a viable platform for our intended use case. Apple Developer Team ID: R4PSRJ28G7 We are genuinely interested in adopting Apple's technology for our enterprise operations, but we need to establish technical feasibility before proceeding. I would appreciate any guidance that could help us move forward. Best regards,Alon Bar-Lev