Is the possibility of programmatically recovering the enrolled email address associated with an iPad. We are currently working on a project that requires us to retrieve this information for our enrolled devices. Could you please provide guidance or documentation on how we can achieve this programmatically? Specifically, we are interested in any APIs or frameworks that Apple provides for this purpose, as well as any necessary permissions or configurations that need to be in place.

We’re looking for best practices to remotely update iOS apps that are deployed in Single App Mode (SAM) or Autonomous Single App Mode (ASAM), managed through MDM. Imagine a typical use case: an iPad installed as a self-service kiosk at an airport restaurant. We need to update the app periodically without: Displaying any prompts to the user Relying on the user to approve or initiate the update (since the device is unattended) Sending technicians onsite, as many devices are in remote locations MDM providers have stated, “This is how Apple handles it,” without offering a workable solution. We’re hoping someone here has experience or suggestions for: Seamless or silent app updates in SAM/ASAM Update workflows that avoid interruptions or user interaction Any proven strategies or automation options under MDM supervision Any insight or documented approaches would be greatly appreciated. Thank you!

In Device management profile, VPN.VPN.OnDemandRulesElement Action->Disconnect Example payload: OnDemandEnabled1OnDemandRules ActionDisconnectInterfaceMatchCellular When install my vpn payload with above configuration, I was unable to connect vpn manually when i try with wifi interface Based on the doc, VPN should tear down when i connect with specific type interface(here cellular) i was unable to connec the vpn when i'm in cellular network good but when i connect to wifi still the same is happening. Is this a bug? tried in ios 18

As we know, we can't add restrictions payload in the mobileconfig when registing the device. We are developing MDM by ourselfs, met some trouble. Please help.

We'd like to determine if there is a configuration declaration that is active on a device as part of a predicate. The current logic (based on the WWDC 22 session) is: SUBQUERY(@status(management.declarations.configurations), $declaration, ($declaration.@key(identifier) == "com.abc.declarationname" AND $declaration.@key(active) == true)).@count == 1 The goal is that if the declaration is active, then a predicate should evaluate to true. This query does not appear to be working. Should we be able to use @status(management.declarations.activations) in a predicate? If so, what are we missing to attempt to determine if the declaration is active? If I search the existing status objects that are sent from the device, it is showing as active in the status channel.

I have come across this Hideable attribute for managed apps, introduced in iOS 18.1, and I've encountered some behavior that seems to contradict the official documentation. According to Apple's documentation for app.managed.yaml, setting the Hideable key to false under the Attributes section should prevent a user from hiding the app. The documentation explicitly states: If false, the system prevents the user from hiding the app. It doesn't affect the user's ability to leave it in the App Library, while removing it from the Home Screen. I have configured this in my app.managed.yaml and successfully applied the profile to my test device via our MDM server. However, I am still able to hide the application from both the Home Screen and the App Library. Here are the steps I'm taking to hide the app: Long-press the app icon on Home Screen Select "Require Touch ID" Select "Hide and Require Touch ID" Authenticate using Touch ID Select "Hide App" After these steps, the app is no longer visible on the Home Screen or in the App Library, which is contrary to the behavior described in the documentation for when Hideable is set to false. My question is: Is this a known issue or a potential bug in iOS 18.1? Or, is there an additional configuration profile or a specific device supervision requirement that I might be missing to enforce this restriction correctly? Any clarification would be greatly appreciated! Thank you!

We’re exploring the use of Apple’s Automatic Assessment Configuration entitlement for an iOS app currently in the proof-of-concept stage. We’re enrolled in the Apple Developer Program with an active subscription. Both the Account Holder and team members have accepted all relevant license agreements. However, when we try to access the entitlement request form at: 👉 https://developer.apple.com/contact/request/automatic-assessment-configuration/ We are immediately redirected to: 🚫 https://developer.apple.com/unauthorized/ This happens for all team members, including the Account Holder, so it doesn’t appear to be a role-specific permissions issue. The app is still in the proof-of-concept stage — there’s no App Store listing or App ID yet. We’re trying to confirm entitlement eligibility before proceeding further. Questions: Is an App Store listing or App ID required to access this request form? Are there any hidden prerequisites (account permissions, team roles, prior submissions, etc.) that need to be fulfilled? Has anyone here successfully submitted this form — and if so, what steps or conditions were required? Any guidance or shared experience would be greatly appreciated. Thanks in advance!

