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.

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.

There could be a case where-in multiple transparent proxies might exist in the system (for ex., Cisco AnyConnect, GlobalProtect, etc). We want to know if there is a way to order transparent proxies so that the desired transparent proxy gets the request first. During our research, we found a resource which talks about ordering transparent proxies through MDM. https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy Using this reference, we tried to create a profile and push it through JAMF. Below is the profile that we created and pushed with JAMF. Property List - <?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>TransparentProxy</key> <array> <dict> <key>ProviderBundleIdentifier</key> <string>com.paloaltonetworks.GlobalProtect.client.extension</string> <key>Order</key> <string>1</string> </dict> <dict> <key>ProviderBundleIdentifier</key> <string>com.cisco.anyconnect.macos.acsockext</string> <key>Order</key> <string>2</string> </dict> <dict> <key>ProviderBundleIdentifier</key> <string>com.mydomain.transparentproxy</string> <key>Order</key> <string>3</string> </dict> </array> We are not sure if this is the right way to create the profile, though JAMF is not throwing any error while pushing this profile. We see this profile on the local machine as "/Library/Managed Preferences/com.apple.networking.vpn-transparent-list.plist". Is there a way to know if the profile took effect and the order of transparent proxies has changed. Thanks in advance.

Hi, I run a midsize business. Apple recommends for company owned devices and for other reasons to use Apple Business managed Apple IDs for the employees. After that, you have to use a MDM System for e.g. deploying apps and licenses. Testflight is an app that can be deployed too. But....Testflight can not more than to say "Hello" on a managed device. The use of Testflight and to test our developed apps is not possible with a managed ID. Can anyone explain to me this thinking or what is recommended than. Setting up a private Apple ID for that purpose...which on the other hand, Apple do not want or does not recommend.

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

Hello Apple Community, We are integrating Apple Tap to Pay into our Point of Sale (POS) application. Our organization manages a fleet of supervised iPhones using Apple Business Manager (ABM) and Mobile Device Management (MDM) to onboard devices with preferred settings and automatically install our POS app via MDM-assigned licenses, then our OPS team installs our devices at merchant location and trains their staff on how to operate our service. So far, we have avoided using Apple IDs on these devices, as our setup has relied solely on MDM enrollment and app deployment. However, Apple Tap to Pay requires an Apple ID and Passcode, which presents a challenge for automation at scale. Our Questions: 1. Generally speaking, is there a recommended flow to manage Apple ID and Passcode for our case? 2. Is Managed Apple ID supported by Tap To Pay flow? 3. Is there a way to automate creation of Managed (or regular one if Managed is not supported by Tap to Pay) Apple ID and assignment into supervised iPhone via Apple MDM protocol? 4. Both regular and managed Apple ID requires 2FA via phone number. It appears Passkeys and Authentication Apps are not supported. What is recommended way to manage 2FA phone numbers on a scale of thousands of merchants? 5. Is there a way to enforce/assign specific passcode into supervised iPhone via Apple MDM protocol? Key Considerations: • Devices are corporate-owned and supervised. • Practice shows that merchant staff is unable to manage Apple ID or any sort of iPhone credentials on their own due to frequent staff rotation and sometimes malicious actions by former employees. • MDM is used to manage deployment, security policies, and app installations and updates. • The goal is to avoid requiring end-users to manually sign in with Apple IDs and assign Passcode on each device. Thank you!

I am creating a prototype with the new Screen Time API introduced by Apple. The issue I am facing is, Applications installed in child device is not showing in parent device with FamilyActivityPicker. It is showing in Child device and apps can be shielded from child's device. Can some one describe, how to list the apps in parent's device. Both Device are running in iOS 15.3. Both falls in same family group Child is under 13 yrs old Screen Time enabled in both device and parent device can see child in Screen Time.

