Hey all, how long does bank account validation take typically? I have everything else in my paid agreement approved and showing active except the bank account. It says 24 hours but it has been over 3 days and there has been no progress.

We are experiencing an issue with Apple Business Manager (ABM) synchronization that is blocking our device management workflow. Issue Description: During the ABM sync process in our MDM, we receive the error: "ABM Terms and Conditions not signed." What We’ve Checked: Logged into the ABM portal as the Administrator and confirmed that the latest Terms and Conditions. Attempted to renew the ABM token on our existing server, but the same error message continues to appear in MDM. Tried creating a brand new ABM server integration, which also fails with the same error. We checked with our MDM provider and they shared the logs, response received from ABM. It says T_C_NOT_SIGNED. But we have already accepted all the new Terms in ABM. We would appreciate any help in resolving this issue or guidance on what steps to take next.

We are developing an MDM (Mobile Device Management) solution for device management purposes, and our current implementation process is as follows: 1. Configure DEP profile to obtain profile_uuid We configured a DEP profile with the following parameters to retrieve the profile_uuid: { "allow_pairing": true, "anchor_certs": [], "auto_advance_setup": true, "await_device_configured": false, "configuration_web_url": "", "department": "test define profile", "devices": ["MNWF07QD9M"], "is_mandatory": false, "is_mdm_removable": false, "is_multi_user": false, "is_supervised": true, "language": "zh", "org_magic": "", "profile_name": "Enrollment Profile - MNWF07QD9M", "region": "cn", "skip_setup_items": [ "Accessibility", "ActionButton", "Android", "Appearance", "AppleID", "AppStore", "Biometric", "CameraButton", "DeviceToDeviceMigration", "Diagnostics", "EnableLockdownMode", "FileVault", "iCloudDiagnostics", "iCloudStorage", "iMessageAndFaceTime", "Intelligence", "Keyboard", "MessagingActivationUsingPhoneNumber", "Passcode", "Payment", "Privacy", "Restore", "RestoreCompleted", "Safety", "ScreenTime", "SIMSetup", "Siri", "SoftwareUpdate", "SpokenLanguage", "UpdateCompleted", "WatchMigration", "WebContentFiltering" ], "supervising_host_certs": [], "support_email_address": "", "support_phone_number": "", "url": "https://mdmp.com/mdm/apple/enroll?shopId=1" } We sent a POST request to the /profile endpoint with the above payload, and the response returned the profile_uuid: 605FB5C274303C19189C9B99DCD3280D. 2. Assign the profile We sent a POST request to the /profile/devices endpoint, including the aforementioned profile_uuid and the target devices list in the request body. 3. Scan the device with Apple Configurator 2 We used Apple Configurator 2 to scan and enroll the target device. Issue Encountered After the device restarts twice, it fails to retrieve the mobileconfig file from the URL: https://mdmp.com/mdm/apple/enroll. We are using Nginx as the web server and have enabled access logging, but the logs show no incoming requests from the device to the /mdm/apple/enroll endpoint at all. Could you please help identify where we might have made a mistake in this process?

Hello, I’m facing an issue while trying to add iOS devices to Apple Business Manager (ABM) using Apple Configurator during enrollment. When going through the setup process, the device fails to complete enrollment and times out. I’ve tried it multiple times. The device does appear in ABM during the process and I am able to assign it to different MDM servers but since the setup times out and fails, the device is automatically released. I have tried this with multiple iOS devices and it times out on every single one of them. Steps attempted: Factory reset and re-enrollment of the device Ensured network connectivity is stable and tested on multiple Wi-Fi networks Tried the following process using Apple Configurator on Mac (wired): Created a Wi-Fi profile in Configurator Connected the iPhone via cable and used Prepare (manual configuration) Used the “MDM server” placeholder and trusted anchors (as recommended) Linked the device to the ABM organization Skipped Setup Assistant steps Attached the Wi-Fi profile, then prepared and wiped the device Verified that the device should appear in ABM Attempted to assign the device to my MDM in ABM Despite these checks, the enrollment process times out. I’m attaching a screenshot of the error for reference. Could someone advise what might be causing this timeout or how I can further troubleshoot this? Any guidance would be greatly appreciated. Thanks in advance.

