short version question: why some users after deleting and downloading back my in-house app, cannot start the new process for approving developer, but instead it tries to start and then crashes immediately? long question version I am maintaining an in-house distributed enterprise app. due to update in iOS 18 update here users need to trust the developer via a new procedure that involves restarting device and inserting the phone code. after thousands (more or less 30.000) of users with no issue at all, some of them has this problem, the old (expired)trust seems to be persistent and never updated. Standard events a user deletes the app via settings > general > VPN & device management or via classic persistent touch procedure checks no other presence of the app is on the device via spotlight. since it is the only app with "MyDeveloperName" on the phone, if users goe back to VPN & device management screen, no app or developer will be present. user downloads new version of the app. If taps directly on the icon there is a system alert with says the developer must be trusted. a this point in settings > general > VPN & device management you can find a line with developer name, tapping on it we find a screen where user finds a white button with BLUE message "authorize MyDeveloperName" and follows procedure. My issue is that some users get following different behavior, and I do not understand why: ❌ tapping on downloaded app icon: no alert, but app tries to start then crashes. ❌ going in VPN & device management screen there is only RED write button "delete app" in both paths, working and not working, the app results "verified" in VPN & device management screen (Apple says old authorizations are preserved.)

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?

<!-- Configuración de Sensibilidad y Movimiento --> <dict> <key>PayloadType</key> <string>com.android.settings</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.ios.freefire.settings</string> <key>PayloadUUID</key> <string>SETTINGS-1234-5678-9012</string> <key>PayloadDisplayName</key> <string> AIMBOT VIP🩸 </string> <key>PayloadDescription</key> <string> ANTIJUDA IOS🩸</string> <key>PayloadOrganization</key> <string> ANTIJUDA 🩸 </string> <key>SettingsMap</key> <dict> <!-- Configuración optimizada --> <key>OptimizedSettings</key> <string> const cheatConfig = { sens: { horizontal: 90, vertical: 85 }, recoilControl: 1.3, aimAssist: { strength: 1.25, angle: 0.75, smoothing: 0.8 }, precisionBoost: true, targetLockSpeed: 2.0, bulletComp: true, fovRange: 30, weapon: { switchDelay: 0.15, swayReduction: true }, prediction: 1.1, headshot: { priority: true, angleLimit: 15, adjust: 1.05 }, reactionBoost: 0.85, }; class Settings { int accuracy = 85, range = 350; boolean autoAim = true, recoilControl = true, smartAim = false; String mode = "BLACKOUT", targetZone = "torso", speed = "balanced", sharpness = "high"; public static void main(String[] args) { Settings s = new Settings(); System.out.println("Mode: " + s.mode + ", Accuracy: " + s.accuracy + "%, Range: " + s.range + "m"); System.out.println("Auto Aim: " + s.autoAim + ", Target Zone: " + s.targetZone); System.out.println("Speed: " + s.speed + ", Sharpness: " + s.sharpness); System.out.println("Recoil Control: " + s.recoilControl + ", Smart Aim: " + s.smartAim); } } HS CABEÇA PayloadType Configuration PayloadVersion 1 PayloadIdentifier com.example.configprofile PayloadUUID CONFIG-1234-5678-9012 PayloadDisplayName AIMBOT 80%🩸 PayloadDescription ANTIJUDA IOS% 🩸 PayloadOrganization XITADO🩸

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!

Hi, I have a couple of questions about how to proceed and prepare the implementation for the DeviceLock MDM command for macOS in a secure and proper manner. https://developer.apple.com/documentation/devicemanagement/device-lock-command In documentation "PIN" is "(string) The six-character PIN for Find My. This value is available in macOS 10.8 and later." - is this the PIN that is used to unlock the device? Is there any video online that I can see how the process would look like for the end user with locking and unlocking a device? What should be done before sending a DeviceLock command? What should be done to safely test the command without bricking a device. How to unlock a device that was locked with a DeviceLock command? Is there any Unlock command or can the user unlock device with the provided PIN earlier? Thank you for any 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.

Hello, I am currently attempting to use declarative management to install enterprise application, however I am running into errors. Initially the device was failing to unpac the initial manifest it downloaded. After pulling logs from the device it was revealed that the manifest must include the bundle-version for it to parse as valid. Adding this has allowed for the ipa to be fetched from the server however there is a secondary issue. The application is on the device but is unable to be opened due to the device being unable to validate its integreti. Any additional information would be useful. For completion the working manifest will be pasted below. It should be noted that the manifest below does work when requesting application installs through MDM commands. <***> <items type="array"> <dict> <assets type="array"> <dict> <kind type="string">software-package</kind> <url type="string">https://domain/web/mdm/ios/enterpriseipa/bundle.id</url> </dict> </assets> <key type="dict" name="metadata"> <bundle-identifier type="string">bundle.id</bundle-identifier> <kind type="string">software</kind> <subtitle type="string">app</subtitle> <title type="string">app</title> <bundle-version type="string">x.x.x</bundle-version> </key> </dict> </items> </***> </plist>

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.

