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 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.

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?

Hello, I have requested entitlements for my DriverKit-based driver, but the status has been "Submitted" since May 24, 2026. Below are the details of my request. Is there any way to expedite the process, as these entitlements are necessary for distributing the app? Also, what is the preferable way to follow up in such cases? Entitlements: DriverKit USB Transport - VendorID (0x0BDA), DriverKit UserClient Access Team: K89F9CL4ZU Request Id: 7W5RQ3D2X6 Requested At: May 24, 2026 Type: Team Status: Submitted Many thanks

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

Hi everyone, I'm building rewindDV, a macOS app for preserving recordings from older FireWire tape cameras and decks. Capture works on our development hardware, and I'm trying to get the PCI transport entitlement needed to move forward with Developer ID signing and notarization so testers can use it with SIP enabled. Our two original requests have been pending since August 1. Developer Support confirmed that DriverKit and UserClient Access are present, but PCI transport approval is still missing. They suggested resubmitting, so I sent a consolidated request today and added the new number to the existing support case. Here are the references: Original requests: 265MP3ZN42 and 49L9RB632H — August 1, 2026; both still showed Submitted today. New request: 5728BY853G — October 3, 2026. Developer Support case: 102964703572. We're requesting DriverKit PCI (PrimaryMatch) for Developer ID distribution, specifically com.apple.developer.driverkit.transport.pci with IOPCIPrimaryMatch = 0x590111C1. That's PCI vendor 0x11C1 (4545 decimal), device 0x5901 (22785 decimal): the Agere/LSI FireWire OHCI host controller, not the downstream camera or deck. We develop the software, not the controller, and are requesting only that exact pair. PCI development access is already assigned. Could someone familiar with the DriverKit review process check whether the new request is in the right queue and whether we're missing anything? I'd also appreciate guidance on which request to keep active, since I haven't cancelled either original. I understand there's no guaranteed turnaround time. After nine weeks, I'd just like to make sure nothing is waiting on us. Happy to provide more technical details if helpful. Thanks for your help!

Hi, Canary Mail has had approval to use the Default Mail App entitlement for years. We have a longstanding Xcode Cloud export failure involving com.apple.developer.mail-client. In our latest iOS build, compilation and archiving succeed (ARCHIVE SUCCEEDED). All three subsequent exports—App Store, Ad Hoc, and Development—fail with the same error: error: exportArchive Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We checked the signing configuration and Developer portal: • The main app requests com.apple.developer.mail-client = true. • An existing manual App Store provisioning profile is active until June 2027. Decoding the downloaded profile confirms it contains com.apple.developer.mail-client = true and matches the app's bundle identifier and team. • Local development archiving also succeeds with our existing manual Default Mail App development profile. • However, Default Mail App is absent from both the Capabilities and Capability Requests tabs for this App ID. This appears related to these reports, where Apple corrected the entitlement's distribution grants: https://developer.apple.com/forums/thread/774506 https://developer.apple.com/forums/thread/800072 Our case differs because all three export modes fail, rather than only Ad Hoc. Apple's provisioning documentation describes migrating older additional entitlements into App ID managed capabilities for cloud-managed signing: https://developer.apple.com/help/account/reference/provisioning-with-managed-capabilities Could our older Default Mail App approval still be available through manual provisioning profiles but not migrated to the managed capability used by Xcode Cloud? What is the correct support route to have Apple verify/migrate this approval and ensure Development, Ad Hoc, and App Store export are supported? If the grant is already correct internally, could this be a Cloud provisioning service issue? Is there a supported way to use our approved manual App Store profile for Xcode Cloud's built-in export while this is investigated? We need to preserve default-mail functionality, so removing the entitlement is not a suitable production workaround. We can provide the full distribution logs and profile details privately to Apple Support. Thank you.

Hi, I am working on a personal HIDDriverKit project. The documentation suggests that you do not need the entitlements from Apple to do local development - that all you need to do is turn of SIP, enable developer mode, and turn signing to "Sign to Run Locally". However, I have followed all of these steps, and am still running into the error that to build, I need to have a provisioning profile with the DriverKit (development) feature (MacOS 15.2 Xcode 16.2). Am I missing something here regarding the steps for local development? Does one need to request a development version of the entitlements even for local development? Do I need a paid developer account to do this? Thank-you in advance.

