I'm currently implementing a managed app using the new AppConfig specification. I referred to Apple's official documentation: Specifying and decoding a configuration. Based on the example provided in the "Publish your configuration specification" section, I structured my application configuration plist like this: <?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>configuration</key> <dict> <key>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </dict> </plist> When I deployed this configuration via my MDM server, the server reported valid for the activation, configuration and asset (which is the plist), but the configuration did not reflect or apply within my app. My app was unable to retrieve these settings. After some troubleshooting, I found that removing the top-level <key>configuration</key> wrapper resolved the issue. The following plist structure successfully pushed the configuration to my app: <?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>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </plist> My question is: Is the inclusion of the <key>configuration</key> wrapper (as shown in the Apple documentation example) incorrect for the current AppConfig implementation? Or is this structure intended for a future release (e.g., iOS 26 or beyond) and the documentation implicitly refers to it, causing confusion for current implementation? Any clarification would be greatly appreciated! Thank you!

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.

Apple iPad Air device failing to enroll through ABM with "failed to retrieve configuration" error. This error occurs while reaching Apple ABM for fetching MDM server enrollment details. When we checked console logs when enrolling the device we found following error: ​default 13:54:07.229022+1000 teslad Error: Error Domain=MCCloudConfigurationErrorDomain Code=34004 "The cloud configuration server is unavailable or busy." UserInfo={NSLocalizedDescription=The cloud configuration server is unavailable or busy., CloudConfigurationErrorType=CloudConfigurationFatalError} default 13:54:07.229120+1000 Setup Service completed default 13:54:07.230096+1000 Setup Could not retrieve cloud configuration. Error: <Error domain: MCCloudConfigErrorDomain, code 33001>\ Feedback raised along with screenshot and console logs as well : FB17785513. Please analyse this issue and reply back to us.

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,

I want to install Chrome extension via configuration profile without user needing to go to System Settings and install profile manually. Can i install configuraation profile by making user only interact with my app?

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?

There could be a case where-in multiple transparent proxies might exist in the system (for ex., Cisco AnyConnect, GlobalProtect, etc). We want to know if there is a way to order transparent proxies so that the desired transparent proxy gets the request first. During our research, we found a resource which talks about ordering transparent proxies through MDM. https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy Using this reference, we tried to create a profile and push it through JAMF. Below is the profile that we created and pushed with JAMF. Property List - &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;TransparentProxy&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.paloaltonetworks.GlobalProtect.client.extension&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;1&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.cisco.anyconnect.macos.acsockext&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;2&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.mydomain.transparentproxy&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;3&lt;/string&gt; &lt;/dict&gt; &lt;/array&gt; We are not sure if this is the right way to create the profile, though JAMF is not throwing any error while pushing this profile. We see this profile on the local machine as "/Library/Managed Preferences/com.apple.networking.vpn-transparent-list.plist". Is there a way to know if the profile took effect and the order of transparent proxies has changed. Thanks in advance.

Hello, We are currently deploying Apple devices in our organization using Apple Business Manager (ABM) and are looking for a long-term self-hosted MDM solution. We initially considered MicroMDM, but since official support will end in December 2025, we are evaluating NanoMDM. I would like to confirm: Is NanoMDM a stable and production-ready option for long-term use with Apple Business Manager and Automated Device Enrollment (ADE)? Does NanoMDM support all essential features like: Supervision Remote wipe App deployment Configuration profiles Are there any limitations or known issues with using NanoMDM? Are there any other open-source or lightweight MDM solutions Apple developers recommend that are actively maintained? We are aiming for a reliable, secure, and future-proof self-hosted MDM setup. Any guidance or shared experience would be greatly appreciated. Thanks, Vijay Pratap Singh

