We’ve run into what looks like a gap in how forceAirDropUnmanaged is enforced on iOS devices. Setup: Device: iOS 17.x (unsupervised, enrolled in MDM) MDM Restriction: forceAirDropUnmanaged = true Managed Open-In restriction also applied (block unmanaged destinations). Verified: from a managed app, the AirDrop icon is hidden in the share sheet. This part works as expected. Issue: When two iOS devices are brought close together, the proximity-initiated AirDrop / NameDrop flow still allows transfer of photos, videos, or files between devices. In this path, forceAirDropUnmanaged does not appear to apply, even though the same restriction works correctly in the standard sharing pane. What I’d expect: If forceAirDropUnmanaged is enabled, all AirDrop transfer paths (including proximity/NameDrop) should be treated as unmanaged, and thus blocked when “Managed Open-In to unmanaged destinations” is restricted. What I observe instead: Share sheet → AirDrop hidden ✅ Proximity/NameDrop → transfer still possible ❌ Questions for Apple / Community: Is this a known limitation or expected behavior? Is there a different restriction key (or combination) that also covers proximity-based AirDrop? If not currently supported, should this be filed as Feedback (FB) to request alignment between share sheet AirDrop and NameDrop enforcement? This behaviour introduces a compliance gap for organisations relying on MDM to control data exfiltration on unsupervised or user-enrolled devices. Any clarification or guidance would be greatly appreciated.

We’re running into a problem when deploying certain .pkg installers via MDM on macOS 15 and above. The installation fails with the following error message: “The app is running and we don’t have the context to quit it, failing install.” Context: The .pkg is being pushed through an MDM solution (not installed manually). This happens consistently across multiple macOS 15+ devices. The target app is often already running when the MDM tries to install the update. Unlike a manual installation, the MDM does not appear to have the ability to quit the running app before proceeding. Questions: Is this a known change in macOS 15 where MDM-delivered installs no longer have permission to terminate apps during package installation? Are there recommended best practices for handling app updates via .pkg through MDM in this scenario? Has anyone implemented a workaround—such as pre-install scripts, user notifications, or policies to quit the app before running the installer—that works reliably on macOS 15? Is Apple planning to update MDM behavior or installer APIs to address this, or should admins expect to handle quitting apps entirely outside of the MDM installation process? Any insights from Apple engineers or other developers/admins who have encountered this would be really helpful.

I have a question regarding MDM functionality for iOS/iPadOS. Background: According to Apple's support page(https://support.apple.com/en-us/125073), since iOS 26.1, "Previous Wi-Fi configurations will be replaced when a new profile is installed." We have observed that because of this change, when we apply a Wi-Fi configuration profile to an iPad via MDM, the manually configured network settings on the device (specifically, "Configure IPv4" and "Configure DNS") are reset to "Automatic". This erases the manually entered IP address, subnet mask, router, and DNS server addresses. Goal: We want to apply a Wi-Fi configuration profile from our MDM server to connect the device to a specific SSID, while preserving the manual IP and DNS settings that have been configured on the device. Question: Is there a way to prevent the IPv4 and DNS settings from being switched from "Manual" to "Automatic" when applying the configuration profile? For example, is there a specific key-value pair we can add to the profile to either preserve the existing manual settings, or to explicitly define manual/static IP settings within the profile itself for iOS/iPadOS? Reference: Sample Configuration Profile Below is a simplified version of the Wi-Fi configuration profile we are currently using. This profile does not contain any keys for IP address configuration. <?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>PayloadType</key> <string>com.apple.wifi.managed</string> <key>PayloadIdentifier</key> <string>com.apple.wifi.managed.13E2E6B3-D4B9-4E23-888A-524B3ED40C38</string> <key>PayloadUUID</key> <string>13E2E6B3-D4B9-4E23-888A-524B3ED40C38</string> <key>PayloadVersion</key> <integer>1</integer> <key>SSID_STR</key> <string>SSID</string> <key>EncryptionType</key> <string>WPA</string> <key>Password</key> <string>Password</string> </dict> </array> <key>PayloadType</key> <string>Configuration</string> </dict> </plist>

