I took notes during the "What's new in managing Apple Devices" session. If interested, please see the attached "Notes from session": Session Notes For the session video, please see the following link: https://developer.apple.com/wwdc22/10045

My Apple MDM Vendor Certificate request (Case ID: 103003418539) has been pending since October 21, 2026, with no response or status update. Has anyone experienced similar delays? Is there any way to escalate the request or get an update from Apple? Any guidance would be appreciated. Thank you!

We are installing Xcode for standard users, but as the standard users don’t have admin rights, they cannot install the system wide components they need admin access to do that, but we don’t want to grant admin access to our users. We have already developed a script where we are accepting the license and we are doing the run first launch, but they still need the iOS simulator and the other packages pre-installed, so how can we do that?

Hello Apple Developer Community, We are developing a hardware diagnostic solution consisting of a macOS desktop application and a companion iOS application. Our iOS application is currently distributed through Apple TestFlight for testing purposes. The application installs and functions correctly when users download it manually through TestFlight. However, we are facing an issue when attempting to automatically install the same iOS application onto iPhones connected to our macOS application via USB. Our Intended Workflow A user connects one or multiple iPhones to a Mac using USB cables. Our macOS application automatically detects the connected devices. The macOS application initiates installation of our iOS diagnostic application onto the connected iPhones. The iOS application performs hardware diagnostic tests. Test results are transferred back to the macOS application. Once testing is completed, the iOS application can be removed from the connected devices. Current Issue When installing the iOS application manually through TestFlight, everything works correctly. However, when attempting to install the application programmatically from our macOS application over USB, we encounter a developer recognition or trust-related error. Our objective is to support commercial hardware diagnostic testing on customer-owned iPhones without requiring users to manually install the application, enable Developer Mode, trust developer certificates, or register individual device UDIDs. Questions Is there an officially supported Apple API, framework, or method that allows a macOS application to programmatically install an iOS application onto USB-connected iPhones? Is this functionality available for applications distributed through TestFlight, or does it require an App Store production release? Can installation be initiated on customer-owned, unmanaged iPhones without requiring Developer Mode, manual certificate trust, or device registration? Are there specific code-signing, provisioning profile, or distribution requirements for installing an iOS application through USB? Does Apple provide a supported solution for deploying diagnostic applications to multiple USB-connected iPhones simultaneously? If direct USB installation is restricted, what alternative Apple-supported workflow would be recommended for commercial device diagnostic and refurbishment applications? Additional Information Our iOS diagnostic application and macOS desktop application have already been developed, and the core diagnostic functionality is working. The remaining challenge is determining the correct Apple-supported method for installing the iOS companion application automatically onto connected devices. We would appreciate guidance from Apple engineers or developers who have experience with USB-based iOS application deployment, device management, or commercial diagnostic solutions. Thank you for your assistance.