Hi Apple Community, We are using Automted Device Enrollment to Enroll macOS Devices and we used to Create AutoAdmin, PrimaryAccount using the Command Account Configuration . As a Part of Primary Account Creation while testing we see that BootStrap Token is Escrowed to MDM, and SecureToken is Created to Primary Account. The Primary Account user will enable FileVault as part of our process. As Tested internally, we seen that SecureToken is escrowed to AutoAdmin only when BootStrapToken is escrowed to MDM By device and AutoAdmin logs in then. That too After FileVault Unlock Since we Sendout the Laptop to users to setup themselves there are no chances of AutoAdmin Login to occur. And it defeats the purpose of having the AutoAdmin Account in emergency situation to login into it from Login Window. Can someone confirm if this behavior is expected and what are the expectation and recommendations from Apple on when to use AutoAdmin Account. Is there any other ways to use AutoAdmin directly from LoginWindow Before To FileVault Disk Unlock

Hi everyone, I’m sharing this because I’ve been stuck with this issue for over two weeks, and I still haven’t found a solution — or received a meaningful response from Apple Support. A yellow banner has appeared on my account saying: “The Apple Developer Program License Agreement has been updated and needs to be reviewed.” But here’s the problem: I’ve already accepted the latest agreement long ago. When I log into both: App Store Connect Developer Portal …there’s no new agreement to accept, no prompt, no button — absolutely nothing new. The yellow banner simply refuses to go away, and it's preventing updates. I’ve already: Cleared cache & cookies Tried Safari, Chrome, Firefox Logged in from different devices/networks Verified that I am the Account Holder Reported the issue via Apple Developer Support (more than a week ago) Despite clearly stating the urgency of the matter, I’ve received no fix and no timeline. This is beginning to feel like developers’ time — especially for those who depend on timely releases — isn’t being taken seriously. So I’m writing here to ask: 🔹 Has anyone else encountered this same issue recently? 🔹 Is there any known workaround or fix? I’d appreciate any help or shared experience. Thank you.

Hi We've had an Enterprise Developer a/c for years. But last year they asked a bunch a questions to confirm we were a company. I answered them all and then it said it would review the answers. Were a big company and answered these questions before so just expected it to go through. Then our Enterprise Program a/c was up for renewal in April. But the money was never taken from the company cc and every expiry date the renewal date keeps moving forward a month. Its now been moved to Sep 2025. Either were getting April-Sep free or were going to be landed with a CC bill for 12+5 months soon. Anyone else seeing this. Is there an email or webpage for Enterprise a/c support? We have the money :)

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!

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!

I tried the new feature of macOS 26.0 com.apple.configuration.app.managed. A configuration and its activation are defined with the data like this. InstallBehavior: Install: Required License: Assignment: Device iOSApp: true AppStoreID: '1113153706' After distributing the configuration with DeclarativeDevicement MDM command, an error is notified via status channel app.managed.list. "managed": { "list": [ { "state": "failed", "declaration-identifier": "1424a813-113f-5de0-9a75-38bf64f22673", "identifier": "com.microsoft.skype.teams", "name": "Microsoft Teams" } ] } What am I missing in the settings? Thank you