We are facing an issue with Platform SSO registration on macOS devices for AD-bound user accounts with Microsoft EntraID configuration. We are using the Platform SSO payload on macOS devices integrated with Entra ID, and it works as expected — registration completes successfully, and the password syncs with the Entra ID password. However, when we try the same on macOS devices with AD-bound (mobile) user accounts, the registration does not complete. To elaborate, the process successfully completes the initial WebView authentication but fails at the stage where Apple prompts for the password to sync the local macOS user’s password with the Entra ID password. It does not display any error, and even after entering a valid password, the process does not proceed further. However, when we try the same on a non-AD user account, it works fine. We have checked with Microsoft, and they confirmed that there are no restrictions on their side for AD-bound accounts. Since the issue appears to occur at the Apple system level, they advised us to reach Apple teams on this. Could you please check and let us know how we can proceed with this? Payload used: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>AuthenticationMethod</key> <string>Password</string> <key>ExtensionIdentifier</key> <string>com.microsoft.CompanyPortalMac.ssoextension</string> <key>PayloadDisplayName</key> <string>Extensible Single Sign-On Payload</string> <key>PayloadIdentifier</key> <string>com.apple.extensiblesso.B408A658-3DAF-41FF-8A5D-AE77B380CB7B</string> <key>PayloadType</key> <string>com.apple.extensiblesso</string> <key>PayloadUUID</key> <string>D506CAFD-C802-41F2-9C3E-DF5289C315FF</string> <key>PayloadVersion</key> <integer>1</integer> <key>PlatformSSO</key> <dict> <key>AccountDisplayName</key> <string>EntraID</string> <key>AuthenticationMethod</key> <string>Password</string> <key>EnableCreateUserAtLogin</key> <true/> <key>LoginFrequency</key> <integer>3700</integer> <key>LoginPolicy</key> <array> <string>AttemptAuthentication</string> </array> <key>NewUserAuthorizationMode</key> <string>Admin</string> <key>UseSharedDeviceKeys</key> <true/> <key>UserAuthorizationMode</key> <string>Admin</string> </dict> <key>ScreenLockedBehavior</key> <string>DoNotHandle</string> <key>TeamIdentifier</key> <string>UBF8T346G9</string> <key>Type</key> <string>Redirect</string> <key>URLs</key> <array> <string>https://login.microsoftonline.com</string> <string>https://sts.windows.net</string> <string>https://login.partner.microsoftonline.cn</string> <string>https://login.chinacloudapi.cn</string> <string>https://login.microsoftonline.us</string> <string>https://login.microsoft.com</string> <string>https://login-us.microsoftonline.com</string> </array> </dict> </array> <key>PayloadDisplayName</key> <string>Platform SSO</string> <key>PayloadIdentifier</key> <string>42GBHOLAP04621.1BD5B6D9-640B-4DC3-9275-56DDD191A5FB</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>58548FC6-38D9-4B28-9EDF-BEEAB03BAB23</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>