We are encountering a critical issue where an enterprise-signed iOS app crashes immediately after installation on devices running iOS 18.3.2 (22D82). The same app runs fine on other iOS versions (including iOS 18.3.1 and earlier). Issue Summary: After upgrading to iOS 18.3.2, users are unable to launch our enterprise app (Bundle ID: com.kt.MobileDRM). The app installs successfully but crashes immediately upon launch. This issue occurs only on iOS 18.3.2, not on earlier versions or other iPadOS/iOS devices. System Log Snippet: SecKeyVerifySignature failed: Error Domain=NSOSStatusErrorDomain Code=-50 "rsa_pub_crypt failed, ccerr=-7" UserInfo={numberOfErrorsDeep=0, NSDescription=rsa_pub_crypt failed, ccerr=-7} Additional Info: The app is signed with a valid enterprise certificate. No changes were made to the app binary or signing configuration before this issue started. We are not using an IPS file. A similar app (different bundle ID) shows the same behavior on iPadOS 18.3.2 but runs fine on other versions. Questions: Has there been a change in iOS 18.3.2 that affects enterprise certificate validation? Does ccerr=-7 indicate a cryptographic change or stricter signature verification? Are there updated requirements or provisioning profile constraints we should be aware of for iOS 18.3.2? We would greatly appreciate any insights or official guidance regarding this issue. Thank you!

We are implementing the Return to Service (RTS) with App Preservation flow. During testing, we were able to successfully fetch the Bootstrap Token as part of the ADE enrollment process. However, when attempting to initiate the Return to Service command with App Preservation enabled, the following error was returned: [ { "ErrorCode": 12089, "ErrorDomain": "MDMErrorDomain", "LocalizedDescription": "Could not erase device.", "USEnglishDescription": "Could not erase device." }, { "ErrorCode": 66002, "ErrorDomain": "MDMBootstrapTokenErrorDomain", "LocalizedDescription": "Failed to generate LAContext for bootstrap token", "USEnglishDescription": "Failed to generate LAContext for bootstrap token" } ] Below is the sample request (with dummy data). The actual request contained valid values in all fields: <?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>Command</key> <dict> <key>RequestType</key> <string>EraseDevice</string> <key>ReturnToService</key> <dict> <key>Enabled</key> <true /> <key>WiFiProfileData</key> <data>WiFiProfileData</data> <key>BootstrapToken</key> <data>BootstrapTokenValue</data> <key>MDMProfileData</key> <data>MDM Profile Data</data> </dict> </dict> <key>CommandUUID</key> <string>3670</string> </dict> </plist>

The issue is with all our enterprise apps. All apps worked on version 18.1. For the few users that updated to 18.2.1 it stopped working after the update. I have a phone that had 18.2.1 installed before I added any enterprise apps, they work fine. So the issue is you have enterprise apps, update from 18.1 to 18.2.1 they stop working. Removing the app (and trust), and installing again doesn't solve the issue. On the app reinstall it's doesn't ask to add the trust or reboot, but the trust is added back. When running the app, it opens for a second or two, then closes.

ABM has introduced a target date for moving a device from one MDM server to a new one. However, there's nothing in the API for setting that when you use the API to move MDM server Am I missing something or does it just not exist? Thanks Caroline

We have an office application used internally within our enterprise. The Provisioning Profiles (PP) for the app were about to expire, so we updated the PP and released a new version. However, we've encountered an issue where some users did not update their phones in time. After the app expired, they found it unusable and downloaded the new version, but the newly downloaded app also crashes on launch. Restarting the phone does not resolve the issue, and this primarily occurs on iOS 18.3.2. What could be the cause of this problem, and how should we address it?

Hello, I have a system, which is able to execute bash/zsh scripts on a set of machines. The default behaviour is that the signature of the script is checked on the machine, which is executing it, and in case if it is not signed properly, the system rejects the execution. An own certificate has to be created for signing the scripts, which means that the certificate has to be installed and marked as trusted on the target machines (which are executing the script). I've been using : "/usr/bin/security add-trusted-cert ..." command to install the certificate on the machines as trusted. Since macOS Big Sur, the above command was prompting the local user for admin credentials. To avoid this, Apple suggested to use the following command to temporarily disable and re-enable the confirmation dialog : 1.: /usr/bin/security authorizationdb write com.apple.trust-settings.admin allow 2.: /usr/bin/security authorizationdb write com.apple.trust-settings.admin admin Now with the release of macOS Sequoia, the above command : "/usr/bin/security authorizationdb write com.apple.trust-settings.admin allow" does not work any more. It gives the following output : NO (-60005) I have the following questions : 1.: Could you please suggest an alternative way for IT administrators to install certificates on their machines, without any user confirmation? 2.: Could you please suggest how the same could be achieved using a bash/zsh script? In which context could the above commands : "/usr/bin/security authorizationdb write com.apple.trust-settings.admin allow" and "/usr/bin/security authorizationdb write com.apple.trust-settings.admin admin" still work? Thank you for your help in advance!

