Downloaded screensavers not appearing in 4KSDR240FPS folder

Hi Apple Community, At WWDC25, introduced a native device migration feature with iOS/macOS 26 and Apple Business Manager that promises seamless migration from one MDM to another without wiping devices or manual re-enrollment. That said, while testing this in iOS/macOS 26 beta, we ran into an issue: the Wi-Fi settings deployed by the old MDM aren’t retained during the migration. This means devices lose Wi-Fi connectivity partway through, and users have to manually reconnect before the migration to the new MDM can continue. This interrupts what should be a smooth, hands-off process. We wanted to ask if this is a known issue or limitation with the current beta? Are there any recommended ways to avoid losing Wi-Fi profiles during this migration window? Will this improve in future updates so that the Wi-Fi connection is preserved or seamlessly handed off to the new MDM? Any tips, workarounds, or official guidance Apple can share on best practices for handling Wi-Fi profiles during ABM-native device migrations would be hugely appreciated. Added Feedback with FeedBackAssistant ID : FB20150763 Thanks in advance.

Hello, I have an Apple Developer Enterprise account, and Apple Support has already enabled MDM for my account. I successfully downloaded and installed my MDM Vendor Certificate (it shows up in Keychain as MDM Vendor: [My Company Name] with its private key). Here’s what I’ve done so far: Exported the Vendor Certificate + private key as a .p12, then converted to .pem and .key using OpenSSL. Generated an unsigned CSR with CN=com.apple.mgmt.External. using OpenSSL. Attempted to sign the CSR using: my Vendor certificate the Vendor private key Apple Worldwide Developer Relations (WWDR) intermediate certificate OpenSSL smime -sign command with DER output Problem: Every time I try to upload the vendor-signed CSR to the Apple Push Certificates Portal, I get an error (CSR rejected). Sometimes OpenSSL even fails with “unable to load certificates” depending on how the WWDR certificate is included. My Questions: What is the correct OpenSSL command and certificate chain Apple expects for signing the CSR? Do I need to include any additional intermediates besides WWDR? Is there an official Apple reference example for generating the vendor-signed CSR that the Push Certificates Portal will accept? Any guidance from the community (or someone who has successfully done this end-to-end) would be greatly appreciated. Thank you, Sergio Sanchez

Hello, this may not be the correct place to ask this question so I apologize in advance if this is the case. We are currently having some issues when attempting to restore device back ups via iCloud that where previously enrolled to our MDM solution, as upon the restore no app data seems to be persisted over (we have tested restoring the backup on the same device and we have been able to have data persist between wipes) On the initial device we have ensured that the restrictions allowCloudKeychainSync allowManagedAppsCloudSync are set to true, and can see that the initial devices back up has the app data backed up, yet despite this data is not persisted when restoring from back up on a new device. On the device where the back up was initially done when restoring the applications are applied but indicated that they must be re-installed via our management console, once the app has been uninstalled and reinstalled the old data does show up, when applied to the new device our mdm solution pushes down the app.managed config but the device treats it as a new install. Could this possibly be due to us using Device Licensing when assigning apps? Or is it due to the intial device only performing a token update request when restoring and the new device going through the entire checkin proccess? Both devices are provisioned via DEP, and applications where assigned initially via VPP Any insight on this would be useful (For reference this is an MDM solution of our own making so we are attempting to sus out if there is a configuration issue we could be overlooking).

Hello world! First post here. Developing my first app. It primarily targets supervised and MDM managed devices. A few questions: For supervised devices, is serial number available? I want to get the number and use it for app auto activation Is MDM required for supervised devices? Or, as long as a device is enrolled through Apple Business Manager? Which capacity shall I request for the app? Thanks so much!