Hi, I developed a Platform Single Sign-On extension and a corresponding extension for my IdP, which is Keycloak based. The code for both projects are here: https://github.com/unioslo/keycloak-psso-extension and https://github.com/unioslo/weblogin-mac-sso-extension I realized that, when using the Secure Enclave as the AuthenticationMethod, and according to Apple's documentation, the Extension doesn’t obtain fresh ID Tokens when they expire if the refresh token is still valid. When using password as the Authentication Method, it fetches new ID tokens when they expire, without prompting the user for credentials, by using the refresh token. My suggestion is that the same behavior should be implemented for Secure Enclave keys. The thing here is that usually, on OIDC flows, the ID/Access tokens are short-lived. It would make sense for the extension to provide fresh ID tokens. It doesn’t seem to make sense for me that, when using passwords, the extension would fetch these tokens, and not when having the Secure Enclave key. By not doing this, Apple almost forces the developer of an extension to fetch new ID tokens themselves, which doens’t make sense when it clearly provides fresh tokens when using passwords. It almost forces the developers to either implement that logic themselves, or to issue longer tokens, which is not so nice. How so you deal with this? Do you simply use the refresh token as an authentication token, or do you do some sort of manual refresh on the extension?

I'm are attempting to use the device management migration feature in Apple Business Manager / Apple School Manager (for devices running iOS 26 / iPadOS 26) to re-assign managed devices from one MDM server to another. We followed the published procedure (select device(s) → Assign Device Management → Set deadline → Continue). However, we are observing that on the device side, no notification or prompt appears to the user (such as “Enrollment Required” or “Your organization requires this device to enroll in a different device management service”), even after the migration deadline has passed. Here are the environment details: Device OS version: (iOS 26.1) Device ownership: enrolled via Automated Device Enrollment MDM re-assignment in ABM: old MDM server（name: https://dev5.clomo.com/panel/mackey-dev/ ） → new MDM server (name: https://obliging-bunny-equally.ngrok-free.app/ ) Deadline set: (12/10/2025 12:00 AM) Network connectivity: confirmed online at deadline time We would like to know: Under what exact conditions will the device display the notification/prompt, and what common mis-configurations prevent it from appearing? Is there any device log or activity indicator in ABM/ASM to confirm that the migration instruction has been sent to the device? In cases where the prompt does not appear, what troubleshooting steps can we perform on the device (or in the MDM/ABM configuration) to correct it?

We’re using the Apple Developer Enterprise Program for internal app distribution. The Apple ID is a generic one using our domain email, but the Account Holder is a real person with authority in the organization. For the payment method, we plan to use a corporate credit card — but it is issued under a different staff name (e.g. card under Chief, but Account Holder is IT Head). Just want to check: • Is this setup acceptable? • Will Apple reject the enrollment/renewal if the card name doesn’t match the Account Holder? • What’s the best practice in this case to avoid delays or verification issues? Appreciate any guidance or experience from the community. Thanks!

Subject: Questions Regarding Signing Certificates for MDM Configuration Profiles Dear all, I hope this message finds you well. I have some questions regarding the signing certificates used for MDM configuration profiles. Currently, our company uses an SSL certificate to sign MDM configuration profiles. However, with the announcement that the validity period of SSL certificates will gradually be shortened starting in 2026, we are considering alternative options for signing certificates. Through our internal testing and investigation, we have found examples of the following certificate chains being used: ・Developer ID - G1 (Expiring 02/01/2027 22:12:15 UTC) + Developer ID Application certificate chain ・Apple Root CA + Apple Worldwide Developer Relations Intermediate Certificate + MDM CSR certificate chain We would appreciate any insights or experiences you can share regarding the following points: Apple Support previously advised that "certificates issued by public certificate authorities (CAs) trusted by Apple" are recommended. The certificates listed at https://www.apple.com/certificateauthority/ are typically preinstalled on Apple devices. Are these considered "trusted public CAs" by Apple in this context? Is it acceptable in practice to use a certificate obtained from the “Certificates, Identifiers &amp; Profiles” section on developer.apple.com for signing MDM configuration profiles? We would be grateful to hear about any real-world experiences. If the answer to question 2 is yes, which certificate type within “Certificates, Identifiers &amp; Profiles” would be most appropriate for signing configuration profiles? If using certificates from question 2 is not suitable, are there alternative certificate types (other than SSL) that are valid for longer periods (e.g., more than one year) and appropriate for signing MDM configuration profiles? Apple's official documents do not seem to clearly specify what type of certificate should be used to sign MDM configuration profiles. If you know of any helpful documents or resources related to this topic, we would greatly appreciate it if you could share them. Thank you very much for your time and support. We would truly appreciate any advice or guidance you can provide.

