I have a in-house delivered app, I updated certificates and delivered the app before expiring, inviting users to update. after certificates expiration people who did not update now must remove the app loosing personal data, and download it again, but app crashes. I know that since iOS 18 in order to trust again an in-house identity, restart is required. What I need to know, is if there is some documentation where is explained the following: if I remove the only app delivered by in-house enterprise profile I have on a customer device, via home, long time tap gesture, "remove the app" then I install again the app, the profile reappears under "VPN and device management" and results already as "trusted" instead if I remove the app directly from settings > VPN and device management, when I re-install the app VPN and device management reappears and developer/app is not trusted, in it asks me to trust again the developer and during the operation, restarts the device, asks me device code and so on. so, my final question is: since it is clear to me that there is a difference between two removal methods, where is this logic described? Is it only present for in-house distribution?

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.

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.

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!

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.

how can i generate MDM Push Certificate for my own MDM server. Please guide me on that.

Hello, Thank you for your message. Regarding 3.2, we still find that your app is intended to be used by a specific business or organization, including partners, clients, or employees, but you've selected public distribution on the App Store in App Store Connect. To resolve this issue, it would be appropriate to review the other distribution options available for apps designed for specific businesses or organizations and choose a distribution option that works for your app and users. You can review these app distribution options on Apple Developer. I appreciate the help to get out of this inconvenience. Thank you.

How to test ManagedAppConfigurationProvider without MDM ? Task { /* Configuration provider task */ for await configuration in configurationProvider.configurations(MyAppConfiguration.self) { self.configuration = configuration ?? MyAppConfiguration.defaultConfiguration } } Can the existence of a configuration be simulated, e.g. by storing a mocked configuration in UserDefaults? The UserDefaults key "com.apple.configuration.managed" seems not relevant here.

Hello all, We have built our own MDM solution as we plan to support quite a few devices running iOS. Manual activation is running fine and devices are checking in. We have setup ABM with Device management service setup and linked to our MDM. We have added reseller via Apple customer number and purchased devices are showing in ABM. We have setup default management service assignment as well. When we are setting up a device it gives an error: Remote Management The configuration for your iPhone could not be downloaded from . cancelled Error in the device log is as follows: Jun 11 14:16:36 iPhone Setup(DMCUtilities)[626] : <DMCHTTPRequestor: 0x84cfd7d40> cannot accept the authentication method NSURLAuthenticationMethodClientCertificate Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Task <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1> auth completion disp=2 cred=0x0 Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Task <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1> summary for task failure {transaction_duration_ms=285, response_status=-1, connection=7, reused=1, reused_after_ms=0, request_start_ms=0, request_duration_ms=0, response_start_ms=0, response_duration_ms=0, request_bytes=0, request_throughput_kbps=0, response_bytes=0, response_throughput_kbps=0, cache_hit=false} Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: TLS Client Certificates encountered error 1:89 Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Task <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1> finished with error [-999] Error Domain=NSURLErrorDomain Code=-999 UserInfo={NSErrorFailingURLStringKey=, NSErrorFailingURLKey=, _NSURLErrorRelatedURLSessionTaskErrorKey=, _NSURLErrorFailingURLSessionTaskErrorKey=, NSLocalizedDescription=} Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: encountered error(1:89) Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: cleaning up Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: summary for unused connection {protocol="http/1.1", domain_lookup_duration_ms=0, connect_duration_ms=0, secure_connection_duration_ms=0, private_relay=false, idle_duration_ms=0} Jun 11 14:16:36 iPhone Setup(DMCUtilities)[626] : <DMCHTTPRequestor: 0x84cfd7d40> failed to communicate with the MDM server. Error: NSURLError:Desc : cancelled Domain : NSURLErrorDomain Code : -999 Extra info: { NSErrorFailingURLKey = "https://mdm.domainname/enroll"; NSErrorFailingURLStringKey = "https://mdm.domainname/enroll"; "_NSURLErrorFailingURLSessionTaskErrorKey" = "LocalDataTask <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1>"; "_NSURLErrorRelatedURLSessionTaskErrorKey" = ( "LocalDataTask <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1>" ); }

It's a great platform to grow your knowledge. Apple Teacher

In the RequestRequiresNetworkTether property, the definition of “network-tethered” is unclear, and there seems to be a discrepancy between the actual behavior and the description in the documentation. We would like to clarify the definition of the connection state that “network-tethered” means and the specific behavior requirements when the property is set to true. Explanation of the document The description “If true, the device must be network-tethered to run the command. I was not sure whether it refers to “network connection” or “tethered communication” as the Japanese translation. Actual operation verification results The error message was “The device is not tethered. (MDMErrorDomain:12081)”. Error occurs when only carrier communication is used The following connection conditions work normally (as in the case of false) Wifi communication Combination of carrier communication and Wifi communication Tethering communication Combination of carrier communication and tethering communication Tethering connection (both parent and child devices) Inconsistencies Although the document description could be interpreted as a simple network connection requirement, actual operation is limited only to carrier communications alone Error message uses language regarding tethering, but actual tethering connection works fine

Hi, I am experiencing an issue with in-house apps on iOS 18. When the MDM profile is removed, newly installed in-house apps cannot be opened. However, previously installed in-house apps still work fine until the device is restarted. Context: Our in-house apps are not distributed via MDM but through an internal company app store. These apps are signed with an enterprise certificate and have been working fine on previous iOS versions. Steps to reproduce: Install an in-house app while the MDM profile is active -> The app works fine. Remove the MDM profile. Install a new in-house app (signed with the same enterprise certificate) The newly installed app does not open at all. The existing in-house apps installed before MDM removal continue to work normally. Restart the device. Now, even the previously installed in-house apps no longer open. Observed behavior: The newly installed in-house app does not open, and no trust prompt appears in Settings > General > VPN & Device Management. The previously installed in-house apps continue to function normally until the device is restarted. After restarting, none of the in-house apps open anymore. Is there a now restriction in iOS 18 regarding in-house app installation after MDM removal? Any insights or solutions would be greatly appreciated! Thank you.

During VPP app installation, the app-device asset association event took longer than the usual maximum of 30 seconds to complete, regardless of the number of app licenses involved.

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.

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.

I tried the new feature of macOS 26.0 com.apple.configuration.app.managed. A configuration and its activation are defined with the data like this. InstallBehavior: Install: Required License: Assignment: Device iOSApp: true AppStoreID: '1113153706' After distributing the configuration with DeclarativeDevicement MDM command, an error is notified via status channel app.managed.list. "managed": { "list": [ { "state": "failed", "declaration-identifier": "1424a813-113f-5de0-9a75-38bf64f22673", "identifier": "com.microsoft.skype.teams", "name": "Microsoft Teams" } ] } What am I missing in the settings? Thank you

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.

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'm currently testing app updates using the App:Managed declarative device management payload, and I have a question regarding app update status reporting. Presently, by subscribing to the app.managed.list status item, we can retrieve a list of managed applications along with their installation status. Additionally, we enable automatic updates for managed App Store apps using the UpdateBehavior.AutomaticAppUpdates key. However, especially when a critical application update is initiated, we frequently find ourselves needing more detailed information about the update process. For instance, having status items similar to softwareupdate.install-state and softwareupdate.failure-reason would be incredibly helpful for user troubleshooting. My question is: Is there a way to obtain a similar level of detailed, real-time status updates for app updates? Any insights you might have, or existing methods to achieve this, would be greatly appreciated. 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