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

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?

Target Device: iPhone 13, iOS 18.5, enroll to MDM by enrollment profile Command: Response: Anyone could help?

In iOS 26.1 beta 4, under MDM restrictions that disable the camera via a configuration profile, the Camera and FaceTime apps are hidden as expected. However, other third-party apps can still access and use the camera function normally. This is unreasonable.

When using the SoftwareUpdateEnforcementSpecific to target an update to iPad OS 18.7.1, will the update be triggered to be downloaded immediately after the iPad has an active Internet connectivity? Or, if the SoftwareUpdateSettingsAutomaticActionsObject download string is set to AlwaysOff, will this mean that the update enforced will not start downloading automatically, but only when the user decides? I am trying to understand how these two can be combined together or if they work independently, as while trying to enforce a specific version, we need to eliminate the possibility to download an iPad OS version using cellular data, as our devices have an eSIM installed and the cost of using that for the iOS updates will be quite high. Maybe there is a setting to only allow the iOS updates to be downloaded via Wi-Fi. Thanks!

Hi, I found In-App purchase feature is restricted even with User-based VPP. I understand Device-based VPP does not accept In-App purchase, however User-based VPP accept In-App purchase. (It works on iOS 15 device actually.) When I tried subscribe ChatGPT on iOS 26 device using User-based VPP, an error dialog is shown that explains In-App purchase is not allowed. sysdiagnose shows logs belog: 情報 2025-10-26 23:58:22.350841 -0700 storekitd [Client] (ChatGPT) Initializing client デフォルト 2025-10-26 23:58:22.353982 -0700 storekitd [Client] (ChatGPT) Initialized with server Production bundle ID com.openai.chat and request bundle ID com.openai.chat] デフォルト 2025-10-26 23:58:22.354020 -0700 storekitd [CanMakePayments] In-app purchase disabled because app com.openai.chat has MID based SINF In iOS 15 device, no storekitd logs are found and appstored and several processes seem to handle In-App purchase. Does In-App purchase no longer work with User-based VPP? 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>

Hello Apple Developer Community, I am implementing the "Return to Service" feature with app preservation in our MDM solution (iOS 26+). My goal is to use the EraseDeviceCommand to securely erase user data while preserving managed apps, and then have the device automatically re-enroll without user interaction. What I am doing: The device is supervised and successfully enrolled in Automated Device Enrollment (ADE). The device has generated and escrowed a bootstrap token to our MDM server (SetBootstrapToken received). I am sending the EraseDeviceCommand to the device via MDM with the necessary parameters for Return to Service with app preservation. The command payload includes: Enabled: true The previously escrowed BootstrapToken (as Base64 data). WiFiProfileData (as Base64 data) to ensure connectivity post-erase. Example Payload Structure (Simplified): <key>ReturnToService</key> <dict> <key>Enabled</key> <true/> <key>BootstrapToken</key> <data>YOUR_BASE64_TOKEN</data> <key>WiFiProfileData</key> <data>YOUR_BASE64_WIFI_PROFILE</data> </dict> The observed behavior: The erase command is successful. The device performs the secure user data erase. Crucially, the managed applications are preserved and automatically installed again after the reboot (confirming app preservation is working). The device connects to the Wi-Fi network successfully. The issue: I am not seeing the GetBootstrapToken request from the device hit our MDM server's check-in URL during the post-erase setup assistant phase. The re-enrollment seems to complete, but this specific request is missing from our server logs. My questions: Is the GetBootstrapToken request an explicit check-in message type, or is it an implicit part of the general CheckIn process during ADE re-enrollment when the token is used? If the device successfully re-enrolls and preserves apps, is the explicit GetBootstrapToken request still expected? Or does the token included in the EraseDeviceCommand payload satisfy all authentication needs for this workflow? What specific conditions or capabilities on the MDM server side might prevent the device from sending this specific request, even if the overall process succeeds? Any insights from Apple engineers or other developers who have successfully implemented this flow would be greatly appreciated. Thank you!