Hello everyone! I'm a software engineer currently working on the development of a Mobile Device Management (MDM) system. I'm trying to implement a restriction that prevents users from manually removing the MDM enrollment profile from their iOS devices. While researching Apple's Device Management documentation, I came across two configurations that seem related to this functionality: PayloadRemovalDisallowed: A Boolean key that appears to control whether users can remove a configuration profile. com.apple.profileRemovalPassword: A payload that allows a removal password to be configured using the RemovalPassword key. However, after attempting to implement these configurations in our .mobileconfig files, I haven't been able to achieve the expected behavior. In some cases, these changes also interfere with our device enrollment process, preventing devices from successfully enrolling in our MDM system. Questions What is the correct way to use PayloadRemovalDisallowed and com.apple.profileRemovalPassword within a .mobileconfig file? Should they be used together, or are they intended for different scenarios? Where exactly should these configurations be placed? Should PayloadRemovalDisallowed be defined at the root level of the configuration profile, while com.apple.profileRemovalPassword is included as a separate payload inside PayloadContent? Can these configurations be included directly in the MDM enrollment profile? Or should they be delivered through a separate configuration profile after successful enrollment? Do these configurations require the device to be supervised? Is it possible to prevent profile removal on manually enrolled devices, or is Automated Device Enrollment (ADE) required? Why might these configurations interfere with device enrollment? Are there any restrictions on combining an MDM payload (com.apple.mdm) with a profile removal password payload? Does setting PayloadRemovalDisallowed to true actually prevent removal of the MDM enrollment profile itself, or does it only apply to regular configuration profiles? Is there any supported way to make an existing MDM enrollment profile non-removable after enrollment? Could someone provide a working .mobileconfig example demonstrating the correct implementation of these configurations? Expected Behavior Once a device has been successfully enrolled in our MDM system, the user should not be able to remove the MDM enrollment profile manually through the device settings. Ideally, this restriction should not interfere with the initial enrollment process or subsequent communication between the device and our MDM server. Current Behavior When attempting to configure PayloadRemovalDisallowed and com.apple.profileRemovalPassword, the expected removal restriction does not work correctly, and the enrollment process may fail. I'm trying to understand whether this is caused by incorrect placement of the configuration keys, limitations imposed by the enrollment method, or specific Apple device management requirements. Any guidance, official documentation, or working implementation examples would be greatly appreciated. Thank you in advance for your help!

Is anyone else seeing this? Apple's documentation says "Your distribution certificate is valid for three years from when it was issued" (https://support.apple.com/guide/deployment/distribute-proprietary-in-house-apps-depce7cefc4d/web). On 2026-10-13 our automation created a new iOS Distribution certificate on our Apple Developer Enterprise Program account through the App Store Connect API (POST /v1/certificates, type IOS_DISTRIBUTION, with a CSR). The certificate expires 2027-11-12, which is about 395 days. Our previous enterprise iOS Distribution certificate, created in April 2025, got the full 3 years (expires 2028-04-28). To rule out our automation, I created another iOS Distribution certificate manually in the Developer portal on 2026-10-16. It also had a validity of about 396 days. We have revoked both so they can't be used. Questions: Has the validity period for Enterprise Program iOS Distribution certificates changed? If so, where is it documented? Is anyone else seeing ~395-day certificates on Enterprise accounts, from the portal or the API? Is there a supported way to request a specific validity period? I have also opened a case with Apple Developer Support (case ID 102999420277).

Hi everyone, We are testing Apple's native MDM migration flow. When we accidentally push an expired/past timestamp for the mdm_migration_deadline, identical test devices behave inconsistently: • Device 1: Immediately triggers the migration flow. • Device 2: Automatically shifts the on-screen countdown timer to exactly 30 minutes in the future. • Device 3 (Flight Mode): Bypasses the lockout while offline, but acts erratically once reconnected. What is the hardcoded framework fallback when a device parses an already-expired deadline? Has anyone else seen the OS dynamically generate this 30-minute grace window? Thanks!

We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.

We are migrating our macOS applications from the legacy PPPC Accessibility service to the macOS 27 declarative App Settings configuration, as recommended by Apple. The applications require Accessibility permission to provide managed data-protection functionality and create the required event taps. Our configuration contains: A declarative com.apple.configuration.app.settings configuration that sets the Accessibility privacy permission to Allow. A legacy PPPC payload that grants PostEvent, because this service is not available through App Settings. The declaration and PPPC payload are delivered and applied successfully. After the user accepts the macOS Allow / Not Now prompt, the application’s Accessibility slider is enabled under: System Settings → Privacy & Security → Device Control and Data Access The user can turn it off even while the management declaration remains installed and active. When the user disables the setting: The application loses Accessibility access. Required event-tap functionality stops working. The application may display the legacy Open System Settings / Deny Accessibility prompt when the protected feature is subsequently activated. Manual user intervention is required to restore the application’s functionality. Expected behavior: We expected an Accessibility permission managed by MDM/DDM to remain enforced while its declaration is active, similar to the behavior of an Accessibility permission granted through the legacy PPPC payload. Apple’s AppSettings documentation states: “The user can change the app permission privacy settings in Settings.app if they choose.” This appears to describe the behavior we are observing. However, it is unclear how an organization can enforce a required Accessibility permission after the legacy PPPC Accessibility grant is deprecated on macOS 27.

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