Hi everyone, I’m sharing this because I’ve been stuck with this issue for over two weeks, and I still haven’t found a solution — or received a meaningful response from Apple Support. A yellow banner has appeared on my account saying: “The Apple Developer Program License Agreement has been updated and needs to be reviewed.” But here’s the problem: I’ve already accepted the latest agreement long ago. When I log into both: App Store Connect Developer Portal …there’s no new agreement to accept, no prompt, no button — absolutely nothing new. The yellow banner simply refuses to go away, and it's preventing updates. I’ve already: Cleared cache & cookies Tried Safari, Chrome, Firefox Logged in from different devices/networks Verified that I am the Account Holder Reported the issue via Apple Developer Support (more than a week ago) Despite clearly stating the urgency of the matter, I’ve received no fix and no timeline. This is beginning to feel like developers’ time — especially for those who depend on timely releases — isn’t being taken seriously. So I’m writing here to ask: 🔹 Has anyone else encountered this same issue recently? 🔹 Is there any known workaround or fix? I’d appreciate any help or shared experience. Thank you.

Attempts to programmatically update or add numerous system-installed certificates (a common practice for organizations that rotate certificates regularly) are blocked, forcing manual, insecure, and error-prone workarounds. The root cause lies in the stricter security protocols implemented in macOS 15, specifically: System Integrity Protection (SIP) and Transparency, Consent, and Control (TCC) Command we are using : sudo security authorizationdb write com.apple.trust-settings.admin

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!

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.

We are using an app created with the Apple Developer Enterprise Program within our company. Every year, we recreate and distribute the app in conjunction with the renewal of the provisioning profile. Currently, there are cases where an app that expired in September 2025 is still running, which is causing problems. What could be the cause of this? The app operates on a VPN, but Apple domains are accessible.

I originally posted here & was referred to post in developer forumsn. https://discussions.apple.com/thread/256036430?login=true&sortBy=rank&answerId=261319559022 There has to be someone else out here that's gone through this. I've tried everything I can think of, forums, reddit, Microsoft documentation.... just can't find any clear cut method of doing this. I'm working on an InTune Mobile App Protection Policy. I know there are going to be some VPs out there asking why they can't use native iOS Apps, especially Apple Calendar, Contacts & Mail. I have not been able to get anywhere, I always end up with this error. Things I've tried: Allow sync of native apps with work account Putting in app exemptions (But I don't truly know if I know if I have the right values for this and there's no simple way of getting it from what I've seen. Having to download app to PC, finding config files, finding specific values.... that people say are hit or miss). Allow data transfer of ALL Apps What am I missing here? I'm pretty much giving up and just going to say sorry, you can't use Native apps.. Period! Anyone have any experience with this, especially for Mail, Calendar & Contacts? Thank you for anyone that can offer advice on this.

Nuestra cuenta está aprobada como MDM Vendor y necesitamos emitir por primera vez el certificado APNs para MDM en el portal de Push Certificates. Procedimiento seguido Primero hemos descargado desde nuestra cuenta de Apple Developer el certificado de MDM Vendor y lo hemos instalado en el ordenador. Esto lo hemos hecho para que, al lanzar la instrucción de OpenSSL, se pueda utilizar el UUID gestionado por Apple y así generar el CSR de forma correcta. La instrucción que estamos ejecutando es la siguiente: openssl req -new -newkey rsa:2048 -nodes -keyout mdm_private.key -out mdm.csr -subj "/O=Numbux/OU=MDM/CN=com.apple.mgmt.External." El CSR resultante es puro (no está firmado ni empaquetado) y está generado con RSA 2048 y SHA256. Sin embargo, al subirlo al portal de Push Certificates, seguimos recibiendo el error “invalid signing request”. Solicitud Dado que es nuestra primera emisión, entendemos que necesitamos el External UUID asignado por Apple a nuestra organización, porque veo que el problema se deriva de una incorrecto UUID que se está generando en el comando OpenSSL. ¿Podríais confirmarnos cuál es ese valor para poder completar el CSR y así emitir correctamente el certificado APNs MDM? He llamado a los números 900 812 703 y al 900 812 468 y he escrito al soporte de developer. NADIE ES CAPAZ DE DARMELO. Sin el external UUID no puedo crear el APN para mi MDM. Alguien me puede ayudar? No me mandeis links ni posibles números que llamar porque ya lo he hecho.