Our app Newton Mail (App ID com.CloudMagic.Mail, App Store app 721677994, Team 53X8EK4BSQ) held the com.apple.developer.mail-client entitlement for years. Newton shipped as a default-mail-capable app starting with iOS 14, and our January 2024 App Store distribution profile (release_appstore_com.CloudMagic.Mail) still contains the entitlement. The grant is no longer active. Automatic signing now fails with: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. The Default Mail App capability does not appear on our App ID in Certificates, Identifiers & Profiles, nor in the Capability Requests tab. This looks like the same migration issue described in these threads: https://developer.apple.com/forums/thread/821303 (same error on a years-old grant, fixed server-side by Apple) https://developer.apple.com/forums/thread/806537 (grant only "partially migrated" to the managed capability) What we have tried since July 2026: July 9: emailed the entitlement team. No response. August 31 and September 5: submitted the Default Mail Client request form. No confirmation page or reference number either time. September 13: resubmitted the form and received Request ID L8JM288VBQ. Support case 102959495479: support confirmed we are not currently granted the entitlement. Our follow-ups on September 18 and September 23 got no reply. Phone case 102973381060: the callback was marked "no answer" 44 seconds after we requested it, and the phone never rang. The current App Store version (10.0.94) meets all four published requirements: mailto: is declared in Info.plist, the app sends to any recipient, the mailto handler opens a compose view with To: pre-filled, and the app receives from any sender. Could someone from DTS take a look, or tell us the right channel to get the migrated grant restored? Thank you.

Hi team, Earlier, Apple’s documentation clearly mentioned that we needed to submit a request to Apple to obtain the Location Push Service Extension (com.apple.developer.location.push) entitlement. However, when I checked the Apple Developer Portal now, I don’t see an option to request this entitlement for my App ID. Could you please confirm whether this entitlement is still required to be requested from Apple, or if the process has changed and the request is no longer required? Thanks

When attempting to build an Apple Vision Pro application written in Swift in Xcode, we get the following status errors: "Provisioning profile [Profile Name] doesn't include the Main Camera Access capability.” and "Provisioning profile [Profile Name] doesn't include the com.apple.developer.arkit.main-camera-access.allow entitlement.” The provisioning profile we are attempting to use DOES have the Main Camera Access capability enabled through the Apple Developer portal. We have tried deleting and remaking the profile multiple times, as well as creating new profiles with the same settings, but completely different names and bundle identifiers, but keep getting the same errors. We DO have the "com.apple.developer.arkit.main-camera-access.allow” added to the entitlements file of the Xcode project, and we DO have the “NSMainCameraUsageDescription” key added to the info.plist file, along with the needed string describing the camera usage. Our organization has a valid and active Enterprise account, through which we have requested and been granted access to the “Main Camera Access” capability. We have built this applications multiple times before in the past year with no issues, these errors began after one of our provisioning profiles expired and we re-made it. We have tried clearing the Provisioning Profile Cache on our machine, clearing the Derived Data in the Xcode settings, and clearing the Xcode build cache. We are experiencing these errors on multiple machines, with different versions of our app, and with completely different apps that use the Main Camera Access entitlement. We experience these errors when the profile is downloaded directly in Xcode, and when it is downloaded from a browser and imported into Xcode. When we use “Automatically manage signing” our app properly builds and deploys to the Vision Pro, but when we use the app and attempt to access the main camera, the app crashes with the exception: "Exception: This app failed to request an authorization.” We have searched online forums and found several instances of others that have experienced this problem, but have not found a solution that works. Software Versions: Xcode Version: 26.6 macOS Version: Tahoe 26.5.1 VisionOS Version: 26.5

I have requested an entitlement for my DriverKit based driver, but the status is still in "Submitted" phase. I have also tried contacting Apple Support by phone/mail but to no avail [Case ID: 20000143721904]. Below are the details of my request. Is there any way to know the turnaround time or to expedite the process as this entitlement is necessary for the distribution of our app? Also, what is the preferrable way to follow up in such cases? Entitlement: com.apple.developer.driverkit.transport.pci - DriverKit PCI (PrimaryMatch) Team: 8S33FS7Q5Q Request Id - NZYWRD96U3 Requested At - August 13, 2026 Type - Team Status - Submitted Thank you, Abishek.

I submitted an Endpoint Security entitlement request today (request ID NWFPYC286F, Team type). The request shows up in my Request History with status "Submitted," but I never received an ACK email or follow-up number. I've checked spam/junk folders and the email associated with our team account. Nothing from Apple. Two questions: Is the request actually in the review queue if I have a request ID in the portal but no email confirmation? Is there any way to check status or get a timeline estimate? This entitlement is critical for our product development. We're building agent identity infrastructure that needs ES for process-level attestation on macOS. Appreciate any help, especially from anyone who's been through this recently.

