I'm currently implementing a managed app using the new AppConfig specification. I referred to Apple's official documentation: Specifying and decoding a configuration. Based on the example provided in the "Publish your configuration specification" section, I structured my application configuration plist like this: <?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>configuration</key> <dict> <key>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </dict> </plist> When I deployed this configuration via my MDM server, the server reported valid for the activation, configuration and asset (which is the plist), but the configuration did not reflect or apply within my app. My app was unable to retrieve these settings. After some troubleshooting, I found that removing the top-level <key>configuration</key> wrapper resolved the issue. The following plist structure successfully pushed the configuration to my app: <?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>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </plist> My question is: Is the inclusion of the <key>configuration</key> wrapper (as shown in the Apple documentation example) incorrect for the current AppConfig implementation? Or is this structure intended for a future release (e.g., iOS 26 or beyond) and the documentation implicitly refers to it, causing confusion for current implementation? Any clarification would be greatly appreciated! Thank you!

I am trying to find clarification on something. We are seeing strange cases where customer devices seem to unenroll themselves after a period of MDM inactivity. This seems to tie into roughly when their identity certificate has expired. We can't confirm this because the device has since unenrolled. Is there any case where an Apple device will automatically unenroll if it's identity certificate has expired? This doesn't always seem to happen - I had a device respond immediately after being switched off for a year - but could this be down to some devices being DEP enrolled and others manually enrolled?

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, I'm currently working on implementing app installation features, referencing the app.managed.yaml declaration on GitHub: https://github.com/apple/device-management/blob/0a4527c5ea21825fd23e08273ccdb9e2302458ce/declarative/declarations/configurations/app.managed.yaml My question pertains to the InstallBehavior.Version key. The current specification indicates its type as <integer>: key: Version title: Version supportedOS: iOS: introduced: '26.0' macOS: introduced: '26.0' visionOS: introduced: '26.0' type: <integer> Is there a way to specify the app version using a string format, such as x.y.z, instead of the integer (App Store External Version Identifier - EVID)? Allowing for a simpler version specification would make app version management through MDM more flexible and efficient. I believe this would significantly streamline the deployment and operation of Apple devices within organizations. Any guidance or consideration for this would be greatly appreciated. Thank you.

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 am a developer working on iOS apps. I would like to report an issue occurring in iOS 26 beta 2. Our company has Enterprise account, and we are developing apps. When we distribute these apps, and install them on a device running iOS 26 beta2, apps install successfully, but apps crashed immediately after being launched. MDM Install Application When I install the app via Xcode and trust it, apps will run. Launchd job spawn failed This issue does not occur on versions prior to iOS 26. I would like to know if this is a problem that will be resolved in future updates, or if it is a policy change.

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

Hello, I am running into a bit of an issue with the Screen Timeout/Screen Lock setting and would like some clarification on. First for a bit of context, I am enrolling personal iOS devices 18.0+ into the company MDM (Intune) with Account Driven User Enrollment. We are trying to set a screen timeout of 5 minutes and immediately after it asks for the passcode on the device, though this setting is not being applied and the device timeout setting can be set as "Never" on the user's end. This is a big security risk for the company I work for and and the issue with being HIPAA compliant. According to the Microsoft Intune Support, "In iOS 18, when using Account-Driven User Enrollment for BYOD (Bring Your Own Device) scenarios, the screen lock timeout setting is indeed marked as “Not Applicable”. This is because Apple’s privacy-preserving model for personal devices restricts administrative control over system-level settings like screen lock or idle timeout." I am needing clarification on the item mentioned from Microsoft Intune Support and if this setting is no longer able to be applied from the MDM with devices enrolled with Account Driven User Enrollment?

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.