Hello, we use an MDM profile that enables FDA for our program. The Identifier is set to be the path to our program. We'd like to have a profile that allows multiple CodeSignatures. Our older programs are signed with a different certificate than the current ones. We tried deploying 2 profiles (one for the 'old certificate' signed binary and the other for the 'new certificate' signed binary). But it looks like that MacOS accepts only one. I have also tried to use ProfileCreator to generate a profile with 2 entries, but it fails to do it. Manually editing the XML file and adding new entries does not work either. I'd like to know if there's a workaround for this issue.

The security configuration updates have been enforced through automatic update policy enabled through an MDM policy. However our end users would like to know when these updates are triggered by the device and installed successfully. We can see on a few devices that even though the automatic updates are enabled there are many devices with config updates pending. Also is there a way to manually install these config updates as the end user cannot see these updates listed in the software update section.

On iOS 26, if in "Single App Mode", the device gets stuck on the lock screen. Devices are configured in SAM (kiosk mode), without a PIN requirement. Since updating to iPadOS 26, every single device that locks (goes to sleep) becomes completely unresponsive at the lock screen. Touch input does not work. The only way to regain access is to reboot the device, which will boot to the SAM app, but then lock again if it goes to sleep. Related discussion in the public forums.

This test setup is Jamf Pro as the MDM with Entra as the IdP. PSSO is working on Sequoia devices. Prior to Tahoe, PSSO required the following three items: An existing local account, the delivery of Company Portal, and a profile containing PSSO payload. Based on the Tahoe announcement, it looks like PSSO is now available during Setup Assistant, removing the requirement of first creating a local account. I assume this means that the requirements now as easy as deploying Company Portal and the PSSO profile during the Pre-Stage policy. I attempted this on the macOS 26 beta 1 and during Setup Assistant, with the PSSO profile delivered, Setup Assistant prompts me to login to my IdP. However, pressing Continue will result in a failure, notifying me that the application required is not available. The continue button is now inactive but a "try again" button is available. This results in the loop of trying and then failing, stating that the required application is not available. I eventually must quit Setup Assistant which exits it and drops me at the login window. The only account that is visible is the management account. A trip into DFU and an IPSW restore then follows. Am I trying this too soon? Is PSSO at Setup Assistant not yet fully supported? Is there another requirement other than delivering Company App in the prestige alongside the profile? I've enabled the beta channel in MAU but there is no newer Company Portal being offered. Any guidance here would be appreciated as this is the PSSO announcement I've been waiting for since the deprecation of Apple Enterprise Connect.

After applying the MDM camera restriction on iOS 26.1 beta 2, the camera availability status is reported incorrectly. After applying the MDM camera restriction [UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera] return YES

We are attempting to block the attachment of photos from the Photos/Gallery app when sending emails or sharing on social media applications such as Gmail, Outlook, and other platforms. These are MDM Managed Applications While file attachments (e.g., PDFs, documents) are successfully blocked, photo attachments are not being restricted, allowing users to attach photos without limitations. We are applying the below restriction to the device through an MDM allowOpenFromUnmanagedToManaged: false https://developer.apple.com/documentation/devicemanagement/restrictions Steps to Reproduce: Open the Photos or Gallery app on a mobile device. Open Gmail, Outlook, or a social media application (e.g., Facebook, Instagram). Open the Photos or Gallery app on a mobile device. Select a photo to attach. Try to attach the selected photo to an email or post. Observe that the photo is successfully attached, despite restrictions on file attachments.

Hello, I am Sergio Sánchez, administrator of NumbuX. We are developing our own MDM. We are already granted as a MDM Vendor. We need to issue the APNs certificate for our MDM for the first time in the Push Certificate portal (identity.apple.com). We are having the error: “invalid signing request” when we upload the signed CSR to identity.apple.com. That is because we do not have the External UUID. Could you please let us know what is our External UUID? Without that, we cannot upload it successfully. We have already compared different signed CSR from other MDM Vendors and all have included the External UUID in the CSR. Please, do not send links, there is not way for us to know our External UUID because it is the first time that we try to issue this APNs. After the first time, we do not need your assitance. Please, let us know our External UUID. Thank you. Kind regards.