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

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?

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 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 work at a school in NYC and have a software idea that could better support the new NYC phone ban law than current market options (i.e. Yondr pouches). Right now at my school, students and staff scan a QR code upon entering the building to indicate that they are in the building. They scan again on the way out to indicate they've left the building. This is super helpful for attendance, particularly in emergency situations (fire drills, etc). Imagine if when students scanned their QR code, it also activated an app similar to Opal or ScreenZen, but with an admin preset whitelisted apps. The idea is that this app would default deny access to all apps on students' phones except the admin preset whitelisted ones such as Phone, Calculator, etc. Depending on the age/needs of the student, other apps like Spotify, or medical apps could also be whitelisted. My question is -- is this idea possible to create? We would need admin preset controls to create the preset whitelist. We can't have students picking their own restrictions, as we know most would opt to not restrict at all. We would need an admin dashboard so teachers/admin can see which students have activated the app in the building, and which may be trying to sneakily avoid it. We would ideally need to be able to whitelist both system apps like Phone and Calculator, as well as non-system apps such as Spotify (and medical apps -- we have some students who manage/monitor their Diabetes with an app). I don't have a background in software. I'm a math and health teacher. I've experimented with trying to have friends who majored in CS to create this app for me, but they've all either struggled/lost interest. So I'm also looking for a business partner in this venture. If anyone has any guidance here, it would be so helpful! My boss (Head of School) is super interested in this idea and significantly prefers it to every other alternative that he has encountered. The problem is this idea does not exist yet! Note: I know this is a super similar idea to the app and product "Brick". Notably, though, Brick does not have the ability for admin preset controls, or the admin dashboard. We reached out to the company to see if they're create this for us and they said it's a back burner idea that they're aware of, but it's not a priority for them right now. Thank you for any guidance!

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

We use Device Management Profile to restrict all apps from using camera on unsupervised devices. It works fine until iOS 26.1 beta. In iOS 26.1, only the camera icon is removed from Home screen, the third party apps can still use camera. In our scenario, the camera of employees' iPhones are disabled when they enter the factory and are restored when they leave. According to the documentation, disabling camera on unsupervised devices is deprecated. But supervision is not feasible option because these iPhones are owned personally by employees. Is there any new solution for camera restriction on unsupervised devices? Thanks.

I am needing to access the ABM API via C#. Searching has directed me to use BouncyCastle. I have downloaded the PEM file. However, using the following: using (var reader = File.OpenText(pemFilePath)) { var pemReader = new PemReader(reader); var keyObject = pemReader.ReadObject(); I get the error "problem creating EC private key: System.NullReferenceException: Object reference not set to an instance of an object."

We are expering frequent delays recently when associating a device serial with the adamid of an app in our business manager account. I get an event id back when calling the /associate api but when i check the status of that event id is can be sat in a pending state for sometimes several hours. Need to understand why and if its a configuration issue

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.

Why don't obtain equipment list (https://mdmenrollment.apple.com/server/devices) interface returns "device_family" contour information. This interface only returns some fields, and many field values are not returned

I'm writing to point out a potential structural error in an example of the DeclarativeManagement command. This could cause significant confusion for developers implementing the MDM protocol. The standard structure for a server-to-device MDM command requires CommandUUID and the Command dictionary to be siblings under the top-level dictionary. The CommandUUID serves as a top-level identifier for the entire command envelope. This is the correct, expected structure: <?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>Command</key> <dict> <key>RequestType</key> <string>DeclarativeManagement</string> </dict> </dict> <key>CommandUUID</key> <string>0001_DeclarativeManagement</string> </dict> </plist> This is an example of the incorrect structure I've seen: <?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>CommandUUID</key> <string>0001_DeclarativeManagement</string> <key>Command</key> <dict> <key>RequestType</key> <string>DeclarativeManagement</string> </dict> </dict> </dict> </plist>

There is a longstanding restriction payload for supervised iOS devices that disables "Erase All Content and Settings." We have been experimenting with supervised watches paired with supervised phones that have that payload applied, and yet "Erase All Content and Settings" remains available on the watch. Is this: – a) An error with our payload? Should we be sending something else? – b) A bug in watchOS supervision? – c) A deliberate design choice? If so, what is the rationale for preventing organizations from maintaining this very basic level of control over devices they may be configuring and dispatching into the field?

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!

I encounter a connection error with Apple Configurator v2.18 when, after making changes in macOS Sequel 15.6.1, I want to apply and transfer the changes to the iPhone icon layout in iOS 26: Apple Configurator v2.18 crashes and returns an error message: ‘Try the operation again. If it fails, quit the application, launch it again, and try again. [NSCocoaErrorDomain – 0x1001 (4097)]’ I have done some research, and it seems that this bug has been identified and fixed in Apple Configurator 2 v2.19 (Build 10434). Have you encountered this problem? Do you know where to find version v2.19? This fixed version does not appear to have been released yet, and Apple support has been unable to help me. Thank you all for your help.

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>

Hi everyone, I want to enable Single App Mode (SAM) for my custom app that’s installed on the device. However, my device is not supervised. Is there any way to: Enable Single App Mode without supervising the device? Any guidance or workaround would be appreciated. Thanks, Arnab Lahiri

Dear Apple Developer Team, Following the rollout of iOS 26.x and the introduction of the iPhone 17, we have identified a critical issue affecting Mobile Device Management (MDM) enrolment and restore operations. The issue appears to stem from the Device Management Profile configuration 'do_not_use_profile_from_backup' within Apple Business Manager (ABM), which currently defaults to False. This setting should be modified to True to ensure proper functionality. When the profile remains set to False, organisations leveraging MDM encounter repeated failures during device backup and restore operations. Specifically, restoring a supervised or managed device triggers a persistent MDM registration loop, effectively preventing deployment of iPhone 17 devices in managed environments. We recommend that Apple review and adjust the default Device Management Profile property within ABM to address this issue and restore full MDM compatibility for iOS 26.x and later.