Hi Apple team and community, We’re currently integrating with the Apps and Books for Organizations API as part of our device management solution and would like to highlight a few critical points we've encountered — including a reliability issue, an enhancement suggestion, and a request for clarification on API rate limits. 1. Issue: Intermittent 403 Errors with stoken-authenticated-apps Endpoint We are encountering intermittent 403 Forbidden responses from the stoken-authenticated-apps endpoint. Approximately 30–35% of the requests fail with a 403 status code. These failures are inconsistent — the same request (using the same Content Token and Storefront) may succeed upon retry. All requests are properly authenticated and include the required Cookie and other headers as specified in the API documentation. This issue is impacting our ability to reliably fetch app metadata at scale, particularly in workflows. We’d like to know: Is this a known issue? Could it be due to a rate limit or token misconfiguration? Are any changes required on our end to avoid these failures? 2. Enhancement Request: Include externalVersionId in versionHistory Response The versionHistory extension currently returns: versionString releaseNotes releaseDate However, for Declarative Device Management (DDM) workflows such as App Pinning, we need the externalVersionId as well. Without it, we can't reliably correlate version metadata with the specific version ID required for pinning. Adding externalVersionId would: Enable precise version targeting during App Pinning Improve reliability and automation in managed deployments We request that Apple consider including externalVersionId in the versionHistory response to better support DDM-based app lifecycle management. 3. Rate Limit Clarification We found the following note in the Apps and Books for Organizations API documentation: "The Apps and Books for Organizations API limits the number of requests your app can make using a developer token within a specific period of time. If you exceed this limit, you’ll temporarily receive 429 Too Many Requests error responses for requests that use the token. This error resolves itself shortly after the request rate has reduced." While this confirms that a rate limit is enforced, there is no detailed information about the thresholds — such as the number of allowed requests per minute, hour, or day per developer token. To help us implement proper throttling and retry strategies, we request clarification on the following: What is the exact rate limit threshold per developer token? Are there per-endpoint limits, or is it a global cap for all requests using the token? Does the API return a Retry-After header when the limit is exceeded? What is the recommended backoff strategy for clients to follow when receiving 429 errors? This information would help us implement efficient throttling and error handling logic. Any insights from the Apple team or other developers who’ve encountered these issues would be greatly appreciated!

I want to install Chrome extension via configuration profile without user needing to go to System Settings and install profile manually. Can i install configuraation profile by making user only interact with my app?

Finally got to the stage where the ACME certificate profile is successfully installed. However, the public key/certificate itself isn't appearing in the System Keychain. I'm not sure if this is normal or if it's an indication that something went wrong after the profile installation. Unfortunately, I didn't study the log detail at the time and I'm uncertain of how to retrieve those logs from two days ago for the ACME activities. Can anyone confirm that macOS 26 should be storing ACME-retrieved MDM profile-based certificates in the System Keychain? If they should be there, what can possibly go wrong? The most obvious issue I can see is that the ACME server has requested the certificate with two CN's, which comes from the MDM profile asking for the subject against CN and the OID (2.5.4.3). Both CN's are identical. I'm surprised the profile installed if something is wrong. At first, I assumed Apple had decided to stop installing the certificates into the System Keychain.

Im trying to make my own iOS MDM Server with SCEP. I cant send a response to the PKIOperation without the iPad rejecting it. Can someone post the PKIOperation response structure

The result Plist for the InstalledApplicationList MDM command is reporting duplicate Application identifiers. Sometimes with different version, other times with the same version. The device is MacOS 15.5, Enrolled via ABM (Supervised). Here are a couple samples from the returned list. Duplicate app: <key>BundleSize</key> <integer>398051</integer> <key>Identifier</key> <string>com.adobe.Acrobat.NativeMessagingHost</string> <key>Installing</key> <false/> <key>Name</key> <string>NativeMessagingHost</string> <key>ShortVersion</key> <string>5.0</string> <key>Version</key> <string>5.0</string> </dict> <dict> <key>BundleSize</key> <integer>398051</integer> <key>Identifier</key> <string>com.adobe.Acrobat.NativeMessagingHost</string> <key>Installing</key> <false/> <key>Name</key> <string>NativeMessagingHost</string> <key>ShortVersion</key> <string>5.0</string> <key>Version</key> <string>5.0</string> </dict> Different Version: <key>BundleSize</key> <integer>4197200</integer> <key>Identifier</key> <string>com.adobe.adobe_licutil</string> <key>Installing</key> <false/> <key>Name</key> <string>adobe_licutil</string> <key>ShortVersion</key> <string>11.0.0.39</string> <key>Version</key> <string>11.0.0.39</string> </dict> <dict> <key>BundleSize</key> <integer>4443177</integer> <key>Identifier</key> <string>com.adobe.AcroLicApp</string> <key>Installing</key> <false/> <key>Name</key> <string>AcroLicApp</string> <key>ShortVersion</key> <string>25.001.20432</string> <key>Version</key> <string>25.001.20432</string> </dict> <dict> <key>BundleSize</key> <integer>7380980</integer> <key>Identifier</key> <string>com.adobe.adobe_licutil</string> <key>Installing</key> <false/> <key>Name</key> <string>adobe_licutil</string> <key>ShortVersion</key> <string>10.0.0.274</string> <key>Version</key> <string>10.0.0.274</string> </dict>

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.

