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?

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

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

We ship an Endpoint Security system extension inside a host app. On one managed Mac (macOS 26.6.2, build 25G83, arm64) the extension can't be activated, while the same package works on other Macs with the same macOS build. WHAT WE SHIP AND HOW IT'S NOTARIZED Host app: ElasticEndpoint.app (co.elastic.endpoint), Developer ID signed, notarized, with the ticket stapled (codesign -dvv shows "Notarization Ticket=stapled"). System extension: ElasticEndpoint.app/Contents/Library/SystemExtensions/co.elastic.systemextension.systemextension (co.elastic.systemextension), same Team ID, Developer ID signed. It was part of the same notarization submission as the host app but has no ticket stapled to itself (stapler validate says "does not have a ticket stapled to it"). Delivery: a root-owned service extracts the app into /Applications with tar (so no quarantine attribute) and then runs "ElasticEndpoint --install" as root to request activation. Versions: first reported on 9.0.8, and the same on 9.5.1. 9.1.0 and 9.5.4 have the same layout. Public packages: https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.0.8-darwin-aarch64.tar.gz , with the app in data/elastic-agent-*/components/endpoint-security-resources.zip -> 64_Bit_Elastic_App_macOS.tgz. The 9.5.1 package is at the same URL pattern. SYMPTOMS ON THE AFFECTED MAC syspolicyd: [com.apple.syspolicy:default] Unable to parse ticket. syspolicyd: [com.apple.syspolicy:default] error registering ticket: -1 sysextd: Error checking with notarization daemon: 3 sysextd: bundle code signature is not valid - does not satisfy requirement: -67050 code failed to satisfy specified code requirement(s) sysextd: co.elastic.systemextension: extension failed to validate! uninstalling... "spctl -a -vv -t execute" prints "accepted / source=Developer ID", not "Notarized Developer ID", for our app and for an unrelated vendor's notarized app. Healthy Macs print "Notarized Developer ID". "syspolicy_check distribution" reports a notary error, and "codesign -R="notarized" --check-notarization" fails. RULED OUT The stapled ticket (Contents/CodeResources, 1716 bytes, SHA-256 e8679543f9934bd43b127210c10348f764b78a53360ec515ccbcb4afc0920e28) is byte-identical on the affected Mac, on a healthy Mac, and in the official 9.5.1 package. The network: TLS to api.apple-cloudkit.com and valid.apple.com works, there's no proxy, and the clock is correct (sntp offset 0.03 s). WHAT A HEALTHY MAC DOES (fresh macOS 26.6.2 VM, app without quarantine) Running the app's binary produces: "Extracting ticket from bundle" -> "Registering stapled ticket with system" -> CloudKit fetch -> "Inserting ticket". /var/db/SystemPolicyConfiguration/Tickets gains rows in the "tickets" and "hashes" tables, including the extension's cdhash. sysextd then validates the extension locally ("isNotarized = 1"), so the extension's notarization is established through the host app's ticket. If I truncate CodeResources on the VM, I get the same "Unable to parse ticket" / "-1" lines and then -67050. So on the affected Mac, ticket registration seems to fail even though the ticket file is intact. A third-party write-up describes the same signature on one Mac ("stapler validate" exit 65 for every vendor's app): https://github.com/fsnow/cst/blob/main/docs/implementation/NOTARIZATION_TICKET_ISSUE.md They report that none of these helped: resetting the Tickets database with SIP off, restarting syspolicyd/trustd, a fresh user account, or OS upgrades up to macOS 27.0.1. QUESTIONS What can make syspolicyd fail to parse or register a valid stapled ticket on a single Mac? Is there a supported way to repair ticket registration without erasing the Mac? Is it expected that sysextd validates nested code (the extension) only against the local ticket database, with no online fallback? What should we collect for you: a sysdiagnose, or a Feedback Assistant report? [FB number if filed]

Hi, This is our first-ever Developer ID notarization submission for our macOS application, Recto. The submission was created on: 2026-10-17T12:55:05.164Z Submission ID: d6f971e4-755c-494e-8f80-b2fa9e48b85e File: Recto.zip The submission has remained: status: In Progress for more than 3 days. Running: xcrun notarytool info d6f971e4-755c-494e-8f80-b2fa9e48b85e \ --keychain-profile "recto-notary" returns the submission successfully and shows In Progress. However, running: xcrun notarytool log d6f971e4-755c-494e-8f80-b2fa9e48b85e \ --keychain-profile "recto-notary" returns: Submission log is not yet available or submissionId does not exist Since notarytool info successfully finds the submission, the submission ID appears to be valid. This is our first notarization under this Developer ID account. Is this delay expected for a first notarization / in-depth analysis, or does the submission appear to be stuck? Should we continue waiting, or is there any action required from our side? Thanks.

Hi, Any idea about the timeline for approval? It's been sitting at submit for 8+ weeks. Email support will not help. Claiming no ETA and it's a separate team that reviews that. I've requested a few as initially had some mistake on submission. Here's one of it: Request ID: R7P34F4338 Team ID: H2SLQH5546 If this forum post can help escalate, that would be appreciated.

I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated. Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours. Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions. This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case. Is this a known issue for new accounts, and is there a way to get these submissions looked at? Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).

2022-07-24 16:43:30.074 *** Error: Notarization failed for '/var/folders/r1/3j8rdbl95l9csz588j1nc6xc0000gn/T/electron-notarize-gGm3Fr/git-icons.zip'. 2022-07-24 16:43:30.075 *** Error: You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881 You do not have required contracts to perform an operation (-19208) { NSLocalizedDescription = "You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881"; NSLocalizedFailureReason = "You do not have required contracts to perform an operation"; }

Hi — submissions from my account have been stuck "In Progress" for 3+ days, and as of today even a tiny control probe is being held, while an identical probe submitted two days earlier was accepted in under an hour. Notary service status is green. This is blocking our first signed beta release. Team ID: 35L272URMA (individual account, enrolled 2026-10-16) App submissions (all still In Progress): fbed8a42-a43e-436f-bc99-49262ee4189d, 2026-10-16 04:55 UTC 090bd775-a288-435a-a2c6-95253e36b4cf, 2026-10-16 05:22 UTC (current build) 698e88b0-e111-41c0-8a5b-4da74aff6599, 2026-10-16 08:22 UTC ec3bd245-9306-4b56-b799-3d84782fc833, 2026-10-17 05:43 UTC App: "Octopus Beta" - Developer ID-signed, hardened-runtime, darwin-arm64 Electron app (131 MB zip, ~10k nested files, submitted as ditto zip, not DMG). Tooling: electron-builder 26.15.2 / notarytool (Xcode CLT) / macOS 26. Control probes (same account, same credentials, same flow, ~10 KB signed test apps): 5dda20a1-3f03-4757-90bb-52fce39427f3, hello.zip, 2026-10-16 09:54 UTC, Accepted in under 1 hour 7889bf07-f4ba-4aa8-9b77-10b504ce9a18, hello2.zip, 2026-10-18 15:29 UTC, STILL In Progress 17+ hours later The first probe passing quickly while an identical second probe now hangs suggests this is no longer just in-depth analysis of the large app. Either the whole account is now being held, or there is a service-side backlog window. Could you confirm which, and whether anything on our side is contributing? We have stopped resubmitting per the guidance in thread/814841. Happy to provide artifacts. Thank you!

Your development team has reached the maximum number of registered iPhone devices. I am use the free provisioning file. So how can I delete old device and use my new iPhone to develop my app. only way is use a paid account? or register a new Apple ID?