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

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

I've installed two different profiles and having no issues using them until iOS 17, 18.0 (certainly for 17, but not so sure for 18). But after upgrading to 18.2 and even developer beta 18.3, installed profiles are not showing on the Setting / General / VPN & Device Management. So I can't even uninstall, also I can't reinstall unless I factory reset by iPhone, iPad and not using iCloud backups. First profile is DNS profile downloaded from website(NextDNS) and the second profile is made by my own, configuration for the cellular APN setting. (DNS setting is shown on the setting but there's no profile showing, I did not uninstalled or removed it) (Installing the custom celluar configuration profile failed, since it's already installed but just not showing as above) All happens on my iPad pro M1 12.9, ipad mini 2021, iphone 12 mini(18.3, else are 18.2), and iphone 16 pro max. Want to know if it's bug, and any resolution excluding factory reset and start using from scratch(It's very useless solution). Thank you.

Hello guys, I wanted to reach out to see if any of you have experienced or come across an issue we are facing in our organization. We are encountering a campus-wide problem where Macs are take an unusually long time to delete files on external drives formatted with ExFAT. We manage these Macs through Jamf Pro, and numerous policies are applied when the devices are enrolled. We have tested the issue in both scenarios—when the Macs are connected to the domain and when they are not—and the slow deletion persists in both cases. At this point, we are unsure whether the issue lies on our end or if it is related to the operating system itself. If anyone has found a fix or workaround for this problem, we would appreciate your input.

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

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 & 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 & 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.

Hello, We're testing the new allowedExternalIntelligenceWorkspaceIDs key in the MDM Restrictions payload on supervised iPads. According to Apple's documentation, this key expects an "external integration workspace ID", but it's not clear what this specifically refers to. We've tried the following IDs individually (one at a time, as documentation says only one is supported currently): OpenAI Organization ID ChatGPT user email Apple ID used in ChatGPT Google ID used in ChatGPT login The profile installs correctly via MDM and the key is set, but we want to confirm: What exactly is considered a valid "external integration workspace ID" for this key? Is there a way to verify that the restriction is working as intended on the device (e.g. does it limit specific integrations or apps)? Is there an official list of services that currently support this? Any clarification from Apple or other developers with experience on this would be very helpful. Thanks in advance.

I have enrolled a macbook through ADE to Apple School Manager and register it to the MDM service. Upon sending the initial DeclarativeManagement payload, the device return the client capabilities as below: "supported-versions": [ "1.0.0" ], "supported-payloads": { "declarations": { "activations": [ "com.apple.activation.simple" ], "assets": [ "com.apple.asset.credential.acme", "com.apple.asset.credential.certificate", "com.apple.asset.credential.identity", "com.apple.asset.credential.scep", "com.apple.asset.credential.userpassword", "com.apple.asset.data", "com.apple.asset.useridentity" ], "configurations": [ "com.apple.configuration.account.caldav", "com.apple.configuration.account.carddav", "com.apple.configuration.account.exchange", "com.apple.configuration.account.google", "com.apple.configuration.account.ldap", "com.apple.configuration.account.mail", "com.apple.configuration.account.subscribed-calendar", "com.apple.configuration.legacy", "com.apple.configuration.legacy.interactive", "com.apple.configuration.management.status-subscriptions", "com.apple.configuration.management.test", "com.apple.configuration.math.settings", "com.apple.configuration.passcode.settings", "com.apple.configuration.safari.extensions.settings", "com.apple.configuration.screensharing.connection", "com.apple.configuration.screensharing.connection.group", "com.apple.configuration.security.certificate", "com.apple.configuration.security.identity", "com.apple.configuration.security.passkey.attestation" ], "management": [ "com.apple.management.organization-info", "com.apple.management.properties", "com.apple.management.server-capabilities" ] }, "status-items": [ "account.list.caldav", "account.list.carddav", "account.list.exchange", "account.list.google", "account.list.ldap", "account.list.mail.incoming", "account.list.mail.outgoing", "account.list.subscribed-calendar", "device.identifier.serial-number", "device.identifier.udid", "device.model.family", "device.model.identifier", "device.model.marketing-name", "device.model.number", "device.operating-system.build-version", "device.operating-system.family", "device.operating-system.marketing-name", "device.operating-system.supplemental.build-version", "device.operating-system.supplemental.extra-version", "device.operating-system.version", "management.client-capabilities", "management.declarations", "screensharing.connection.group.unresolved-connection", "security.certificate.list", "test.array-value", "test.boolean-value", "test.dictionary-value", "test.error-value", "test.integer-value", "test.real-value", "test.string-value" ] }, "supported-features": { } } }, com.apple.configuration.softwareupdate.enforcement.specific couldn't be found. The macbook current OS version is 15.5 and it's supervised so looking at this, I assume it should include the Software Update:Enforcement:Specific capability? https://github.com/apple/device-management/blob/release/declarative/declarations/configurations/softwareupdate.enforcement.specific.yaml When I tried sending the payload to the device anyway the valid status is unknown

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!