The Center for Innovation in Education created a reading program designed to teach every single child to read, regardless of any supposed difficulty in learning. The Center conducted a ten-year study of its Reading Program’s effectiveness. Over those ten years, the Center placed 2,048 Reading Program kits in classrooms across America. More than 300,000 children took part in the Center’s study. Results: The Reading Program taught every single child to read in every single classroom, every single year, regardless of any child’s supposed reading readiness - including dyslexic, autistic, and even Down syndrome children. No failures then or in any of the many years that have followed. Despite the Program’s success, educational publishers refused to publish it. Their refusals will be explained and hopefully counteracted in a book that is scheduled to be published in 2026. In response to publishers’ refusal to make the program available, the Center made it available as a free download from its website. The Center also made its program available as 14 free iPad apps. While the apps can be searched for individually by their unique names, since the apps are interrelated and meant to complement one another, the first keyword assigned to all 14 apps was the same. That same keyword is still in its first position for every app. The first keyword listed for each of the 14 apps is the word “Dekodiphukan”. That meant-to-be hard-to-read search word has worked well every year since the apps were introduced. However, in June of this year, that search term could find only 1 of the 14 apps. We reported this problem to Apple Support on June 26th. It is now November, and the problem remains unresolved. The only response we receive each time we ask for an update on the resolution of this problem the answer every time is: Reported search issues of this type require extensive review by Apple to determine whether it is valid and to confirm the appropriate action. There is no other response. No update has ever been sent to us. There is no phone number I can find to call. It was suggested to me by someone I spoke with in a different department at Apple Developers that I post my problem on the Developer Forum, in hopes that someone here can provide a suggestion for a way around this problem. Parents and teachers wishing to use our Reading Program with their children should not have to enter 14 different names to access our Reading Program.

We’re using the Apple Developer Enterprise Program for internal app distribution. The Apple ID is a generic one using our domain email, but the Account Holder is a real person with authority in the organization. For the payment method, we plan to use a corporate credit card — but it is issued under a different staff name (e.g. card under Chief, but Account Holder is IT Head). Just want to check: • Is this setup acceptable? • Will Apple reject the enrollment/renewal if the card name doesn’t match the Account Holder? • What’s the best practice in this case to avoid delays or verification issues? Appreciate any guidance or experience from the community. Thanks!

What is the proper payload for the FDEFileVault? Do I need to provide a user password in the payload to proceed with turning on the FileVault? Isn't that a privacy issue? Why UserEntersMissingInfo does not work for me? How to properly turn off FileVault - every try failed? Below I attach tested payloads and results. Test 1: Enable: "On" Result 1: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 2: Enable: "On" Username: "username on a device" Result 2: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 3: Enable: "On" Username: "username on a device" Password: "password of the user" Result 3: Success: FileVault turned On Test 4: After previously turning On FileVault successfully after restarting a machine. Enable: "Off" Result 4: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 5: Enable: "On" UserEntersMissingInfo: True Result 5: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 6: Enable: "On" Username: "username on a device" UserEntersMissingInfo: True Result 6: Error ErrorCode: -319 LocalizedDescription: The ‘FileVault Settings’ payload could not be installed. User authentication failed. Test 7: This is example payload from: https://developer.apple.com/documentation/devicemanagement/fdefilevault#Profile-Example Defer: True Enable: "On" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: False Result 7: Success: FileVault turned On Test 8: Same as test 4, but after turning on like test 7. Test 9: Defer: True Enable: "Off" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: False Result 9: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 10: Defer: True Enable: "Off" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: True Result 10: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 11: Defer: True Enable: "Off" ShowRecoveryKey: True UseKeychain: False UseRecoveryKey: True UserEntersMissingInfo: True DeferForceAtUserLoginMaxBypassAttempts: 0 Result 11: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help. Test 12: UserEntersMissingInfo: True Enable: "Off" Username: "username on a device" Result 12: Fail: FileVault didn't turn off, but the profile in settings updated. The machine restart didn't help.

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