Hello, I am building a Content Filter app for iOS and would like to get access to some information about network connections that are happening on the device. I managed to have the handle(_ report: NEFilterReport) method of my NEFilterControlProvider called, but the bytesOutboundCount and bytesInboundCount properties of the report are always 0. How can I have the real byte count of the connection ?

I recently reviewed the device management restrictions page of the developer docs (https://developer.apple.com/documentation/devicemanagement/restrictions) and noticed that several items are now marked "In a future release, this restriction will begin requiring supervision." Some of these changes are likely to have a dramatic impact on our app and business! So my question is threefold: a) where can I find out or request more information about the planned changes (e.g. timeline would be especially helpful)? b) why are these changes being implemented at all? c) to whom / where can I protest these changes (aside from this forum and feedback assistant)?

For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device, but still be able to reference them in later installed configuration profiles via MDM. However, it seems that for a configuration profile's payload to use a certificate (e.g. VPN payload), the certificate payload must be present in the same profile. Are we missing anything, perhaps it's already possible somehow? Ideal workflow for us would be: our MDM server generates a certificate (private+public keys) for a given device our MDM server sends this certificate to the device as configuration profile and saves PayloadUUID of the certificate's payload our MDM server deletes the generated private key from its storage. At this point the private key is present only on the device. at some point in the future our MDM server sends a configuration profile that references the certificate from step 2 via the saved PayloadUUID (e.g. using key PayloadCertificateUUID in a VPN payload) Current result: device responds to MDM server with error "The profile “VPN” could not be installed. Certificates needed for the VPN service “VPN” are invalid." Desired result: device is able to find the previously installed certificate via its PayloadUUID. Alternatively, it could be certificate fingerprint or something similar. One more alternative could be to replace steps 1-3 by an app on the device that obtains a certificate (in any way), installs it to device as a configuration profile, passes the certificate's PayloadUUID to our MDM server and then doing step 4.

Hi everyone, I submitted this feature request through Apple’s Feedback Assistant and wanted to share it here, because many families run into the same issue and Apple prioritizes features based on the number of reports they receive. Current limitation: Screen Time only allows one single Downtime period per day for child accounts. For families with separate school hours and bedtime, this is very impractical. My real-world use case: • Downtime 1: 08:00–13:00 (school) • Downtime 2: 20:00–06:00 (bedtime) Both serve completely different purposes, but are not possible to combine with the current system. My suggestions to Apple: Support multiple Downtime periods per day for child accounts. Allow custom exceptions per Downtime block (e.g., allow Phone app). Provide more flexibility overall for families using Screen Time. If you would benefit from this too, it would be great if you could submit the same request via the Feedback app – the more reports Apple receives, the higher the chance for implementation. My Feedback ID: FB21265678 Thank you! 🙏 Hallo zusammen, ich habe über die Feedback-App einen Vorschlag an Apple eingereicht und wollte ihn hier teilen, weil viele Familien dasselbe Problem haben und Apple mehr Rückmeldungen braucht, um das Thema zu priorisieren. Aktuelles Problem: In Bildschirmzeit kann für Kinder aktuell nur eine einzige Auszeit pro Tag eingerichtet werden. Für Familien mit getrennten Schul- und Schlafenszeiten ist das extrem unpraktisch. Mein Anwendungsfall: • Auszeit 1: 08:00–13:00 (Schule) • Auszeit 2: 20:00–06:00 (Schlafenszeit) Beides erfüllt unterschiedliche Zwecke, ist aber nicht kombinierbar. Mein Vorschlag an Apple: Mehrere Auszeiten pro Tag für Kinderaccounts. Pro Auszeit eigene Ausnahmen festlegen (z. B. Telefon erlauben). Allgemein mehr Flexibilität im Screen-Time-System für Familien. Wenn ihr das ebenfalls hilfreich findet, wäre es super, wenn ihr es auch über die Feedback-App meldet – je mehr, desto besser. Feedback-ID meines Vorschlags: FB21265678 Danke euch! 🙏

Hi, everyone! Is there any way to change ACL of existing Private key in system keychain using MDM? We would like to add the binary or .app to access list of the key. I tried to send script via MDM which imported/exported our certificate with private key with required ACL. But can we change it without import/export?

Issue Using the DeviceInformationCommand API, the following device information can no longer be retrieved on iOS/iPadOS 26 and later. IMEI ICCID PhoneNumber This issue does not occur on devices running iOS/iPadOS 18.x or earlier. We would appreciate it if you could advise us on a solution to enable the retrieval of this information. Request XML <?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>CommandUUID</key> <string><!-- Here is CommandUUID --></string> <key>Command</key> <dict> <key>RequestType</key> <string>DeviceInformation</string> <key>Queries</key> <array> <string>IMEI</string> <string>ICCID</string> <string>PhoneNumber</string> </array> </dict> </dict> </plist>

We are having issues working with bypass codes the server creates when initiating Activation Lock through MDM. We are able to use the device-generated bypass codes without issue. When using the end point to request activation lock as specified in https://developer.apple.com/documentation/devicemanagement/creating-and-using-bypass-codes/ we get a 200 response. But when using the endpoint to bypass the activation lock, we get a 404 response. If we try to manually input the activation lock bypass code, it also does not work. Both of these methods work with the device-generated bypass codes. Just to clarify when testing the server generated codes, we ensured that we did not test the device-generated codes. All of this was tested on iOS devices. Created feedback ticket FB21365819 with device specific details.

I've been running the betas fine for a while, now, where do you want to go??

Hello everyone, I am looking for technical clarification regarding potential rate limits when automating frequent iOS device resets. In my workflow, I need to reset test devices multiple times per day using the EraseDevice MDM command, often combined with the ReturnToService flag for automated setup. I understand that after a full reset, the device undertakes several critical steps to become operational again, including device activation, system app installation, MDM re-enrollment, and subsequent validation of developer certificates for internally distributed apps. Based on Apple’s documentation and my own observations, I am aware of the following domains being involved in these processes: Device Activation: albert.apple.com, gs.apple.com, captive.apple.com, humb.apple.com, static.ips.apple.com, sq-device.apple.com, tbsc.apple.com, time*.apple.com System App Installation: *.itunes.apple.com, *.apps.apple.com, *.mzstatic.com MDM Enrollment: Communication with Apple ADE servers followed by the MDM server. Developer Certificate Validation: ppq.apple.com, ocsp.apple.com, crl.apple.com My primary question is: Are there any rate limits imposed by Apple’s servers on these specific processes when performed frequently on the exact same device within a short timeframe (e.g., multiple times per day)? Specifically, could anyone provide information regarding potential limits for: Device activation requests? System app downloads post-activation? Automated Device Enrollment checks and subsequent MDM enrollments? Developer certificate validation requests? Additionally, is the list of domains above comprehensive for these processes, or are there other key endpoints involved that I should be aware of regarding potential rate limiting? Understanding these limitations is crucial for ensuring the reliability of automated device management workflows. Thank you for any insights!

It seems like every time an IOS update is installed, the camera app file formats get reset to defaults. This setting is not available to manage at the MDM level. Many people need the the most compatible settings for the purpose of file sharing. So, now we have nearly 1,000 devices with a complete mix of photo and video formats. And IT has wasted MANY hours converting files for people. Feature Request: Please either stop resetting the camera app file formats or allow us to manage those settings at the MDM level. Respectfully, Robert

Hello, I’ve run into an issue with a configuration profile on my supervised iPhone. I’m wondering if anyone here might be able to help? The profile contains the allowListedAppBundleIDs key within the restrictions payload. My Apple Watch is paired with the iPhone. The iPhone was supervised manually with Apple Configurator, hence the Apple Watch has not been directly supervised itself. The profile works completely as expected when installed on the phone. As soon as the profile is installed on the iPhone, I can witness the apps on the Apple Watch rearrange themselves as some apps are hidden. So clearly the profile is applying its restrictions to the Apple Watch to some degree. My issue however is that apps listed in the whitelist are hidden from the Watch. The apps that are missing from my Watch are Walkie Talkie, Find My Items, Find My Friends, Messages, Alarm, Remote, Now Playing, Sleep, Meditation and Heart Rate. This is despite the following bundle IDs being listed in the whitelist array: com.apple.findmy.findpeople, com.apple.findmy.finddevices, com.apple.HeartRate, com.apple.SessionTrackerApp, com.apple.NanoWorldClock, com.apple.findmy.finditems, com.apple.Mind, com.apple.NanoOxygenSaturation, com.apple.watchmemojieditor com.apple.NanoSleep com.apple.NanoNowPlaying com.apple.noise com.apple.tincan com.apple.NanoRemote com.apple.NanoAlarm com.apple.private.NanoTimer com.apple.NanoStopwatch I’ve done some testing, but not sure what I’ve found really. I’ve so far identified 3 scenarios. Scenario 1: I have the whitelist profile installed on the iPhone. I download an app that appears in the whitelist from my watch (or at least its iPhone version does). The apps show up on the iPhone automatically and can be launched there. These apps cannot be launched on the watch. Scenario 2: I downloaded a few apps to my watch, that didn’t automatically install on my iPhone at the same time. They were on the whitelist. These ones couldn’t be launched from my Watch. I then downloaded them to the iPhone and they could be launched there (since they were on the whitelist). Scenario 3: A couple of 3rd party apps on the whitelist could be downloaded and launched from the watch with the whitelist installed. It seems as though there are different kinds of Apple Watch app and this is what I’ve read elsewhere. First of all there are Watch-only apps, which do not automatically install a companion iPhone app. Secondly there are companion apps, which when installed from the Watch App Store download their companion app to the iPhone in the background. Someone please correct me - I’m bound to be overlooking something here. So maybe the apps that when installed from Watch automatically install on iPhone and can only be launched from the iPhone have a separate bundle ID for their Watch app which I haven’t included? Apps that are on the whitelist AND do not automatically install an iPhone app AND can be launched from the Watch, include: solstice What3words So maybe these do not need a companion app, but have the same Bundle ID as their iPhone app? However, I’m still not sure why many stock Apple Watch apps are missing from the Watch…. The most obvious answer is that I’ve got their Bundle IDs wrong, but I don’t think I have given I extracted the bundle IDs from the App Store pages of the Apple WatchOS apps. I noticed at this Apple Support page (https://support.apple.com/en-gb/guide/deployment/dep34c5cd30f/1/web/1.0) that there is no mention of whitelisting or blacklisting apps on WatchOS using MDM, yet something definitely happens on the watch when the configuration profile is installed on the iPhone. Furthermore, if I tap on a configuration profile, which comprises a blacklist, on my iPhone it will ask me if I want to install it on the iPhone or Watch. The same pop-up question doesn’t happen when the profile contains a whitelist. All this to say, I’m massively confused as to why I can’t get this working. I’d really appreciate anyone’s advice which is bound to be expert. Thank you

We want to set key-value pair (installation_token: xxxxx) into an app installed by MDM. Formerly we could set the key-value using Settings MDM command like this. <dict> <key>Command</key> <dict> <key>RequestType</key> <string>Settings</string> <key>Settings</key> <array> <dict> <key>Configuration</key> <dict> <key>installation_token</key> <string>xxxxxxx</string> </dict> <key>Identifier</key> <string>com.cloudflare.cloudflareoneagent</string> <key>Item</key> <string>ApplicationConfiguration</string> </dict> </array> </dict> We can still use this for the apps installed withInstallApplication MDM command, however we cannot apply this configuration into the app using Declarative Device Management. When we try it, we got an error like this. <dict> <key>CommandUUID</key> <string>.............</string> <key>Settings</key> <array> <dict> <key>ErrorChain</key> <array> <dict> <key>ErrorCode</key> <integer>12008</integer> <key>ErrorDomain</key> <string>MDMErrorDomain</string> <key>LocalizedDescription</key> <string>Could not modify apps managed by Declarative Device Management.</string> <key>USEnglishDescription</key> <string>Could not modify apps managed by Declarative Device Management.</string> </dict> </array> <key>Identifier</key> <string>com.cloudflare.cloudflareoneagent</string> <key>Item</key> <string>ApplicationConfiguration</string> <key>Status</key> <string>Error</string> </dict> </array> How can we work with managed application configuration with DDM?