Hi Team, As per this documentation Handling NotNow Status Responses | Apple Developer Documentation, the last command that is delivered to the device on a connection should be the one that the device reported NotNow so that the device will automatically retry when it is ready to consume commands. Our question is it possible to have a fixed command which we can try at the end once all commands are tried and if device has reported NotNow for any of the commands. E.g. If there were 3 commands delivered to the device one by one SSO profile (com.apple.sso ) was delivered and device reported NotNow VPN profile (com.apple.vpn.managed) was delivered and the device reported NotNow DeviceInformation command was delivered and the device reported Acknowledged. As there were NotNow responses earlier, can we try a certificate profile(com.apple.security.pkcs1), with a dummy certificate payload, to ensure that the last command delivered to the device in this connection is responded with NotNow. Questions: Can we use a fixed command e.g. certificate profile(com.apple.security.pkcs1) as in above example to ensure the last command delivered to the device has NotNow response. Or is it better to try one of the commands which the device reported NotNow earlier. As in above example should we try the SSO or VPN profile at step 4 instead of the certificate profile? Following up to above, when a device reports NotNow for any profile installation command, can we say it will always report NotNow for certificate profile(com.apple.security.pkcs1) as well for all iOS and MacOS devices?

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.

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.

We’re looking for best practices to remotely update iOS apps that are deployed in Single App Mode (SAM) or Autonomous Single App Mode (ASAM), managed through MDM. Imagine a typical use case: an iPad installed as a self-service kiosk at an airport restaurant. We need to update the app periodically without: Displaying any prompts to the user Relying on the user to approve or initiate the update (since the device is unattended) Sending technicians onsite, as many devices are in remote locations MDM providers have stated, “This is how Apple handles it,” without offering a workable solution. We’re hoping someone here has experience or suggestions for: Seamless or silent app updates in SAM/ASAM Update workflows that avoid interruptions or user interaction Any proven strategies or automation options under MDM supervision Any insight or documented approaches would be greatly appreciated. Thank you!

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