We've disabled FUS through a config profile, but users can still access FUS by enabling the MenuBar/Control Center icons. My org would like to prevent access to FUS so I've created a config profile. But the profile doesn't seem to work. Anyone have any ideas what I'm missing, or is this an OS bug? <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadDisplayName</key> <string>macOS - Tahoe - Disable Fast User Switching Control Center</string> <key>PayloadIdentifier</key> <string>com.myorg.fast-user-switching</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadScope</key> <string>System</string> <key>PayloadUUID</key> <string>f1a2b3c4-d5e6-7890-abcd-ef1234567890</string> <key>PayloadVersion</key> <integer>1</integer> <key>TargetDevmyorgType</key> <integer>5</integer> <key>PayloadContent</key> <array> <dict> <key>PayloadType</key> <string>com.apple.controlcenter</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.apple.controlcenter.57EBEF9E-E568-411E-AE27-500AD98C94F4</string> <key>PayloadUUID</key> <string>f1a2b3c4-d5e6-7890-abcd-ef1234567890</string> <key>UserSwitcher</key> <integer>8</integer> </dict> <dict> <key>PayloadType</key> <string>.GlobalPreferences</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>.GlobalPreferences.71DE1486-60BC-4CB9-890D-AD50A772890D</string> <key>PayloadUUID</key> <string>c5234012-e0sw-2066-6fl8-3bd5p8125op7</string> <key>MultipleSessionEnabled</key> false/> </dict> </array> </dict> </plist>

We are experiencing an issue with Apple Business Manager (ABM) synchronization that is blocking our device management workflow. Issue Description: During the ABM sync process in our MDM, we receive the error: "ABM Terms and Conditions not signed." What We’ve Checked: Logged into the ABM portal as the Administrator and confirmed that the latest Terms and Conditions. Attempted to renew the ABM token on our existing server, but the same error message continues to appear in MDM. Tried creating a brand new ABM server integration, which also fails with the same error. We checked with our MDM provider and they shared the logs, response received from ABM. It says T_C_NOT_SIGNED. But we have already accepted all the new Terms in ABM. We would appreciate any help in resolving this issue or guidance on what steps to take next.

Hello, I’m facing an issue while trying to add iOS devices to Apple Business Manager (ABM) using Apple Configurator during enrollment. When going through the setup process, the device fails to complete enrollment and times out. I’ve tried it multiple times. The device does appear in ABM during the process and I am able to assign it to different MDM servers but since the setup times out and fails, the device is automatically released. I have tried this with multiple iOS devices and it times out on every single one of them. Steps attempted: Factory reset and re-enrollment of the device Ensured network connectivity is stable and tested on multiple Wi-Fi networks Tried the following process using Apple Configurator on Mac (wired): Created a Wi-Fi profile in Configurator Connected the iPhone via cable and used Prepare (manual configuration) Used the “MDM server” placeholder and trusted anchors (as recommended) Linked the device to the ABM organization Skipped Setup Assistant steps Attached the Wi-Fi profile, then prepared and wiped the device Verified that the device should appear in ABM Attempted to assign the device to my MDM in ABM Despite these checks, the enrollment process times out. I’m attaching a screenshot of the error for reference. Could someone advise what might be causing this timeout or how I can further troubleshoot this? Any guidance would be greatly appreciated. Thanks in advance.