We are experiencing an issue with Privacy Preferences Policy Control (PPPC) profiles deployed through Jamf Pro on the Golden Gate beta. We use the following Jamf configuration profiles to pre-approve Digital Guardian Accessibility permissions: DG – Grant Accessibility Access to DgSessionSvc.app DG – RME These profiles are intended to grant Accessibility permissions automatically for Digital Guardian under: System Settings → Privacy & Security → Accessibility On macOS Tahoe and macOS Sequoia, these PPPC profiles work as expected. After deployment, the required Accessibility permissions are granted automatically and users are not prompted. However, on the Golden Gate beta, the same configuration profiles are installed successfully, but the required Accessibility permissions are not granted. As a result, users continue to receive the Accessibility permission prompts. We also observed a difference when inspecting the installed profile under: System Settings → General → Device Management → Profile On macOS Tahoe, the installed profile contains the following entry: Control the Computer — com.verdasys.DgSessionSvc — Allowed On the Golden Gate beta, this entry is missing, even though the identical Jamf PPPC profile has been installed successfully. For reference, we have attached: The Jamf PPPC configuration profiles (.mobileconfig) DGSessionSvc MobileConfig RME MobileConfig Comparison screenshots from macOS Tahoe and the Golden Gate beta Could you please confirm whether this is: a known issue in the Golden Gate beta, an intentional change in PPPC behavior, or an issue with our PPPC configuration profile? If this is an operating system issue, we would appreciate it if it could be investigated and addressed in a future Golden Gate beta release. Environment Affected OS: Golden Gate 27.0 Beta (26A5388g) Working OS versions: macOS Tahoe and macOS Sequoia MDM Solution: Jamf Pro 11.30.1 Affected Application: Fortra Digital Guardian Required Permission: Accessibility (Control the Computer) Architecture: Apple silicon We would also appreciate it if you could review the attached .mobileconfig files and let us know whether any modifications are required to make the PPPC profiles compatible with the Golden Gate beta, or if any additional information would be helpful for your investigation.

PermissionDefaults under Privacy for com.apple.configuration.app.settings , device reports Info.UnsupportedSettings for "$.Privacy.PermissionDefaults for macOS 27 device iMac manufactured 2024 Request from MDM : "Type": "com.apple.configuration.app.settings", "Payload": { "Privacy": { "PermissionDefaults": { "net.soti.mobicontrol.macOS": { "OrganizationJustification": "Message", "Accessibility": "Allow" }, "net.soti.mobicontrol.macOSHelper": { "OrganizationJustification": "Message", "Accessibility": "Allow" } } } }, "Identifier": "2adc58b3-f631-41b8-93d8-f55612055c30", "ServerToken": "4dc895cc-b7c2-4729-b8a4-f9e2f8dba5a9" } Response from Device: { "StatusItems": { "management": { "declarations": { "activations": [ { "active": true, "identifier": "77409e31-ff4f-4f86-a1bd-175515e3a3bd", "valid": "valid", "server-token": "b096dd48-a127-4f65-a60d-bd615911deb8-1" }, { "active": true, "identifier": "84992e13-edc2-4791-989e-0cc54bd18ab8", "valid": "valid", "server-token": "8460aca3-b263-43fe-b659-343c81a6479e" }, { "active": true, "identifier": "bfd661e8-b81f-4383-b243-00330fca13ae", "valid": "valid", "server-token": "38399079-5402-401a-83f4-c39e8b4807e8" } ], "configurations": [ { "active": true, "identifier": "00d217fe-f6e2-479f-89b5-73b479bd9f1d", "valid": "valid", "server-token": "c25104a2-6d13-44a1-ac00-ccc916490ae9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "2adc58b3-f631-41b0-93d8-f55612055c30", "valid": "valid", "server-token": "4dc895cc-b7c2-4429-b8a4-f9e2f8dba5a9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "c5bc77f6-745d-43ae-9e49-6e9100d3f6a5", "valid": "valid", "server-token": "e3a5cdb3-fd51-42a2-afb4-fe5f602a493d-1" } ], "assets": [], "management": [] } } }, "Errors": [] }