Summary: When applying a configuration profile that uses allowListedAppBundleIDs to permit a defined set of apps, essential Apple Watch apps are unexpectedly removed from the paired Watch — even though their associated iPhone bundle IDs are explicitly included. This issue occurs with a minimal profile, and has been consistently reproducible on the latest versions of iOS and watchOS. Impact: This behavior severely limits the use of Apple Watch in managed environments (e.g., education, family management, accessibility contexts), where allowlisting is a key control mechanism. It also suggests either: Undocumented internal dependencies between iOS and watchOS apps, or A possible regression in how allowlists interact with Watch integration. Steps to Reproduce: Create a configuration profile with a Restrictions payload containing only the allowListedAppBundleIDs key. Allow a broad list of essential system apps, including all known Apple Watch-related bundle IDs: com.apple.NanoAlarm com.apple.NanoNowPlaying com.apple.NanoOxygenSaturation com.apple.NanoRegistry com.apple.NanoRemote com.apple.NanoSleep com.apple.NanoStopwatch com.apple.NanoWorldClock (All the bundles can be seen in the Attached profile) Install the profile on a supervised or non-supervised iPhone paired with an Apple Watch. Restart both devices. Observe that several core Watch apps (e.g. Heart Rate, Activity, Workout) are missing from the Watch. Expected Behavior: All apps explicitly included in the allowlist should function normally. System apps — especially those tied to hardware like Apple Watch — should remain accessible unless explicitly excluded. Actual Behavior: Multiple Apple Watch system apps are removed or hidden, despite their iPhone bundle IDs being listed in the allowlist. Test Environment: iPhone running iOS 18 Apple Watch running watchOS 11 Profile includes only the allowListedAppBundleIDs key Issue confirmed on fresh devices with no third-party apps Request for Apple Engineering: Please confirm whether additional internal or undocumented bundle IDs are required to preserve Apple Watch functionality when allowlisting apps. If this behavior is unintended, please treat this as a regression or bug affecting key system components. If intentional, please provide formal documentation listing all required bundle IDs for preserving Watch support with allowlisting enabled. Attachment: .mobileconfig profile demonstrating the issue (clean, minimal, reproducible) Attached test profile = https://drive.google.com/file/d/12YknGWuo1bDG-bmzPi0T41H6uHrhDmdR/view?usp=sharing

Hello, We are currently deploying Apple devices in our organization using Apple Business Manager (ABM) and are looking for a long-term self-hosted MDM solution. We initially considered MicroMDM, but since official support will end in December 2025, we are evaluating NanoMDM. I would like to confirm: Is NanoMDM a stable and production-ready option for long-term use with Apple Business Manager and Automated Device Enrollment (ADE)? Does NanoMDM support all essential features like: Supervision Remote wipe App deployment Configuration profiles Are there any limitations or known issues with using NanoMDM? Are there any other open-source or lightweight MDM solutions Apple developers recommend that are actively maintained? We are aiming for a reliable, secure, and future-proof self-hosted MDM setup. Any guidance or shared experience would be greatly appreciated. Thanks, Vijay Pratap Singh

We have applications RME and RMEUI, which are added under FileProviders section. Looking for MDM profile that can lock these entries so that users cannot disable them. Currently we are using JAMF Pro MDM to control our applications. In Sequoia OS -> Open System Preferences -> General -> Login Items & Extensions -> Under Extensions section -> File Providers In Tahoe OS -> Open System Preferences -> General -> Login Items & Extensions -> Under By Category/App section -> File Providers (In the screen shot you can find RME entry)

Apple face app is used to fore video calling and chatting and voice calling AP same a what’s app tango etc…

When I try to sign in Managed Apple ID in supervised device there appears a prompt stating that "Apple ID" is a work account.This account must be signed in as a work account on this device.When I click continue it takes to VPN and device management tab where MDM profile already exists. Note:The managed Apple ID has a ICloud subscription for it. When I remove the subscription for the Apple ID and try to sign in, it works. Kindly help on this or advise on any additional steps required to enable sign in for managed Apple ID in this scenario