Issue Description: We are experiencing MDM profile installation failures specifically on iPhone 17 devices. After extensive testing and comparison between affected and working devices, we suspect this appears to be a parameter transmission error rather than device settings. Technical Analysis: Device Settings Comparison: No differences found between problematic and working devices in system settings, indicating this is not a configuration issue. Suspected Parameter Transmission Error: • Device model information appears to be restricted or blocked during profile download • User ID and phone number parameters are not being transmitted to the server • Installation logs show missing login ID and phone number entries Symptoms: • During MDM profile installation, the "Apps & Restrictions" section that should appear is missing • Profile download parameters are suspected to not be properly transmitted to the server • Installation process fails at the profile configuration stage Critical Finding: When we cloned a previously working device to create a problematic device configuration, the cloned device also began experiencing the same installation failures. This strongly suggests the issue is related to device-specific parameters or identifiers. Additional Information: We continue to receive reports of this issue from our iPhone 17 users, and these reports are occurring across various iOS versions. Request for Assistance: Has anyone encountered similar MDM profile installation issues on iPhone 17? Are there known limitations or changes in how device parameters are transmitted during MDM enrollment on this model? Any guidance on debugging parameter transmission or known workarounds would be greatly appreciated.

We are trying to develop an app that will be responsible for managing 5000+ managed iPads through Intune MDM. The user flow is to have a device locked to a single app when a user is not logged in, but to make the device available to other apps once a user is authenticated. We already tried UIAccessibility GuidedAccess Mode and autonomous single app mode but those were not sufficient due to our need to be able to toggle this from the background. When the device may be asleep. So another way we could achieve this functionality would be to control all app access under a launching mechanism. That way we could allow one app to be visible in our MDM configuration and try to access our business app through that using deep links. If this were to work, we would have to be able to hide an app and still make it launchable from the manager. Any ideas? Thanks

Before iOS26.1, allowCamera set false, all app can't use camera. On iOS26.1, allowCamera set false, removes camera icon from the Home Screen, but third app can still use camera, such as Safari and other apps that can call camera. Is it a bug or a new features？

Details: Device: iPhone 12 Pro Max System: iOS 26.1 beta 2 Issue Description: When testing MDM device restriction capabilities on iOS 26.1 beta 2, I found that the allowCamera restriction does not work as expected. Observed Behavior: • On a BYOD device: When allowCamera is set to false, the Camera and FaceTime apps disappear from the Home Screen, as expected. However, third-party apps (such as WeChat) can still access the camera and take photos. • On earlier versions (e.g. iOS 26.0.1): Setting allowCamera to false correctly blocks all apps, including third-party apps, from accessing the camera. Initially, I assumed Apple might have changed this restriction behavior so that allowCamera only applies to supervised devices. However, after testing on supervised devices, I found that even there, when allowCamera is set to false, the Camera and FaceTime apps are hidden, but third-party apps can still use the camera. This indicates that the restriction is not functioning correctly in iOS 26.1 beta 2. Expectation: When allowCamera is set to false, all camera access — including third-party apps — should be blocked. Request: Could someone from Apple’s development or MDM team confirm whether this is an expected behavior change or a potential bug in iOS 26.1 beta 2?

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?

I desperately need help with this issue. Are there any known issues regarding MDM profiles not installing on iPhone 17? Too many cases are being reported.

I'm hoping to make certain in-house apps fail to launch by revoking the in-house certificate that they were built on. This is by way of encouraging users of these apps to download updates built on a new certificate. How long will it take app built on a now-revoked certificate to no longer launch? Also, what is Apple's process for checking the validity of an in-house certificate in an app built on that certificate, running on iOS devices? I understand that provisioning profiles have built-in expiration dates, but will an in-house app that's built on a valid provisioning profile keep running even on a revoked certificate if the revocation happened before the certificate's own expiration date? Craig Umanoff