Hey everyone, Is it possible and how to get Managed Apple ID (email) programmatically for user signed in to ipad through shared IPad feature ? It would be good to have MDM independent solution, I mean API call to MDM service is not acceptable for us. Maybe API call to ASM or ABM, or get that somehow on iOS device end... any advice ? Thanks in advance, Dima

I found a new Payload attribute LegacyAppConfigAssetReference in AppManaged introduced in iOs 18.4 beta. So I tried it, however no configuration is discoverted in the installed app. -- configuration { "Identifier": "8c2af0b6-5ae0-5927-a1cd-bab5e4148bb8", "Type": "com.apple.configuration.app.managed", "Payload": { "InstallBehavior": { "Install": "Required", "License": { "Assignment": "Device", "VPPType": "Device" } }, "AppStoreID": "535886823", "LegacyAppConfigAssetReference": "ac35558f-aefc-5faf-8f64-1faaff993b96" }, "ServerToken": "2abdc89492d89ca1a213ca61318ae0651c2b8de660c2847a44a3fb8ad9d9a8ad" } -- declaration/asset/ac35558f-aefc-5faf-8f64-1faaff993b96 { "Identifier": "ac35558f-aefc-5faf-8f64-1faaff993b96", "Type": "com.apple.asset.data", "Payload": { "Reference": { "DataURL": "https://i3-oreore-ios-mdm.azurewebsites.net/asset_files/eyJpZCI6IjNkOTg2YWVjNzQ1MWJiYWZlZjJmZGU1NmZmYmJlYjdkLnBsaXN0Iiwic3RvcmFnZSI6InN0b3JlIiwibWV0YWRhdGEiOnsiZmlsZW5hbWUiOiJFbmNvZGVkQ2hyb21lUG9saWN5RXhhbXBsZS5wbGlzdCIsInNpemUiOjMyMjUsIm1pbWVfdHlwZSI6ImFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbSJ9fQ", "ContentType": "application/plist" } }, "ServerToken": "7433f7c0c991a1943636ff7bd8949e88738c684ecbde347ac8a9c5b5c19dda14" } -- And the data type of the managed app configuration is application/plist http https://i3-oreore-ios-mdm.azurewebsites.net/asset_files/eyJpZCI6IjNkOTg2YWVjNzQ1MWJiYWZlZjJmZGU1NmZmYmJlYjdkLnBsaXN0Iiwic3RvcmFnZSI6InN0b3JlIiwibWV0YWRhdGEiOnsiZmlsZW5hbWUiOiJFbmNvZGVkQ2hyb21lUG9saWN5RXhhbXBsZS5wbGlzdCIsInNpemUiOjMyMjUsIm1pbWVfdHlwZSI6ImFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbSJ9fQ HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-age=31536000 Content-Length: 3225 Content-Type: application/plist Date: Tue, 18 Mar 2025 22:59:40 GMT X-Content-Type-Options: nosniff <?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>EncodedChromePolicy</key> <string>PD94bWwgdmVyc2lvbj0iMS4wIiA/PjwhRE9DVFlQRSBwbGlzdCAgUFVCTElDICctLy9BcHBsZS8vRFREIFBMSVNUIDEuMC8vRU4nICAnaHR0cDovL3d3dy5hcHBsZS5jb20vRFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCc+PHBsaXN0IHZlcnNpb249IjEuMCI+PGRpY3Q+PGtleT5BdXRvRmlsbEVuYWJsZWQ8L2tleT48ZmFsc2UvPjxrZXk+Q29va2llc0FsbG93ZWRGb3JVcmxzPC9rZXk+PGFycmF5PjxzdHJpbmc+aHR0cDovL3d3dy5leGFtcGxlLmNvbTwvc3RyaW5nPjxzdHJpbmc+WyouXWV4YW1wbGUuZWR1PC9zdHJpbmc+PC9hcnJheT48a2V5PkNvb2tpZXNCbG9ja2VkRm9yVXJsczwva2V5PjxhcnJheT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPlsqLl1leGFtcGxlLmVkdTwvc3RyaW5nPjwvYXJyYXk+PGtleT5Db29raWVzU2Vzc2lvbk9ubHlGb3JVcmxzPC9rZXk+PGFycmF5PjxzdHJpbmc+aHR0cDovL3d3dy5leGFtcGxlLmNvbTwvc3RyaW5nPjxzdHJpbmc+WyouXWV4YW1wbGUuZWR1PC9zdHJpbmc+PC9hcnJheT48a2V5PkRlZmF1bHRDb29raWVzU2V0dGluZzwva2V5PjxpbnRlZ2VyPjE8L2ludGVnZXI+PGtleT5EZWZhdWx0UG9wdXBzU2V0dGluZzwva2V5PjxpbnRlZ2VyPjE8L2ludGVnZXI+PGtleT5EZWZhdWx0U2VhcmNoUHJvdmlkZXJFbmFibGVkPC9rZXk+PHRydWUvPjxrZXk+RGVmYXVsdFNlYXJjaFByb3ZpZGVyS2V5d29yZDwva2V5PjxzdHJpbmc+bWlzPC9zdHJpbmc+PGtleT5EZWZhdWx0U2VhcmNoUHJvdmlkZXJOYW1lPC9rZXk+PHN0cmluZz5NeSBJbnRyYW5ldCBTZWFyY2g8L3N0cmluZz48a2V5PkRlZmF1bHRTZWFyY2hQcm92aWRlclNlYXJjaFVSTDwva2V5PjxzdHJpbmc+aHR0cDovL3NlYXJjaC5teS5jb21wYW55L3NlYXJjaD9xPXtzZWFyY2hUZXJtc308L3N0cmluZz48a2V5Pk1hbmFnZWRCb29rbWFya3M8L2tleT48YXJyYXk+PGRpY3Q+PGtleT5uYW1lPC9rZXk+PHN0cmluZz5Hb29nbGU8L3N0cmluZz48a2V5PnVybDwva2V5PjxzdHJpbmc+Z29vZ2xlLmNvbTwvc3RyaW5nPjwvZGljdD48ZGljdD48a2V5Pm5hbWU8L2tleT48c3RyaW5nPllvdXR1YmU8L3N0cmluZz48a2V5PnVybDwva2V5PjxzdHJpbmc+eW91dHViZS5jb208L3N0cmluZz48L2RpY3Q+PC9hcnJheT48a2V5PlBhc3N3b3JkTWFuYWdlckVuYWJsZWQ8L2tleT48dHJ1ZS8+PGtleT5Qb3B1cHNBbGxvd2VkRm9yVXJsczwva2V5PjxhcnJheT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPlsqLl1leGFtcGxlLmVkdTwvc3RyaW5nPjwvYXJyYXk+PGtleT5Qb3B1cHNCbG9ja2VkRm9yVXJsczwva2V5PjxhcnJheT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPlsqLl1leGFtcGxlLmVkdTwvc3RyaW5nPjwvYXJyYXk+PGtleT5Qcm94eUJ5cGFzc0xpc3Q8L2tleT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZTEuY29tLGh0dHA6Ly93d3cuZXhhbXBsZTIuY29tLGh0dHA6Ly9pbnRlcm5hbHNpdGUvPC9zdHJpbmc+PGtleT5Qcm94eU1vZGU8L2tleT48c3RyaW5nPmRpcmVjdDwvc3RyaW5nPjxrZXk+UHJveHlQYWNVcmw8L2tleT48c3RyaW5nPmh0dHA6Ly9pbnRlcm5hbC5zaXRlL2V4YW1wbGUucGFjPC9zdHJpbmc+PGtleT5Qcm94eVNlcnZlcjwva2V5PjxzdHJpbmc+MTIzLjEyMy4xMjMuMTIzOjgwODA8L3N0cmluZz48a2V5PlNlYXJjaFN1Z2dlc3RFbmFibGVkPC9rZXk+PHRydWUvPjxrZXk+VHJhbnNsYXRlRW5hYmxlZDwva2V5Pjx0cnVlLz48a2V5PlVSTEJsYWNrbGlzdDwva2V5PjxhcnJheT48c3RyaW5nPmV4YW1wbGUuY29tPC9zdHJpbmc+PHN0cmluZz5odHRwczovL3NzbC5zZXJ2ZXIuY29tPC9zdHJpbmc+PHN0cmluZz5ob3N0aW5nLmNvbS9iYWRfcGF0aDwvc3RyaW5nPjxzdHJpbmc+aHR0cDovL3NlcnZlcjo4MDgwL3BhdGg8L3N0cmluZz48c3RyaW5nPi5leGFjdC5ob3N0bmFtZS5jb208L3N0cmluZz48L2FycmF5PjxrZXk+VVJMV2hpdGVsaXN0PC9rZXk+PGFycmF5PjxzdHJpbmc+ZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPmh0dHBzOi8vc3NsLnNlcnZlci5jb208L3N0cmluZz48c3RyaW5nPmhvc3RpbmcuY29tL2JhZF9wYXRoPC9zdHJpbmc+PHN0cmluZz5odHRwOi8vc2VydmVyOjgwODAvcGF0aDwvc3RyaW5nPjxzdHJpbmc+LmV4YWN0Lmhvc3RuYW1lLmNvbTwvc3RyaW5nPjwvYXJyYXk+PC9kaWN0PjwvcGxpc3Q+</string> </dict> </plist> Please note that this example plist is the same content as is described here: https://www.chromium.org/administrators/ios-mdm-policy-format/ After applying the declaration, the app GoogleChrome is successfully installed but no managed app configuration seems applied. MDMAppManagement.plist in the sysdiagnose is like below: plutil -p logs/MCState/Shared/MDMAppManagement.plist { "metadataByBundleID" => { "com.google.chrome.ios" => { "Attributes" => { "Removable" => 0 } "flags" => 1 "source" => "Declarative Device Management" "state" => 7 } "com.microsoft.skype.teams" => { "Attributes" => { "Removable" => 0 } "flags" => 1 "source" => "Declarative Device Management" "state" => 7 } } } I also tried with our private apps and not applied... How can we use this feature or check the configuration is applied? Thank you,

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! 🙏