I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): `let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes.

I’m developing a macOS application that contains an embedded User Service Login Item: Outer app bundle ID: com.xxx.app Embedded User Service bundle ID: com.xxx.app.service Team ID: DE8Y96K9QP The User Service is embedded at: OuterApp.app/Contents/Library/LoginItems/UserService.app I deployed a com.apple.configuration.app.managed declaration through an MDM server, with an asset declaration of type: com.apple.asset.credential.identity, the declaration uses: "AppComposedIdentifier": "com.xxx.app (DE8Y96K9QP)" When the ManagedApp APIs are called from the outer ZTA app, the app successfully receives the identity. However, when the same ManagedApp APIs are called from the embedded User Service, the identity list is empty. When I instead use the embedded service’s identifier: "AppComposedIdentifier": "com.xxx.app.service (DE8Y96K9QP)", macOS reports either Error.InvalidCodeSignature or Error.NotPresent. My questions are: Can an embedded Login Item or embedded subsystem be the target of an app.managed declaration and access managed identities through ManagedAppIdentitiesProvider? Or must AppComposedIdentifier always identify the top-level application that contains the embedded Login Item? If the declaration targets the outer application, is there a supported way for the embedded User Service to access the same managed identity—for example, through XPC communication with the outer application? The outer application and embedded User Service are signed by the same Team ID, and both signatures validate successfully when checked with codesign. Thanks, Ying

I am developing an iOS application with a Location Push Service Extension and am trying to provide managed app configuration to the extension using Apple's ManagedAppConfigurationProvider and Declarative Device Management (DDM). The same managed configuration works correctly in the containing application, but the exact same API fails when called from the Location Push Service Extension. Environment: iOS: 26.2.1 Xcode: 16.4 Extension type: Location Push Service Extension The extension has the following entitlement in both the signed extension and provisioning profile: com.apple.developer.location.push The extension is configured through DDM using ExtensionConfigs: "ExtensionConfigs": { "bundleid (teamid)": { "DataAssetReference": "xxxxxxx" } } The Data Asset is successfully compiled by the MDM server and contains the managed configuration values. The device reports the following DDM status: "config-state": { "app-config-state": { "state": "valid" }, "extension-config-state": { "bundleidofextension": { "state": "unknown" } } } The main application can successfully retrieve the configuration using: let provider = ManagedAppConfigurationProvider() Task { for await configuration in await provider.configurations( ModelManagedAppConfiguration.self ) { print("APP CONFIG = (String(describing: configuration))") } } The same code and the same configuration type are used inside the Location Push Service Extension. Inside the extension, the provider is created successfully: LOCATION EXTENSION: creating ManagedAppConfigurationProvider LOCATION EXTENSION: provider created LOCATION EXTENSION: requesting configurations However, the request fails with: Failed to connect to managedappsd with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.devicemanagementclient.managedappsd was invalidated from this process." Failed to fetch managed app configuration. Returning nil. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") Failed to determine managed app configuration changed notification name. Unable to register for notifications. Failed to report configuration error state. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") LOCATION EXTENSION: CONFIG = nil The important observation is that the configuration works from the containing application but fails from the Location Push Service Extension before the configuration reaches the Decodable configuration type. I have also verified: The extension Bundle ID matches the ExtensionConfigs entry. The Team ID matches. com.apple.developer.location.push is present in the signed extension. com.apple.developer.location.push is also present in the provisioning profile. The DDM Data Asset is successfully compiled. The containing application's managed configuration state is valid. The same ManagedAppConfigurationProvider code works in the containing application. According to Apple's documentation, ManagedAppConfigurationProvider provides configurations for a managed app or extension, and ExtensionConfigs is the DDM mechanism for configuring extensions. My question is: Is ManagedAppConfigurationProvider fully supported from a Location Push Service Extension? If it is supported, what could cause managedappsd to reject/invalidate the XPC connection specifically when the request originates from a Location Push Service Extension? Could there be an additional entitlement, extension-specific configuration, or system restriction required for ManagedAppConfigurationProvider to communicate with managedappsd from this type of extension? Any guidance on how to further diagnose the NSCocoaErrorDomain Code=4099 / "Couldn’t communicate with a helper application" error would be appreciated.

Since iPadOS 26.5, when my application is running in background (non visible but with location fetching active in background), then my users are not able to update the application from their MDM application. The installation stays frozen, until the user manually kills my app. While in iPasOS 26.2 and older iOS, the MDM was able to terminate and update my app. My understanding: The MDM app can only terminate the non-interactive applications (maxTerminationResistance:NonInteractive). My application running in background with the location activated is seen as interactive. TestFlight and Appstore can terminate all applications (maxTerminationResistance:Absolute), so they are able to terminate and update my application. Can you confirm this has changed in the ios26 (after iPadOS26.2)? What are the recommendations to allow my users to update my app?

Hi Apple Team, We are using the Accounts MDM payload with: PayloadType: com.apple.MCX DisableGuestAccount: true On macOS 26, even after the MDM profile is successfully applied, a local Administrator can still toggle the Guest User setting in System Settings. Expected: The setting should be enforced by MDM and should not be modifiable by an Administrator. Interestingly, the same configuration works as expected on macOS 27 beta, where the Guest User setting is shown as “This setting has been configured by a profile” and cannot be modified. Could you please confirm whether this is a known issue/regression in macOS 26 and whether there is a workaround or any permanent solution in later patches ? Environment: macOS 26.x Payload: com.apple.MCX DisableGuestAccount = true macOS 27 beta: Works as expected

Hi all, Posting here because I've exhausted the Developer Support channel and I'm hoping someone in the community has seen this before, or can point me toward a path that actually leads somewhere. What happened I tried to enroll in the Apple Developer Program through the Developer app on my iPhone 16 Pro Max. I uploaded my passport as prompted and entered my address in Latin characters. I then got an error screen saying there may be an issue with my account that needs to be resolved before I can continue, and to contact Support. The enrollment button now reads "ID Verification Rejected." I have since also attempted enrollment through the web at developer.apple.com. Same result. This appears to rule out the Developer app's device check as the cause, and suggests the block sits on the account itself. What Support told me After several weeks and multiple exchanges, the answer I keep receiving is that my device is listed as a trusted device on other Apple Accounts, and that I need to contact whoever controls those accounts and have my device removed. They've also told me they can't disclose which accounts those are. So the instruction is: fix a problem by contacting people whose identity Apple won't reveal. I've also tried reaching Developer Support by phone. I've sat on hold for up to three hours on multiple attempts and never reached anyone. Email replies come back every few days and repeat the same instruction. What I've already checked I own the device, the phone number, and both of my Apple Accounts. My two accounts use different trusted phone numbers and different devices. Nothing is shared between them. I've checked every account belonging to people in my household. Nothing is shared or borrowed. Enrollment fails identically through the web and through the app. Where that leaves me Either Apple's records are wrong and my device or number is flagged in error, or an account I don't control genuinely has my device listed as trusted, which would be a security concern that I can't investigate without information only Apple has. Either way, I don't see how the resolution is on my end. What's stopping me from just throwing money at this is that I don't know what's actually flagged. If it's the device, a new iPhone fixes it. If it's my phone number or my Apple Account, I could buy a new phone, a new number, and a new email and still land on the same screen, out well over a thousand dollars with nothing to show. Nobody at Apple will tell me which it is, so any purchase is a guess. That's the part I find hardest to accept. What I'm asking the community Has anyone hit "ID Verification Rejected" during enrollment and gotten past it? What actually worked? Given that web and app enrollment both fail the same way, has anyone seen an account-level verification flag like this get cleared, and what triggered the clearing? Is there any way to see or reset which accounts list a device as trusted, from the device owner's side? Is there an escalation route that actually connects to a human? Three-hour phone holds with no answer and repeating email replies have gotten me nowhere. Does Feedback Assistant work for this, or is there a specific team that handles enrollment identity issues? Any pointers appreciated. I've been stuck on this for weeks, and I'd rather find the right door than keep knocking on the same one. Thanks.

We are testing the new Declarative Device Management (DDM) App Settings configuration on macOS 27 Golden Gate to manage Accessibility permission for our applications as suggested by the apple team in https://developer.apple.com/forums/thread/839536. We created a Jamf Blueprint with a custom com.apple.configuration.app.settings declaration and configured the required Accessibility settings. After applying the Blueprint to the User channel, we now receive the consent prompt shown in the attached screenshot. However, the permission flow does not appear to work as expected. Our understanding is that, after the user clicks Allow in this consent prompt, the configured Accessibility permission should be applied to the application without requiring an additional Accessibility authorization prompt. Instead, after selecting Allow, we still receive the subsequent prompt, which asks the user to choose either Open System Settings or Deny. The DDM declaration appears to have been successfully deployed and is shown as active on the system. Could you please clarify the following? Expected consent behavior: After the user selects Allow in the DDM App Settings consent prompt, should the configured Accessibility permission become effective without any additional Accessibility prompts? Consent scope: We are observing an Allow / Not Allow consent prompt for each DDM App Settings declaration. Is user consent expected to be requested separately for each declaration, or should macOS consolidate the Accessibility settings from multiple declarations into a single consent request? Additional Accessibility prompt: Why does the application continue to receive the Accessibility permission alert with Open System Settings / Deny even after the user has selected Allow for the DDM declaration? User interaction: Is there any supported way for an organization to manage or suppress these additional prompts so that no further user interaction is required after the initial DDM consent? Our goal is to understand the expected macOS 27 behavior and determine the supported management configuration for applications that previously received Accessibility permission through the PPPC payload.

Hello Team, We have a System Extension with Provider Type "DNS Proxy". We have embedded the System Extension in GUI target which registered as LaunchAgent. We found NEDNSProxyManager saves the proxy configuration in the caller's preferences. Due to that we see a prompt for Network Extension when switching users. On allowing that we see multiple DNS filter in the System Settings->Network->Filters even though one DNS Filter can enabled which is annoying. Question 1: Is this expected for non MDM users? Are the users expected to authorise Network extension when switching users. Question 2: Is there a way to prevent the multiple DNS filter for both MDM and non MDM users? To prevent multiple filters, we identified a solution to embed the System Extension in our LaunchDaemon target. So the proxy configuration will be save in the root preference. But with this approach we ended up with an error [OSSystemExtensionErrorDomain error 13] during OSSystemExtensionRequest.deactivationRequest. Question 3: Is there a way to avoid OSSystemExtensionErrorDomain 13 when deactivating System extension from our LaunchDaemon process? Question 4: What is the best practice in terms of embedding and deploying DNS Proxy System Extension for managed and non managed environment. Also if user expected to see multiple DNS filter. I suggest to show the filter that saved for that user's preference. Thank you.

Ever since tvOS 26.4, we've had some difficulties in discovering, pairing, and supervising Apple TV 4K devices using Apple Configurator 2.20. We submitted a feedback report about this issue (FB22525540). The issue has improved somewhat for me when using the latest tvOS 26.6, if the Apple TV is connected via Ethernet during the initial paring step. Sometimes the pairing still fails, but eventually I can get it to work. However, some others on our dev / QA teams haven't had the same luck in even seeing the device as available to pair (even when the Apple TV is at the welcome screen or Remote and Devices screen, nearby, and on Ethernet along with the Mac). I've seen other cases where the pairing seems to work, but then the device doesn't appear in the Apple Configurator devices list, and therefore it’s not possible to supervise and install profiles onto it. Are they any workarounds or other steps we can try?