We are moving to Apple Business Store for our b2b customers. On the "residential" apple store side there is testflight. What process would one test an app we provide to a b2b customer when using apple business store publishing? (I don't see any sort of test flight for apple business)

Hello, I am an iOS developer managing an MDM app. In this app, we are only using the camera restriction feature. Can the MDM status (specifically, the camera state) be changed while the user's screen is locked? We want to communicate with our server in the background and apply changes, but there is no known information about this. I would appreciate your help!

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.

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.

It's a great platform to grow your knowledge. Apple Teacher

Hello, I am trying to authenticate to the Apple Business Manager API to retrieve device information and ingest it into ServiceNow. I am following the documentation here. The first step is to create an API account and download the private key used to create a JWT client assertion. The guide linked above gives a python script to create a client assertion. Below the first python script, the following description is given for the "kid" variable: "The value is your keyId that returns when you upload a public key." This is the first time that a public key, rather than a private key, is referenced. Where is the public key supposed to be uploaded? Later in the guide, a public key is referenced again, in the section describing the client_id Request parameter: "(Required) You receive your clientId when you upload a public key." I have tried to create a client assertion using the keyId that is associated with the API account. When I try to request an access token, however, I also get an "invalid_client" error back. I am wondering if I'm using the wrong values for both key_id and client_id due to not creating and uploading a public key. Any help would be appreciated, 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?

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.

As we know, we can't add restrictions payload in the mobileconfig when registing the device. We are developing MDM by ourselfs, met some trouble. Please help.

Background / Objective We are currently developing a solution to centrally manage Apple OS updates (major and minor) across managed macOS devices. Before implementing at scale, we need Apple’s guidance on supported and future-proof update mechanisms under MDM. Questions / Ask (Apple Guidance Requested) Apple recommended method What is Apple’s recommended approach to perform: Minor updates (e.g., macOS X.Y → X.Z) Major upgrades (e.g., Ventura → Sonoma) in an enterprise fleet? Support boundary Is macOS update management only supported via MDM (including any newer declarative workflows), or are local mechanisms (installer + command-line tooling) also considered supported for enterprise automation? Use of startosinstall Can we leverage the existing utility: /Applications/Install macOS .app/Contents/Resources/startosinstall for automated upgrades in enterprise environments? If yes, are there recommended flags/workflows Apple endorses for unattended or minimally interactive upgrades? Long-term support / stability Does startosinstall have any form of long-term support / stability guarantees across future macOS releases? Are there any known deprecations planned (or guidance that customers should transition to MDM/DDM workflows)? MDM interaction / interference When using startosinstall, can MDM policies (software update deferrals/restrictions, update enforcement, etc.) interfere with or block the upgrade? If interference is expected, what is the correct supported way to coordinate: MDM software update settings local startosinstall execution to avoid failures and ensure compliance? What We Need From Apple (Desired Outcome) A clear statement of recommended and supported update workflow(s) for enterprise managed macOS: for minor updates for major upgrades Guidance on whether startosinstall is acceptable for long-term automation, or whether we should only use MDM/DDM-driven workflows. Any best practices or reference documentation Apple recommends for implementing this safely and reliably.

Hi, I developed a Platform Single Sign-On extension and a corresponding extension for my IdP, which is Keycloak based. The code for both projects are here: https://github.com/unioslo/keycloak-psso-extension and https://github.com/unioslo/weblogin-mac-sso-extension I realized that, when using the Secure Enclave as the AuthenticationMethod, and according to Apple's documentation, the Extension doesn’t obtain fresh ID Tokens when they expire if the refresh token is still valid. When using password as the Authentication Method, it fetches new ID tokens when they expire, without prompting the user for credentials, by using the refresh token. My suggestion is that the same behavior should be implemented for Secure Enclave keys. The thing here is that usually, on OIDC flows, the ID/Access tokens are short-lived. It would make sense for the extension to provide fresh ID tokens. It doesn’t seem to make sense for me that, when using passwords, the extension would fetch these tokens, and not when having the Secure Enclave key. By not doing this, Apple almost forces the developer of an extension to fetch new ID tokens themselves, which doens’t make sense when it clearly provides fresh tokens when using passwords. It almost forces the developers to either implement that logic themselves, or to issue longer tokens, which is not so nice. How so you deal with this? Do you simply use the refresh token as an authentication token, or do you do some sort of manual refresh on the extension?

The result Plist for the InstalledApplicationList MDM command is reporting duplicate Application identifiers. Sometimes with different version, other times with the same version. The device is MacOS 15.5, Enrolled via ABM (Supervised). Here are a couple samples from the returned list. Duplicate app: <key>BundleSize</key> <integer>398051</integer> <key>Identifier</key> <string>com.adobe.Acrobat.NativeMessagingHost</string> <key>Installing</key> <false/> <key>Name</key> <string>NativeMessagingHost</string> <key>ShortVersion</key> <string>5.0</string> <key>Version</key> <string>5.0</string> </dict> <dict> <key>BundleSize</key> <integer>398051</integer> <key>Identifier</key> <string>com.adobe.Acrobat.NativeMessagingHost</string> <key>Installing</key> <false/> <key>Name</key> <string>NativeMessagingHost</string> <key>ShortVersion</key> <string>5.0</string> <key>Version</key> <string>5.0</string> </dict> Different Version: <key>BundleSize</key> <integer>4197200</integer> <key>Identifier</key> <string>com.adobe.adobe_licutil</string> <key>Installing</key> <false/> <key>Name</key> <string>adobe_licutil</string> <key>ShortVersion</key> <string>11.0.0.39</string> <key>Version</key> <string>11.0.0.39</string> </dict> <dict> <key>BundleSize</key> <integer>4443177</integer> <key>Identifier</key> <string>com.adobe.AcroLicApp</string> <key>Installing</key> <false/> <key>Name</key> <string>AcroLicApp</string> <key>ShortVersion</key> <string>25.001.20432</string> <key>Version</key> <string>25.001.20432</string> </dict> <dict> <key>BundleSize</key> <integer>7380980</integer> <key>Identifier</key> <string>com.adobe.adobe_licutil</string> <key>Installing</key> <false/> <key>Name</key> <string>adobe_licutil</string> <key>ShortVersion</key> <string>10.0.0.274</string> <key>Version</key> <string>10.0.0.274</string> </dict>

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.

I'm hoping to make certain in-house apps fail to launch by revoking the in-house certificate that they were built on. This is by way of encouraging users of these apps to download updates built on a new certificate. How long will it take app built on a now-revoked certificate to no longer launch? Also, what is Apple's process for checking the validity of an in-house certificate in an app built on that certificate, running on iOS devices? I understand that provisioning profiles have built-in expiration dates, but will an in-house app that's built on a valid provisioning profile keep running even on a revoked certificate if the revocation happened before the certificate's own expiration date? Craig Umanoff

Attempts to programmatically update or add numerous system-installed certificates (a common practice for organizations that rotate certificates regularly) are blocked, forcing manual, insecure, and error-prone workarounds. The root cause lies in the stricter security protocols implemented in macOS 15, specifically: System Integrity Protection (SIP) and Transparency, Consent, and Control (TCC) Command we are using : sudo security authorizationdb write com.apple.trust-settings.admin