I registered in this summer, uploaded 2 apps. But recently I decided to add iAP to my apps, everything is ready, in Xcode sandbox everything works fine, but when I uploaded new version to TestFlight to test, when I tap on the subscription it says something like "Product not found". (I have added subscriptions to the app, and added them to the version before submitting, also, this version is in status "awaiting developer release" so I can tap a button and this new version with iAPs will be on App Store. But im unsure what to do, because exactly this verified by Apple's version is not working in TestFlight.) In Business section of my Apple Developer Account in Agreements I only have agreement of free apps, but not about the paid apps. 
When I registered I used my (R)(us)sian passport, I think this is the reason that I simply don't even have the agreement of paid apps to accept it. 
I have multiple passports, and multiple EU debit cards. I emailed apple to change the location of my account (to another EU country), but they ghosted me. They sent me emails to upload documents about 4 or 5 times, every time I uploaded my another passport, got an auto email "thank you, we will write you in 2-3 days", but either they did not write me, or they said that the document is not in English (it isn't). 
What do I do? Also, to my situation, someone of my family has a company in (R)(us)sia, and I have in EU (Estonia). Maybe if nothing will work out with "Individual account", I should change to my company? And what is better EU or (R)(us)sian? 
Im new to this community, hope to hear an answer, or just an advice. Thank you!

I am a developer distributing an enterprise app. Recently, some users have intermittently encountered an error message on iOS 18.5 stating: "Unable to install this app because its integrity could not be verified." While the issue could not be reproduced on iPhone 15 / iOS 18.5, we have received reports that it does occur on the following devices: iPhone 14 / iOS 18.5, iPhone 14 Pro / iOS 18.5, iPhone 14 Plus / iOS 18.5, iPhone 16 Pro Max / iOS 18.5, Are there any known issues or recommended solutions regarding this behavior? Thank you in advance for your assistance.

Platform SSO not working on macos devices for zscaler application other app like safari / chrome working well. Need help from apple expert on the same. Environment : IDP : Entra ID MDM : Omnissa Workspace one UEM platform : macOS

Hi There Our app is used in the hospital field and receives remote APNS via the Notification Service Extension. We found a scenario where screen is on, our app is in background, if a "Critical" notification is displayed as a banner at the top of the screen, subsequent normal notifications will be suppressed and no sound will play. Only after the user swipes away the critical notification will the normal notification appear and play a sound. is this as expected? I could not find any document on such case from Apple. Thanks.

I'm using Apple's MDM protocol InstalledApplicationListCommand to get information about installed apps. From iOS/iPadOS 26, the app information obtained by InstalledApplicationListCommand includes information on all apps including system apps (apps that come standard with iOS/iPadOS). https://developer.apple.com/documentation/devicemanagement/installed-application-list-command I want iOS/iPadOS26 to get the same information as the app information I get from the previous iOS/iPadOS, and I want to exclude system apps from the app information I get with the InstalledApplicationListCommand. As a way to exclude system apps, you can use the app ID I'm thinking of a way to exclude anything that starts with "com.apple" (the Identifier key value of the InstalledApplicationListResponse.InstalledApplicationListItem object). As a way to exclude system apps, please tell us whether the above method is appropriate and whether there will be any problems in the future.

May I know the checking mechanism for the ios Provisioning profile? Is my Apple app distributed by MDM inside the organisation? If the Provisioning profile is expired , what is the behaviour when user run the App and how to perform the checking mechanism , is it performed at user client side device or Apple server via online access.

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.

We’ve run into what looks like a gap in how forceAirDropUnmanaged is enforced on iOS devices. Setup: Device: iOS 17.x (unsupervised, enrolled in MDM) MDM Restriction: forceAirDropUnmanaged = true Managed Open-In restriction also applied (block unmanaged destinations). Verified: from a managed app, the AirDrop icon is hidden in the share sheet. This part works as expected. Issue: When two iOS devices are brought close together, the proximity-initiated AirDrop / NameDrop flow still allows transfer of photos, videos, or files between devices. In this path, forceAirDropUnmanaged does not appear to apply, even though the same restriction works correctly in the standard sharing pane. What I’d expect: If forceAirDropUnmanaged is enabled, all AirDrop transfer paths (including proximity/NameDrop) should be treated as unmanaged, and thus blocked when “Managed Open-In to unmanaged destinations” is restricted. What I observe instead: Share sheet → AirDrop hidden ✅ Proximity/NameDrop → transfer still possible ❌ Questions for Apple / Community: Is this a known limitation or expected behavior? Is there a different restriction key (or combination) that also covers proximity-based AirDrop? If not currently supported, should this be filed as Feedback (FB) to request alignment between share sheet AirDrop and NameDrop enforcement? This behaviour introduces a compliance gap for organisations relying on MDM to control data exfiltration on unsupervised or user-enrolled devices. Any clarification or guidance would be greatly appreciated.

Hello, I’d like to clarify the technical limitations around app updates in an Apple School Manager (ASM) + MDM environment. Environment • iOS/iPadOS devices supervised and managed via Apple School Manager • Apps are distributed via ASM (VPP / Custom App) and managed by MDM • Apps are App Store–signed (not Enterprise/In-House) • Some apps include NetworkExtension (VPN) functionality • Automatic app updates are enabled in MDM Question From a technical and platform-design perspective, is it possible to: Deploy app updates for ASM/MDM-distributed App Store apps via a separate/custom update server, and trigger updates simultaneously across all managed devices, bypassing or supplementing the App Store update mechanism? In other words: • Can an organization operate its own update server to push a new app version to all devices at once? • Or is App Store + iOS always the sole execution path for installing updated app binaries? ⸻ My current understanding (please correct if wrong) Based on Apple documentation, it seems that: 1. App Store–distributed apps cannot self-update • Apps cannot download and install new binaries or replace themselves. • All executable code must be Apple-signed and installed by the system. 2. MDM can manage distribution and enable auto-update, but: • MDM cannot reliably trigger an immediate update for App Store apps. • Actual download/install timing is decided by iOS (device locked, charging, Wi-Fi, etc.). 3. Custom update servers • May be used for policy decisions (minimum allowed version, feature blocking), • But cannot be used to distribute or install updated app binaries on iOS. 4. For ASM-managed devices: • The only supported update execution path is: App Store → iOS → Managed App Update • Any “forced update” behavior must be implemented at the app logic level, not the installation level. ⸻ What I’m trying to confirm • Is there any supported MDM command, API, or mechanism that allows: • Centralized, immediate, one-shot updates of App Store apps across all ASM-managed devices? • Or is the above limitation fundamental by design, meaning: • Organizations must rely on iOS’s periodic auto-update behavior • And enforce version compliance only via app-side logic? ⸻ Why this matters In large school deployments, delayed updates (due to device conditions or OS scheduling) can cause: • Version fragmentation • Inconsistent behavior across classrooms • Operational issues for VPN / security-related apps Understanding whether this limitation is absolute or if there is a recommended Apple-supported workaround would be extremely helpful. Thanks in advance for any clarification

Hello folks, I stumbled upon a weird CNContact serialization problem. I use the Contacts framework to update the AIM field, which is one of the instantMessageAddresses within a single Contact. Here is the simplified code I used: func updateAIMFieldOn(contact: CNContact, aimValue: String) { do { guard let mutableContact = contact.mutableCopy() as? CNMutableContact else { logger.error("[CM] Couldn't update contact with aim \(aimValue)") return } var updatedAddresses = mutableContact.instantMessageAddresses updatedAddresses.append(CNLabeledValue(label: "", value: CNInstantMessageAddress(username: aimValue, service: CNInstantMessageServiceAIM))) mutableContact.instantMessageAddresses = updatedAddresses let saveRequest = CNSaveRequest() saveRequest.update(mutableContact) try CNContactStore().execute(saveRequest) logger.verbose("Contact's AIM updated successfully!") } catch { logger.error("Couldn't update contact") } } And after serializing the contact to data, and then deserializing, the contact got two AIM fields with the same value: X-AIM;type=pref:some:part:of_my_aim_value IMPP;X-SERVICE-TYPE=AIM;type=pref:some:part:of_my_aim_value Why does it work in this manner? Is it possible that ":" char causes that? Format of my aim username is {some:part:of_my_aim_value}. I didn't find any information in the docs. Thanks!

We are upgrading macOS (minor versions and potentially major versions) using a scripted approach: Install the InstallAssistant package via installer Trigger OS install via startosinstall On MDM-managed assets, OS update policies appear to prohibit or interfere with the update flow. The update often fails with startosinstall reporting “Helper tool crashed…” during the “Preparing” phase. Steps to Reproduce On an MDM-enrolled Mac with OS update restriction/deferral policies applied, run: sudo /usr/sbin/installer -pkg /Path/To/InstallAssistant.pkg -target / && echo 'MACOS_PASSWORD' | /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --stdinpass --user MACOS_USER Actual Result Package installation reports success, but startosinstall fails during preparation with: Standard Output installer: Package name is macOS15.7_SoftwareUpdate installer: Upgrading at base path / installer: The upgrade was successful. By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms. If you do not agree, press CTRL-C and cancel this process immediately. Preparing to run macOS Installer... Preparing: 0.0% Preparing: 0.1% ... Preparing: 24.9% Standard Error Helper tool crashed... notes.log Install.log is also attached. Questions for Apple / Ask: We suspect this crash is caused by MDM OS update restrictions/policies. We need Apple’s recommended method to perform macOS updates (minor + major) when MDM is present, especially in environments where update deferrals/restrictions may be configured.

Environment Devices: e.g., iPhone 12 mini, iPhone 16 (multiple units) OS: iOS 26 beta 2 and beta 4 (23A5297m) Distribution: Apple Enterprise Program (In-House), deployed via MDM InstallApplication Tooling: Xcode (latest available for iOS 26 betas) Summary Apps signed for Enterprise (In-House) distribution install successfully on iOS 26 betas via MDM, but terminate immediately on launch. The same builds run if installed from Xcode on the same devices. This is a regression from pre-iOS 26 versions where Enterprise builds installed via MDM launched normally. Steps to Reproduce Archive an iOS app and export for Enterprise (In-House) distribution. Deploy the .ipa via MDM using InstallApplication to a device on iOS 26 beta (e.g., 23A5297m). Tap the app icon to launch. Actual Result The app quits instantly on launch. System logs show launchd/runningboard errors, including NSPOSIXErrorDomain Code=85 (“Bad executable (or shared library)”): runningboardd(RunningBoard)[34]: Process start failed with Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" UserInfo={NSLocalizedDescription=Launchd job spawn failed} runningboardd(RunningBoard)[34]: Launch failed with Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" SpringBoard(FrontBoard)[35]: Bootstrapping failed ... NSUnderlyingError = { NSLocalizedDescription = Launchd job spawn failed; } Expected Result Enterprise-signed builds installed via MDM should launch as they did on iOS 25.x and earlier. Regression? Works on iOS versions prior to 26. Works on iOS 26 betas when installed from Xcode (developer-signed run). Fails only for Enterprise (In-House) builds delivered via MDM. Additional Notes / Possibly Related We also reproduced a similar failure mode with a minimal Safari Web Extension project: it installs and appears under Settings → Safari → Extensions, but enabling it and opening Safari produces: “ is no longer available.” Building a fresh project with a new bundle ID shows the same behavior on iOS 26 beta (23A5297m). Logs contain: Error occurred during transaction: The provided identifier "" is invalid. Running from Xcode (debug build) works. Workarounds None identified for Enterprise/MDM distribution. Only Xcode-installed builds run. Impact Blocks Enterprise deployment to our fleet on iOS 26 betas. Feedback / Attachments Included: sysdiagnose from an affected device, minimal Xcode project demonstrating the issue, Enterprise-exported app, and reproduction notes. Happy to share additional logs or perform targeted tests if needed. Request Can Apple confirm whether this is a known regression vs. a policy/validation change in iOS 26 for Enterprise/MDM installs? Any guidance on a short-term mitigation or build/signing change we can apply would be appreciated.