Hello, this may not be the correct place to ask this question so I apologize in advance if this is the case. I am currently running into two specifc issues while continuing to implement the app.managed configuration which are quite frustrating and I will detail them below Unlike MDM where an application could be "reinstalled", by sending an install application command down for the same app DM does not have a similar mechanism which causes some issues as (while inconsistent) devices do not always respect the configuration sent down, and will not begin downloading VPP applications. They can be seen in the configuration when checking under VPN & Device Management but they do not return on a status report, alternatively and app will "install" but will have a cloud symbol next to it requiring a download (which I believe would be impossible on supervised devices without apple accounts/have restricted apple accounts associated to them). These apps are also reported incorrectly, as they return a managed response while being inaccessible. Both of these issues are solved by removing and reinstall applications (occasionally). Is there any easier way to trigger a re-install or is this the only way to trigger this? The Version element that can be optionally sent down does not seem to work (or if it does, does so inconsistently). A device will very happily download the application initially with the version element present, though when we detect an updated external ID from the VPP program and send down an updated configuration devices behave unexpectedly. Some have ignored it, some have responded back that a download has begun (with no download taking place and the application clearly still being the initial installed version as can be see in the apps page) or it just works, but there is not consistency. I realize a new UpdateBehavior object has been added to possibly handle this, but it is only supported in iOS 26 and above and there are plenty of people who do not have phones that can upgrade that far. Are there alternative ways to enforce an application update other than uninstalling and reinstalling the application without the version (or will sending down a config without a version after one was originally pinned force it to update to latest?) Kind Regards

Hi guys, I need to configure a VPN to work only for specific apps. I already have a supervised iPhone, and I’ve successfully configured the VPN, but right now it applies to the whole phone. I need it to work just for some apps. I tried using both Apple Configurator and iMazing, but I can’t find this option there.

Hello ! Currently, we have customers who use about 5,000 devices. In the case of ios26, the phone number is not acquired overall, and 18.x, 17.x, and 16.x are all acquired in half and not acquired in half. https://developer.apple.com/documentation/devicemanagement/deviceinformationcommand/command-data.dictionary/queries-data.dictionary It seems that it is the right behavior not to acquire it on the specification sheet. However, I wonder when it became impossible to acquire. (There are devices that can be acquired and devices that can't be acquired in the same os version.) Will the devices that are being acquired be blocked someday? When it was developed in 2019, it was in a state that could be acquired in full. I would also like to ask if there is an alternative way to get your phone number. Thank you.

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.

Hi there, We’re testing Declarative Device Management (DDM) for VPP app management and followed the latest declaration template here: https://github.com/apple/device-management/blob/release/declarative/declarations/configurations/app.managed.yaml Our goal is to enable VPP auto-updates via the declaration. The payload we’re using looks like this: "AppStoreID": "1231325957", "InstallBehavior": "{\"Install\": \"Required\", \"License\": {\"Assignment\": \"Device\"}}", "UpdateBehavior": "{\"AutomaticAppUpdates\": \"AlwaysOn\"}" } What we’re seeing Device A (no Apple ID signed into App Store): User can manually update the VPP app with the above declaration in place. ( The same user cannot update the app if UpdateBehavior is not in the declaration payload. Device B (Apple ID signed into App Store, and the same Apple ID doesn't have the above app purchased): User cannot manually update the same VPP app. The App Store shows the error seen when UpdateBehavior is absent: “ cannot be updated because it was refunded or purchased with a different Apple Account.” Also, in this case, the user has no way to purchase the (free) app by their own as the app shows as owned/managed by MDM server. We have to remove the declaration, let the user purchase the same app, then re-deploy the declaration to allow the user to click that "Update" button when a new version for that app is available. Additionally, we’re unsure about the criteria/timing for automatic VPP app updates under DDM. After a new version became available, we waited several hours but the app did not auto-update. Repro summary App: VPP, device-assigned license Declaration: AutomaticAppUpdates = AlwaysOn, install required Device A: not signed into App Store → manual update allowed Device B: signed into App Store → manual update blocked with “refunded/different account” error Auto-update did not occur after waiting several hours post-release Any guidance, confirmation of expected behavior, or tips on additional logging we should collect (e.g., specific App Store / MDM / DDM logs and subsystems) would be greatly appreciated. If this is a known issue or requires a Feedback Assistant report, we’re happy to file one. Thanks,

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)?