Recently, we have encountered some users who have been unable to open the enterprise signature application after upgrading to version 18.3.2, without an IPS file. Through system logs, we found that signature verification has occurred SecKeyVerifySignature failed: Error Domain=NSOSStatusErrorDomain Code=-50 "rsa_pub_crypt failed, ccerr=-7" UserInfo={numberOfErrorsDeep=0, NSDescription=rsa_pub_crypt failed, ccerr=-7} Waiting for the information, I will provide the obtained system logs below. The application package name that crashed is com. mobile. moa aa.txt new

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.

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.

When an iOS 26.0 device is prepared in supervised mode, wifi connection screen is showing when the device is restarted. This wifi connect appears always on restart. I have tried using Apple Configurator GUI and Command line (cfgutil) command. In both cases, The behavior Wifi screen is showing up on restart for supervised mode. Cfgutil command: cfgutil -C {Certificate} -K {Key} prepare --supervised --name {NAME} --host-cert {Certificate} --skip-all Note: In non-supervised mode and other iOS, the wifi screen is not showing. Apple Configurator version: 2.18 iOS version: 26.0 Device model: iPhone 11 and above. Anyone else facing this issue? Any help is super appreciated.

"If your app includes any links outside the app, or offers any in-app or other purchasing opportunities, make sure these are behind a parental gate" Super Awesome and Kidoz are proving with a parental gate on ad click and they also claim that all ads are manually approved (another criteria for ads in Kids apps). So these two are the only ad networks we can use moving forward. Or we can use ad networks like Admob as well? I dont intend not to be in Kids category - so leaving Kids category is not a choice.

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 have noticed that if we apply forceDelayedSoftwareUpdates in Restrictions profile, it causes ScheduleOSUpdates to fail or go into an invalid state. For example: On my iOS device, we have set the forceDelayedSoftwareUpdates to 90 days which removed the latest iOS update iOS 18.2 from the Software Updates section on the device. Post this, if I schedule an update for iOS 18.2 using ScheduleOSUpdateCommand, it fails to download. If I schedule the same without forceDelayedSoftwareUpdates, the update works as expected. Please help what could be the reason for this behavior as forceDelayedSoftwareUpdates should not block ScheduleOSUpdates.

The question: Is there any chance that Apple will integrate Intune SDK into Apple apps such as Mail or Calendar, or create Siri-compatible Intune SDK-integrated versions of Mail and Calendar? The reason for the question: My team has been asked by VIPs in our company (e.g. execs and board members) if Siri can be used with Outlook, and the only way is through Shortcuts or by adding the Outlook account to Mail. Both of these options would violate our security policies for these reasons: Since our company policy and federal regulations don't permit us to allow access to company resources on non-MAM-protected apps, we can't allow our users to login to the Mail app and make full use of Siri, due to the lack of MAM controls for Mail and Calendar. We only allow users to transfer data between policy-managed apps which have integrated the Intune SDK allowing us to enforce DLP and other security measures. The only way to enable Shortcuts would be to disable these security measures.