The profile expiration date is approaching, and no amount of inquiries will solve it. Create a new profile Download a new profile from Xcode Press archive, press Distribute App, press Enterprise, and distribute Invalid expiration date in profile of summary of review app.ipa content I've tried everything that comes out by Googleing profiles, such as regenerating profiles, erasing caches, updating Xcode, updating macOS, deleting existing profile information, etc. Expiration date different from the expiration date of the profile created in that menu is displayed. The expiration date of the profile I created is December 8, 2026, and the previous certificate is January 22, 2026. However, the profile information of the generated ipa is February 12, 2026. So I can't distribute this app because I'm scared, and the expiration date is coming up. Users should have a period of time to update. Get me a novice developer who's choking up.

We have been trying to figure out how to block Apple Private Relay in our enterprise so we can monitor and filter our employees traffic. We are able to block the Private Relay via this process: We used this article from Fortinet to achieve this: https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-block-iCloud-Private-Relay-from-bypassing/ta-p/228629 This also appears to block the users ability to utilize Apple iCloud Drive Backups. They would like to allow that still. Is there a way to block iCloud Private Relay while still allowing iCloud Drive Backups to work? I am not finding a document listing the URL requirements for iCloud Drive Backups. We currently have this solution in place: https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-allow-iCloud-private-relay/ta-p/383703 Basically this solution is allowing all Apple URL/IPs to go through the firewall and not be filtered. They would like to scan the traffic through. When scanning is enabled the firewall blocks the iCloud Private Relay traffic as it is blocked as being a proxy. Any guidance is greatly appreciated.

Hello! I’m testing certificate issuance using a locally running Smallstep step-ca ACME server with the device-attest-01 challenge. I’ve created a custom MDM profile for this purpose. When I install the profile, the certificate is issued successfully, but it is not saved to the Keychain as stated in the documentation. I can only see the certificate via mdmclient or in the Wi-Fi settings dropdown menu. Is this expected behavior, or are there additional settings that need to be included in the MDM profile?

I encounter a connection error with Apple Configurator v2.18 when, after making changes in macOS Sequel 15.6.1, I want to apply and transfer the changes to the iPhone icon layout in iOS 26: Apple Configurator v2.18 crashes and returns an error message: ‘Try the operation again. If it fails, quit the application, launch it again, and try again. [NSCocoaErrorDomain – 0x1001 (4097)]’ I have done some research, and it seems that this bug has been identified and fixed in Apple Configurator 2 v2.19 (Build 10434). Have you encountered this problem? Do you know where to find version v2.19? This fixed version does not appear to have been released yet, and Apple support has been unable to help me. Thank you all for your help.

I am using system_profiler command to check on the installed application list from mac device. **Terminal command to check installed java version - ** But while running /usr/sbin/system_profiler SPApplicationsDataType -xml , I cant able to find Java as an installed application. Is this a known issue or do we have any alternative workaround to fetch the same?