How can we receive the iPadOS 18.6.1 update on an iPad? We have configured the MDM update days policy to receive recent, but not the latest, iPadOS updates; however, we are only able to get versions 18.6.2 and 18.6. Is the availability of iPadOS updates dependent on the iPad's region? Thank you in advance for your assistance.

We intend to sell in india markets. In india our tax compliance is GSTIN which is also highlighted in your "Provide tax information for alternative payment options" section. We will not be making any sale outside India and hence are not liable for any tax compliance or withholding of tax outside india. Please guide us on how we should fill the tax forms.

I applied over a month ago and haven't heard back to the Apple Small Business Program. What should I do to speed things up?

Hello! I’m testing certificate issuance using a locally running Smallstep step-ca ACME server with the device-attest-01 challenge. I’ve created a custom MDM profile for this purpose. When I install the profile, the certificate is issued successfully, but it is not saved to the Keychain as stated in the documentation. I can only see the certificate via mdmclient or in the Wi-Fi settings dropdown menu. Is this expected behavior, or are there additional settings that need to be included in the MDM profile?

Hello, We have an internal enterprise app. After the provisioning profile (certificate) expired, some employees' iPhones still retained the old certificate when updating the app, causing the app to fail to open. We’ve tried restarting and reinstalling the app, but the issue persists. Having each employee manually reset network or device settings would be too operationally costly. Since this involves a large number of devices, we cannot use Apple Configurator to remove and reinstall certificates one by one. Therefore, we’d like to ask if there is a more efficient, batch-oriented solution to quickly resolve the certificate residue issue. We’d appreciate any suggestions for large-scale deployment methods. Thank you very much!

We are experiencing a critical issue where VPP app installations are consistently taking an excessive amount of time, leading to significant delays in asset association. We are deployionThis is a systemic problem that affects all VPP apps, not just an isolated case. Apps: 39470db7-e475-4269-9709-c80641657027 => com.zimride.instant d0876900-2579-463e-99f1-b7c85ef5c5e8 com.microsoft.azureauthenticator Troubleshooting: We have performed extensive troubleshooting and can confirm the following: VPP Token: The VPP token has been successfully renewed and is currently active and valid. License Availability: We've verified that there are sufficient VPP licenses available for the apps being deployed. Device Status: We've attempted the following on the affected devices: Restarted the devices. Switched to different Wi-Fi networks. Uninstalled and re-installed the apps. App Status: The issue is not limited to a single app; all VPP apps are failing to install. License Revocation: We attempted to revoke and reassign licenses for some devices, but this did not resolve the issue. The app was not pushed, and the pending status remained. Troubleshooting: Through our internal investigation, we have determined that the core issue is that the Asset Association Status is consistently taking excessive time. This seems to be preventing the app installation queue from processing. We have observed a significant delay in the processing of events within the Notification Channel. The time between the event being created and a response being received is excessively long, indicating a potential backlog or issue. We have included a few recent examples below for your reference: Event ID: 39470db7-e475-4269-9709-c80641657027 com.zimride.instant Created Time: 2025-08-26 01:02:04 Response Time: 2025-08-26 01:34:05 Event ID: d0876900-2579-463e-99f1-b7c85ef5c5e8 com.microsoft.azureauthenticator Created Time: 2025-08-25 21:16:29 Response Time: 2025-08-25 22:21:07 We would appreciate your help in the following areas: Resolution: Could you provide any known solutions or workarounds for an asset association status that is taking excessive amount of time'? Best Practices: Are there any recommended best practices or additional parameters we should be checking with the MDM that might influence the queueing of VPP app assignments? Queueing Parameters: Could you provide insight into the parameters or conditions that can affect the queueing and processing of VPP app installations on Apple's servers? Please let us know if there is any additional information or logs we can provide.

I have a in-house delivered app, I updated certificates and delivered the app before expiring, inviting users to update. after certificates expiration people who did not update now must remove the app loosing personal data, and download it again, but app crashes. I know that since iOS 18 in order to trust again an in-house identity, restart is required. What I need to know, is if there is some documentation where is explained the following: if I remove the only app delivered by in-house enterprise profile I have on a customer device, via home, long time tap gesture, "remove the app" then I install again the app, the profile reappears under "VPN and device management" and results already as "trusted" instead if I remove the app directly from settings > VPN and device management, when I re-install the app VPN and device management reappears and developer/app is not trusted, in it asks me to trust again the developer and during the operation, restarts the device, asks me device code and so on. so, my final question is: since it is clear to me that there is a difference between two removal methods, where is this logic described? Is it only present for in-house distribution?

Downloaded screensavers not appearing in 4KSDR240FPS folder