Hi. I am writing a little MDM application. Despite the basic task (add a password for 'remove profile' button in settings), it seems I am stuck with a problem: When I try to enroll my device with enrollment.mobileconfig file, Apple Configurator app, I receive an error The profile “Enrollment Profile” could not be installed because it is invalid. Make sure the profile is valid and try installing it again. The original architecture of my .mobileconfig contains of two payloads (com.apple.security.scep , com.apple.mdm), and it works correctly. However, when I try to add a third payload of com.apple.profileRemovalPassword , I receive the error stated above. From logs collected on iPhone, here's what was found : Failed to parse profile data. Error: NSError: Desc : The profile “Enrollment Profile” is invalid. Sugg : A profile containing an MDM payload must be removable. US Desc: The profile “Enrollment Profile” is invalid. US Sugg: A profile containing an MDM payload must be removable. Domain : MCProfileErrorDomain Code : 1000 Type : MCFatalError Params : ( "Enrollment Profile" ) ...Underlying error: NSError: Desc : A profile containing an MDM payload must be removable. US Desc: A profile containing an MDM payload must be removable. Domain : MCProfileErrorDomain Code : 1000 Type : MCFatalError Extra info: { isPrimary = 1; } My main dictionary contains HasRemovalPasscode Also, I have tried playing around with PayloadRemovalDisallowed setting it to true and false, however, I keep getting the same error message. There is also a second error produced: Profile MCConfigurationProfile, version 1: Display Name: “Enrollment Profile” Description : “***” Identifier : *** UUID : *** Organization: *** Is Stub : No Locked : Yes Removal passcode present Encrypted : No Trusted : 0 Signed : No Device Type : 0 Payloads: Payload MCSCEPPayload, version 1 Description : “***” Identifier : *** UUID : *** Type : com.apple.security.scep Display name: *** Organization: *** Payload MCMDMPayload, version 1 Description : “***” Identifier : *** UUID : *** Type : com.apple.mdm Organization: *** Payload MCRemovalPasswordPayload, version 1 Identifier : com.examp Can't parse profile: <decode: missing data> The code for com.apple.profileRemovalPassword is taken from apple documentation (https://aninterestingwebsite.com/documentation/devicemanagement/profileremovalpassword) I have also tried the automatic way - creating it from Apple Configurator, so it is correct in terms of syntax 100%. Several important notes: Creating a fresh new profile with just password removal protection single payload allows to perform a download of the profile If I comment out the whole com.apple.mdm payload block, I will be able to download this profile on iPhone also The com.apple.mdm block is also valid by itself, and works correctly I have tried implementing other types of "dummy" payloads - for example com.apple.dock <dict> <key>PayloadType</key> <string>com.apple.dock</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.example.test.dock</string> <key>PayloadUUID</key> <string>22222222-3333-4444-5555-666666666666</string> <key>PersistentApps</key> <array/> </dict> And everything worked out fine. So my hypothetical conclusion out of these four notes might be in some type of interconnection between mdm and profileRemovalPassword, which isn't really listed anywhere? Or am I missing something ? Thank you in advance.

Hi Apple team and community, We’re currently integrating with the Apps and Books for Organizations API as part of our device management solution and would like to highlight a few critical points we've encountered — including a reliability issue, an enhancement suggestion, and a request for clarification on API rate limits. 1. Issue: Intermittent 403 Errors with stoken-authenticated-apps Endpoint We are encountering intermittent 403 Forbidden responses from the stoken-authenticated-apps endpoint. Approximately 30–35% of the requests fail with a 403 status code. These failures are inconsistent — the same request (using the same Content Token and Storefront) may succeed upon retry. All requests are properly authenticated and include the required Cookie and other headers as specified in the API documentation. This issue is impacting our ability to reliably fetch app metadata at scale, particularly in workflows. We’d like to know: Is this a known issue? Could it be due to a rate limit or token misconfiguration? Are any changes required on our end to avoid these failures? 2. Enhancement Request: Include externalVersionId in versionHistory Response The versionHistory extension currently returns: versionString releaseNotes releaseDate However, for Declarative Device Management (DDM) workflows such as App Pinning, we need the externalVersionId as well. Without it, we can't reliably correlate version metadata with the specific version ID required for pinning. Adding externalVersionId would: Enable precise version targeting during App Pinning Improve reliability and automation in managed deployments We request that Apple consider including externalVersionId in the versionHistory response to better support DDM-based app lifecycle management. 3. Rate Limit Clarification We found the following note in the Apps and Books for Organizations API documentation: "The Apps and Books for Organizations API limits the number of requests your app can make using a developer token within a specific period of time. If you exceed this limit, you’ll temporarily receive 429 Too Many Requests error responses for requests that use the token. This error resolves itself shortly after the request rate has reduced." While this confirms that a rate limit is enforced, there is no detailed information about the thresholds — such as the number of allowed requests per minute, hour, or day per developer token. To help us implement proper throttling and retry strategies, we request clarification on the following: What is the exact rate limit threshold per developer token? Are there per-endpoint limits, or is it a global cap for all requests using the token? Does the API return a Retry-After header when the limit is exceeded? What is the recommended backoff strategy for clients to follow when receiving 429 errors? This information would help us implement efficient throttling and error handling logic. Any insights from the Apple team or other developers who’ve encountered these issues would be greatly appreciated!

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?

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？

We are trying to develop an app that will be responsible for managing 5000+ managed iPads through Intune MDM. The user flow is to have a device locked to a single app when a user is not logged in, but to make the device available to other apps once a user is authenticated. We already tried UIAccessibility GuidedAccess Mode and autonomous single app mode but those were not sufficient due to our need to be able to toggle this from the background. When the device may be asleep. So another way we could achieve this functionality would be to control all app access under a launching mechanism. That way we could allow one app to be visible in our MDM configuration and try to access our business app through that using deep links. If this were to work, we would have to be able to hide an app and still make it launchable from the manager. Any ideas? Thanks

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.

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

We’re exploring the use of Apple’s Automatic Assessment Configuration entitlement for an iOS app currently in the proof-of-concept stage. We’re enrolled in the Apple Developer Program with an active subscription. Both the Account Holder and team members have accepted all relevant license agreements. However, when we try to access the entitlement request form at: 👉 https://aninterestingwebsite.com/contact/request/automatic-assessment-configuration/ We are immediately redirected to: 🚫 https://aninterestingwebsite.com/unauthorized/ This happens for all team members, including the Account Holder, so it doesn’t appear to be a role-specific permissions issue. The app is still in the proof-of-concept stage — there’s no App Store listing or App ID yet. We’re trying to confirm entitlement eligibility before proceeding further. Questions: Is an App Store listing or App ID required to access this request form? Are there any hidden prerequisites (account permissions, team roles, prior submissions, etc.) that need to be fulfilled? Has anyone here successfully submitted this form — and if so, what steps or conditions were required? Any guidance or shared experience would be greatly appreciated. Thanks in advance!

Hello, We are working with an iOS app that is distributed as a Public Unlisted App Store app. Our MDM allows us to import the app by URL, but when added this way, the app is marked as unmanaged in the inventory. Because of that, we cannot assign a Managed App Configuration payload to it in the normal way. What we are trying to achieve: Deliver a configuration profile to all enrolled devices before the app is installed. When the user installs the app from the MDM catalog, the app should immediately see the configuration values. Questions we’re hoping to clarify: Is it technically feasible to pre-provision a Managed App Configuration for an app in this scenario, by pushing a .mobileconfig profile to all devices? If yes, what would be the correct payload format and content of such a .mobileconfig file? We’ve tested a profile format we found here that uses com.apple.managed-app-config PayloadType and a ManagedAppConfiguration key with the bundle ID nested inside, but iOS reports this as “payload not recognized.” From what we understand, that may not be part of Apple’s schema. Any guidance from Apple or the community on whether this use case is possible (and, if so, what the valid profile format should look like) would be very helpful. Note: For a complicated company policy, at the moment we are not able to participate in ABM. Thanks in advance!

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?