We are experiencing a critical issue where VPP app installations are consistently taking an excessive amount of time, leading to significant delays in asset association. We are deployionThis is a systemic problem that affects all VPP apps, not just an isolated case. Apps: 39470db7-e475-4269-9709-c80641657027 => com.zimride.instant d0876900-2579-463e-99f1-b7c85ef5c5e8 com.microsoft.azureauthenticator Troubleshooting: We have performed extensive troubleshooting and can confirm the following: VPP Token: The VPP token has been successfully renewed and is currently active and valid. License Availability: We've verified that there are sufficient VPP licenses available for the apps being deployed. Device Status: We've attempted the following on the affected devices: Restarted the devices. Switched to different Wi-Fi networks. Uninstalled and re-installed the apps. App Status: The issue is not limited to a single app; all VPP apps are failing to install. License Revocation: We attempted to revoke and reassign licenses for some devices, but this did not resolve the issue. The app was not pushed, and the pending status remained. Troubleshooting: Through our internal investigation, we have determined that the core issue is that the Asset Association Status is consistently taking excessive time. This seems to be preventing the app installation queue from processing. We have observed a significant delay in the processing of events within the Notification Channel. The time between the event being created and a response being received is excessively long, indicating a potential backlog or issue. We have included a few recent examples below for your reference: Event ID: 39470db7-e475-4269-9709-c80641657027 com.zimride.instant Created Time: 2025-08-26 01:02:04 Response Time: 2025-08-26 01:34:05 Event ID: d0876900-2579-463e-99f1-b7c85ef5c5e8 com.microsoft.azureauthenticator Created Time: 2025-08-25 21:16:29 Response Time: 2025-08-25 22:21:07 We would appreciate your help in the following areas: Resolution: Could you provide any known solutions or workarounds for an asset association status that is taking excessive amount of time'? Best Practices: Are there any recommended best practices or additional parameters we should be checking with the MDM that might influence the queueing of VPP app assignments? Queueing Parameters: Could you provide insight into the parameters or conditions that can affect the queueing and processing of VPP app installations on Apple's servers? Please let us know if there is any additional information or logs we can provide.

Environment Devices: e.g., iPhone 12 mini, iPhone 16 (multiple units) OS: iOS 26 beta 2 and beta 4 (23A5297m) Distribution: Apple Enterprise Program (In-House), deployed via MDM InstallApplication Tooling: Xcode (latest available for iOS 26 betas) Summary Apps signed for Enterprise (In-House) distribution install successfully on iOS 26 betas via MDM, but terminate immediately on launch. The same builds run if installed from Xcode on the same devices. This is a regression from pre-iOS 26 versions where Enterprise builds installed via MDM launched normally. Steps to Reproduce Archive an iOS app and export for Enterprise (In-House) distribution. Deploy the .ipa via MDM using InstallApplication to a device on iOS 26 beta (e.g., 23A5297m). Tap the app icon to launch. Actual Result The app quits instantly on launch. System logs show launchd/runningboard errors, including NSPOSIXErrorDomain Code=85 (“Bad executable (or shared library)”): runningboardd(RunningBoard)[34]: Process start failed with Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" UserInfo={NSLocalizedDescription=Launchd job spawn failed} runningboardd(RunningBoard)[34]: Launch failed with Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" SpringBoard(FrontBoard)[35]: Bootstrapping failed ... NSUnderlyingError = { NSLocalizedDescription = Launchd job spawn failed; } Expected Result Enterprise-signed builds installed via MDM should launch as they did on iOS 25.x and earlier. Regression? Works on iOS versions prior to 26. Works on iOS 26 betas when installed from Xcode (developer-signed run). Fails only for Enterprise (In-House) builds delivered via MDM. Additional Notes / Possibly Related We also reproduced a similar failure mode with a minimal Safari Web Extension project: it installs and appears under Settings → Safari → Extensions, but enabling it and opening Safari produces: “ is no longer available.” Building a fresh project with a new bundle ID shows the same behavior on iOS 26 beta (23A5297m). Logs contain: Error occurred during transaction: The provided identifier "" is invalid. Running from Xcode (debug build) works. Workarounds None identified for Enterprise/MDM distribution. Only Xcode-installed builds run. Impact Blocks Enterprise deployment to our fleet on iOS 26 betas. Feedback / Attachments Included: sysdiagnose from an affected device, minimal Xcode project demonstrating the issue, Enterprise-exported app, and reproduction notes. Happy to share additional logs or perform targeted tests if needed. Request Can Apple confirm whether this is a known regression vs. a policy/validation change in iOS 26 for Enterprise/MDM installs? Any guidance on a short-term mitigation or build/signing change we can apply would be appreciated.

Hi, We developed a Platform SSO extension for our IdP, Keycloak. It would be great to get some feedback on it: https://francisaugusto.com/2025/Platform_single_sign_on_diy/