Hi Apple DTS and community, My developer account's app has been granted the Default Mail App managed capability (com.apple.developer.mail-client). The capability works for Development and App Store Connect distribution, but it is not enabled for Ad Hoc distribution. This prevents us from using our Xcode Cloud “Archive & TestFlight” workflow: The archive succeeds. Development and App Store Connect exports succeed. Xcode Cloud then automatically attempts an Ad Hoc export. The Ad Hoc export fails, causing the entire archive action to fail and the TestFlight post-action to be skipped. The export log reports: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We have reproduced this in two consecutive Xcode Cloud runs. We also confirmed that: The App ID has the Default Mail App capability enabled. The entitlement is present and correctly spelled in the app’s entitlements file. The App ID’s provisioning support lists Development and App Store Connect, but not Ad Hoc. Our Xcode Cloud workflow does not expose an option to disable the automatically attempted Ad Hoc export. This appears to match these previous reports: https://developer.apple.com/forums/thread/774506 — a DTS engineer enabled Ad Hoc support for the entitlement, after which the developer confirmed the issue was resolved. https://developer.apple.com/forums/thread/800072 — DTS confirmed that the Ad Hoc distribution option must be enabled for the Default Mail App managed capability. We also opened an Apple Developer Support case (102945477410). Developer Support directed us to the forums and indicated that this issue would need to be handled by DTS engineers. I can provide our Team ID, Developer Support case number, Xcode Cloud run identifiers, and any other account details privately if needed. Thank you!

Two months ago we got approval for using the Notification Filtering entitlement. We rushed out to implement it in our app, only to find out that the permission was set for the wrong bundle identifier. We expected to get the permission for the notification extension's bundle identifier, yet it is added for the main app's bundle identifier. Per the official docs, the entitlement permission should be in the notification service extension target: After you receive permission to use the entitlement, add com.apple.developer.usernotifications.filtering to the entitlements file in the Notification Service Extension target. However, this fails to get signed when compiling for non-simulator targets because of the bundle mismatch issue. Simulator perfectly filters notifications. Adding the entitlement to the main app does compile, but filtering does not work (as expected). We reached out to Apple twice (Case-ID: 14330583) but we have yet to receive any response. Could there be something else wrong instead of the identifier mismatch?

Eons ago we were approved in the older entitlement method where we had to apply an Entitlement to our provisioning profile via a dropdown. We'd basically attach "Local Push Provider (Dist)" to our profile. That broke in May of 2025 when our fastlane process could no longer automate the creation of a provisioning profile with that profile attached. We learned the future was the capabilities so we submitted a request to migrate our Local Push Provider to a capability - https://developer.apple.com/contact/request/entitlement-migration-requests/ Meanwhile a new client wanted a white-labeled iteration of our app. So a new client requested the capability of Local Push via https://developer.apple.com/contact/request/local-push-connectivity and it worked in roughly 4 weeks. Their account now has "Network Extensions (additional values)" on the identifier which grants access to app-push-provider. Our build is fully automated - everything works. So we waited on our migration request and after months passed, we submitted in October of 2025 a new entitlement request for Local Push as our submit to migrate went stale. It never arrived again. So I started a case in 2026 roughly 6 months later - 102869206062. After many escalations I've been told: I wanted to provide an update to you regarding your entitlement request. It appears that your entitlement no longer requires a request. The channel you’ve reached is actually set up to provide administrative support to Apple Developers and those enrolled in the Apple Developer Program I just wanted to follow-up with you and ask you to please request the Network Extensions Entitlement again (19627183) It seems the overarching point is Network Extensions are no longer required for approval, but it seems app-push-provider (LocalPush) is. I don't want a random forum post to be a support thread. So looking for clarity on 2 points. Can you obtain app-push-provider (network extension) without Apple approval? Is this doc out of date? https://developer.apple.com/documentation/networkextension/local-push-connectivity To use the Local Push Connectivity API, your app must have the Network Extensions Entitlement with the app-push-provider value. Request this entitlement from the Entitlement Request Page. After you receive the entitlement, apply it to both your app target and your provider extension target. tldr; ➜ Desktop security cms -D -i match_ClientApp.mobileprovision| plutil -p - | grep 'push' 0 => "app-push-provider" ➜ Desktop security cms -D -i match_OurApp.mobileprovision| plutil -p - | grep 'push' ➜ Desktop