I represent a 501C3 non-profit in the United States. We are a small organization and sell books and other items to students and teachers. Would we qualify for a waiver of the $99 fee?

We are experiencing an issue with Privacy Preferences Policy Control (PPPC) profiles deployed through Jamf Pro on the Golden Gate beta. We use the following Jamf configuration profiles to pre-approve Digital Guardian Accessibility permissions: DG – Grant Accessibility Access to DgSessionSvc.app DG – RME These profiles are intended to grant Accessibility permissions automatically for Digital Guardian under: System Settings → Privacy & Security → Accessibility On macOS Tahoe and macOS Sequoia, these PPPC profiles work as expected. After deployment, the required Accessibility permissions are granted automatically and users are not prompted. However, on the Golden Gate beta, the same configuration profiles are installed successfully, but the required Accessibility permissions are not granted. As a result, users continue to receive the Accessibility permission prompts. We also observed a difference when inspecting the installed profile under: System Settings → General → Device Management → Profile On macOS Tahoe, the installed profile contains the following entry: Control the Computer — com.verdasys.DgSessionSvc — Allowed On the Golden Gate beta, this entry is missing, even though the identical Jamf PPPC profile has been installed successfully. For reference, we have attached: The Jamf PPPC configuration profiles (.mobileconfig) DGSessionSvc MobileConfig RME MobileConfig Comparison screenshots from macOS Tahoe and the Golden Gate beta Could you please confirm whether this is: a known issue in the Golden Gate beta, an intentional change in PPPC behavior, or an issue with our PPPC configuration profile? If this is an operating system issue, we would appreciate it if it could be investigated and addressed in a future Golden Gate beta release. Environment Affected OS: Golden Gate 27.0 Beta (26A5388g) Working OS versions: macOS Tahoe and macOS Sequoia MDM Solution: Jamf Pro 11.30.1 Affected Application: Fortra Digital Guardian Required Permission: Accessibility (Control the Computer) Architecture: Apple silicon We would also appreciate it if you could review the attached .mobileconfig files and let us know whether any modifications are required to make the PPPC profiles compatible with the Golden Gate beta, or if any additional information would be helpful for your investigation.

We have an Apple Watch app and companion iPhone app that we distribute via Enterprise Distribution using OTA manual installation. (We are on an Apple Enterprise Developer Team) With WatchOS 26.4 and earlier, the app would install fine on both the phone and the watch. However, after updating to WatchOS 26.5 (and iOS 26.5), the app will not install on the watch. It will install on the phone and we can trust the developer/run the phone app. However, when we go into the Apple Watch app on the phone and choose "Install" for the app, it tries to install for a minute and then returns an error "The app could not be installed at this time". We have tried the following remedies: Restarting both watch and phone, and reinstalling the app on phone Factory resetting both the watch and the phone, then reinstalling app Generating a new Distribution Certificate and new manual profiles for the app in Apple Developer Looking through console logs from both the phone and the watch Confirmed that we can install other (non-Enterprise) apps on the watch Try installing a basic example app (the default Xcode watch + companion app project) There does not seem to be anything obviously amiss about the app or its packaging, it seems to be something to do with the update to WatchOS 26.5. The closest related errors we have found seems to be these: appconduitd 0x16d43f000 -[ACXInstallQueue _onQueue_deQueueNextOperation]_block_invoke_3: Failed to install app .EnterpriseInstallTest.watchkitapp (p = Y, ui = Y) : Error Domain=ACXErrorDomain Code=8 "Failed to create socket" UserInfo={NSUnderlyingError=0xcf9138e10 {Error Domain=com.apple.identityservices.error Code=20 "Socket open timed out" UserInfo={NSLocalizedDescription=Socket open timed out}}, FunctionName=-[ACXServerInstallOperation _onQueue_prepForTransferAndInstall]_block_invoke, SourceFileLine=370, NSLocalizedDescription=Failed to create socket} appconduitd 0x16d89f000 -[ACXCompanionSyncConnection _installQueuedOrCompletedForWatchBundleID:companionAppBundleID:withName:userInitiated:withError:withCompletion:]_block_invoke: Failed to install app .EnterpriseInstallTest.watchkitapp : Error Domain=ACXErrorDomain Code=8 "Failed to create socket" UserInfo={NSUnderlyingError=0xcf9138e10 {Error Domain=com.apple.identityservices.error Code=20 "Socket open timed out" UserInfo={NSLocalizedDescription=Socket open timed out}}, FunctionName=-[ACXServerInstallOperation _onQueue_prepForTransferAndInstall]_block_invoke, SourceFileLine=370, NSLocalizedDescription=Failed to create socket}

We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.

I'm the IT Admin in my company. We use Microsoft Intune, which is a Mobile Device Management tool, to manage our devices and apps. I created an app protection policy, restricting the data can only be shared between the allowed apps. For example, if our user want to copy the content in Outlook for iOS to WeChat or personal memo, the action will be blocked. However, may be it's too strict, here is the scenario that we need to hadle: A user selected the content in the Outlook for iOS mail, and wanted to use the "translate" function to do translation. Before the app protection policy was deployed, he can do the translation successfully. And now, it's blocked. Therefore, we need to find a way to exempt the app "Translate" so that users can do the translation successfully. We put the value "com.apple.Translate"(this is a package ID listed in the official document of Apple) to the exemption, but it's not working. May I know what is the correct "value" for the iOS native Translate APP? I need to put this value to our app protection policy to exempt Translate app. Thank you so much.

Topic: App Store Small Business Program Application - Pending Review Submission Date: April 22 Most Recent Support Case ID: 102935711794 Hi everyone, I submitted my application for the App Store Small Business Program back on April 22. It has been over 3 months without any status update or confirmation. I have checked my Agreements, Tax, and Banking page in App Store Connect to ensure all contracts (including the Paid Applications Agreement), tax documents, and banking information are active and fully up to date. There are no pending actions required on my end. I have submitted 5 separate support inquiries through the Developer Contact portal regarding this delay, but I have not received a resolution or progress update. Could an Apple Staff member or moderator please assist in escalating my Team ID and Case IDs to the Agreements & Contracts Operations team so my enrollment can be reviewed? Thank you!

I have so far been unable to enrol a macOS 27 beta VM in to Jamf since initial beta release. Is this by design? I can’t find any documentation or posts on apple developer forums about this anywhere. My agentic coding session has done some probing around in the VM and it thinks something is going wrong with Secure Keychain within the VM. Everybody on my team is observing the same behaviour as this, and I’ve had it happening across two different laptops (one of them which is, itself, running the latest macOS 27 Beta, and the other which I created a Beta VM by installing Tahoe in the VM, logging in to iCloud, and enabling Beta channel updates) The only thing we’ve found we can do so far is to join to Jamf in Tahoe first, but the problem I have there is, often times the option for Beta channel updates just doesn’t present itself in System Settings -> Software Update after signing in to iCloud, and I don’t know why it sometimes does but often doesn’t. Logs from agentic coding session below: The core log evidence This is the whole causal chain, from the 27 guest's unified log, inside 370 microseconds. Innermost failure first: 05:24:04.967316 apsd: (CryptoTokenKit) [com.apple.CryptoTokenKit:sepkey] <sepk:* kid=0000000000000000>: (apsd) unable to generate key: error e00002e2(-536870174) ACL=<SecAccessControlRef: dk;ock(true);odel(true);osgn(true);oa(true);okd(true)> 05:24:04.967433 apsd: (Security) [com.apple.security:seckey] SecKeyCreateRandomKey_ios failed: NSOSStatusErrorDomain Code=-25308 "Failed to generate keypair" (errSecInteractionNotAllowed / Interaction is not allowed with the Security Server.) 05:24:04.967574 apsd: (DeviceIdentity) com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967600 apsd: [com.apple.apsd:courier] APSBAAClientIdentityProvider failed to obtain a BAA cert, error: com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967686 apsd: [com.apple.apsd:courier] <APSCourierConnectionManager; production>: Stream error occurred for : APSErrorDomain Code=1 "Told not to connect after fetching server bag: (null) - closing stream" Read bottom-up: Secure Enclave key generation fails, so MobileActivation cannot create the reference key, so apsd cannot obtain its BAA device-identity certificate, so APNs tells it not to connect. kid=0000000000000000 means there is no key id at all. Then every courier line reports Connected on 0 interfaces, and mdmclient sets its PushWakeTopics only to get Connection Invalid for service com.apple.apsd and tear down. The command to regenerate it: log show --predicate 'process == "apsd"' --last 60m --info | grep -iE 'BAA|unable to generate key|server bag'. New control, collected just now mac26 happened to be running, so I got the comparison. macOS 26.6 (25G72) guest, same host, same network, 3 days uptime: BAA_FAILURES: 0 SEPKEY_FAILURES: 0 APNS_SOCKETS: 192.168.64.8.52286 -> 17.57.146.7.443 ESTABLISHED 192.168.64.8.52285 -> 17.253.77.203.443 ESTABLISHED (+ 3 more into 17.0.0.0/8) No BAA or courier complaints at all over 6 hours, and live connections into Apple's network. So a virtualised guest per se is fine; the 27 guest specifically cannot mint the key. The physical host, also on macOS 27.0, likewise logged zero of both failures over 3 hours.

We develop a third-party endpoint security agent (DLP / device control). It needs kTCCServiceBluetoothAlways to enumerate paired Bluetooth devices and disconnect them selectively based on policy — without user interaction, since this runs unattended on managed fleets. Until recently we granted this silently via a com.apple.TCC.configuration-profile-policy (PPPC) profile pushed by MDM, or by writing directly to the TCC database — the latter no longer possible starting with macOS 27 (Golden Gate). As of macOS 27, tccd also ignores the PPPC profile approach: Override: skipping kTCCServiceBluetoothAlways ... as it is defined in deprecated PPPC profile As a result, end users now hit the standard Bluetooth access consent popup, which we have no way to suppress or pre-answer with Allow. ** Questions: ** Is there any currently supported MDM mechanism — profile-based, DDM, or otherwise — to pre-approve kTCCServiceBluetoothAlways for a specific managed app, so the popup never appears? If direct pre-approval is gone for good, is there any supported way to auto-answer the popup on the user’s behalf via policy (as exists for some other TCC services)? Is this now permanently interactive by design, or is a replacement mechanism planned for MDM-managed Bluetooth access?

Hi everyone, We are currently preparing to submit an enterprise MDM (Mobile Device Management) agent/client application to the App Store. We would like to seek advice or best practices from the community and Apple engineers on how to handle the App Review process for this type of application. https://postimg.cc/kBLFWB3t Our production workflow is as follows: The target device is enrolled into our MDM server. The server then deploys our agent app to the device, attaching its ManagedAppConfiguration payload during installation. The app is launched and successfully reads the configuration. If the app is launched standalone (without being deployed and configured by our MDM server), it naturally starts in an "Unconfigured" state and displays "Application not configured. Please register your device or contact the administrator." Since App Reviewers do not enroll their test devices into our MDM server, they will only see the "Unconfigured" screen when launching the app during the review. Our questions are: How does the App Review team typically evaluate the complete functionality of an MDM agent app in this scenario under Guideline 2.1 (App Completeness)? What are the recommended practices or setup requirements for developers to prepare? (e.g., Is providing an offline/demo sandbox mode inside the app, or providing an end-to-end walkthrough video of the active management workflow, the standard way to satisfy the review?) Under Guideline 5.5 (Mobile Device Management), what specific verification materials or organizational documentation should we prepare in App Store Connect to demonstrate that our application is an authorized commercial MDM solution? We would highly appreciate any guidance, shared experiences, or official best practices. Thank you!

Hi everyone, I'm hoping someone has experienced a similar issue. My Apple Developer Organization enrollment has already been approved, and my developer account now shows my organization as "(Pending)". On July 15, 2026, I received the following email: "Thank you for your order. Here's a summary of your order request, which will be processed within 2 business days." However, it has now been over a week, and nothing has changed. Current status: My credit card has not been charged. I have not received a payment receipt. I have not received a membership activation email. My developer account still displays: Purchase your membership To continue your enrollment, complete your purchase now. Your purchase may take up to 48 hours to process. I have already contacted Apple Developer Program Support. Case ID: 102945548446 Support history: Email with Apple Developer Support — Saturday, July 18, 2026 (GMT+7) Follow-up email with Apple Developer Support — Wednesday, July 22, 2026 (GMT+7) Unfortunately, I have not yet received a response from the support team. I also have one question regarding the payment. The organization owner is a different person, but the credit card used to purchase the Apple Developer Program membership is under my name. Could this affect the membership purchase process, or should the cardholder's name not matter as long as the payment method is valid? Has anyone experienced a similar situation? Is this a known billing issue? Could the order be stuck in Apple's payment processing system? Should I continue waiting, or should I contact Apple again? Any advice or shared experiences would be greatly appreciated. Thank you!

We are seeing a startup issue with in-house enterprise iOS apps on iOS 27 Developer Beta. We would like to understand whether this could be related to changes in iOS 27 Developer Beta startup validation, code signing validation, provisioning profile validation, certificate chain validation, entitlements, embedded frameworks, enterprise developer trust state, or device-specific launch behavior. This issue blocks our enterprise app compatibility validation on iOS 27 Developer Beta, especially on iPhone 11 and iPhone 12 devices. If this is a known beta issue, we would appreciate confirmation from Apple and any available fix plan or workaround. Symptoms: After installing the same enterprise app, some iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta cannot launch it correctly. There are two visible behaviors: When launched from the Home Screen icon, the app stays on the Launch Screen. The normal app UI never appears. When launched from Spotlight/Search, the app crashes immediately. Additional observations: iPhone 13 and later devices do not show this issue. Other enterprise apps distributed with the same provisioning profile or provisioning setup show the same behavior. This makes the issue look less like a single app's business logic problem and more like an iOS 27 Developer Beta validation, trust, or launch-time behavior difference on specific device models. We added logs and breakpoints at the earliest possible app startup points, including main, AppDelegate, SceneDelegate, and before crash-reporting SDK initialization. On affected devices, none of these logs are printed. Based on this, it appears that our app code is never reached. The failure seems to happen before iOS transfers control to the app, possibly while launching the process or loading the app binary/frameworks. Our current suspicion is that the failure may happen during one of these system-level steps: Enterprise code signing validation embedded.mobileprovision validation Certificate chain validation Enterprise developer certificate trust validation Mach-O / embedded frameworks / dynamic libraries loading Entitlements validation Bundle ID / App ID / provisioning profile matching Reuse of stale local enterprise trust, provisioning, or signing validation state on the device Temporary workaround observed: We found a temporary workaround on affected devices: Completely uninstall the existing enterprise app from the device. Download and install the app again. Trust the enterprise developer certificate again in Settings. Launch the app again. After doing this, the app can start normally on the affected iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta. The Launch Screen hang and Spotlight/Search crash no longer reproduce. This suggests that the IPA itself may not be permanently invalid, and the issue may not be caused by app business logic. It may instead be related to stale or invalid local enterprise trust, provisioning profile, certificate chain, or signing validation state after upgrading to iOS 27 Developer Beta. Questions: Does iOS 27 Developer Beta introduce any new restrictions or behavior changes for enterprise in-house app launch validation, code signing validation, enterprise developer trust state, embedded frameworks loading, entitlements, or provisioning profile validation? Are there any known differences in this area between iPhone 11 / iPhone 12 and iPhone 13 or later devices on iOS 27 Developer Beta? If multiple enterprise apps distributed with the same provisioning profile or provisioning setup fail before app code runs, does that point more strongly to a provisioning profile, certificate chain, enterprise trust state, or system validation issue? Given that completely uninstalling the old enterprise app, reinstalling it, and trusting the enterprise developer certificate again fixes the issue, could this be caused by stale trust, provisioning profile, certificate, or code-signing validation state cached on the device after upgrading to iOS 27 Developer Beta? For an enterprise app that stays on the Launch Screen before app code runs, or crashes immediately when launched from Spotlight/Search, what are the most common signing, certificate, provisioning profile, entitlement, or enterprise trust problems to check? Which system logs or crash log fields should we focus on for this kind of pre-main launch failure? For example: device console, crash log, Termination Reason, dyld message, Code Signature Invalid, profile validation, or trust evaluation messages. Are there recommended commands or checks to verify that the IPA's code signature, certificates, entitlements, embedded.mobileprovision, and embedded frameworks are all valid and consistent? If this is an iOS 27 Developer Beta regression, is there any known workaround until the issue is fixed? Environment: Distribution type: Apple Developer Enterprise Program / In-House distribution Affected OS: iOS 27 Developer Beta Affected devices: iPhone 11 / iPhone 12 Unaffected devices: iPhone 13 and later Same provisioning profile or provisioning setup: other enterprise apps show the same behavior Behavior 1: stuck on Launch Screen when launched from Home Screen Behavior 2: crashes immediately when launched from Spotlight/Search App code execution: not reached main/AppDelegate/SceneDelegate logs: not printed Crash SDK initialization: not reached Temporary workaround: completely uninstall the old enterprise app, reinstall it, and trust the enterprise developer certificate again. After that, the app launches normally. Impact: blocks enterprise app compatibility validation on iOS 27 Developer Beta for affected devices Suspected area: iOS 27 Developer Beta startup validation / code signing / provisioning profile / certificate / enterprise developer trust state / entitlements / embedded frameworks / device-specific validation behavior We are looking for guidance on how to confirm whether this is caused by an iOS 27 Developer Beta signing, provisioning profile, or enterprise developer trust validation change on iPhone 11 / iPhone 12, rather than an app-level crash. If this is a system issue in iOS 27 Developer Beta, we hope Apple can provide a fix or a practical temporary workaround as soon as possible.

Hi everyone, We are currently developing an on-premises enterprise MDM (Mobile Device Management) server. We are implementing the Software Update feature and need to support a wide range of devices, ranging from legacy versions (iOS 15 and below) to modern versions (iOS 16, 17, and later). As we know, iOS 16+ supports Declarative Device Management (DDM) for software updates (using configurations like com.apple.configuration.softwareupdate.enforcement.specific), which is now the recommended best practice. However, we still have enterprise clients running iOS 15 and below, which do not support DDM. These legacy devices require traditional MDM command payloads (such as ScheduleOSUpdate, OSUpdateStatus, and AvailableOSUpdates). We noticed that Apple has recently deprecated and removed the documentation for these legacy commands (e.g., the "Schedule an OS Update" endpoint documentation has been deleted from the Apple Developer Documentation portal). We would appreciate advice on the following: Is a "Dual-Pathway" approach still the recommended architecture for modern MDM servers to handle this transition (i.e., detecting OS version, sending traditional ScheduleOSUpdate plist commands for iOS 15 and below, and sending DDM Declarative configurations for iOS 16+)? Since the official documentation for legacy ScheduleOSUpdate and related commands has been deleted, where can we officially find the archived technical specifications and plist schemas for these commands to ensure proper backward-compatible implementation? Thank you so much in advance for your guidance!

Hi everyone, We are currently developing an on-premises enterprise MDM (Mobile Device Management) server. We are implementing the Software Update feature and need to support a wide range of devices, ranging from legacy versions (iOS 15 and below) to modern versions (iOS 16, 17, and later). As we know, iOS 16+ supports Declarative Device Management (DDM) for software updates (using configurations like com.apple.configuration.softwareupdate.enforcement.specific), which is now the recommended best practice. However, we still have enterprise clients running iOS 15 and below, which do not support DDM. These legacy devices require traditional MDM command payloads (such as ScheduleOSUpdate, OSUpdateStatus, and AvailableOSUpdates). We noticed that Apple has recently deprecated and removed the documentation for these legacy commands (e.g., the "Schedule an OS Update" endpoint documentation has been deleted from the Apple Developer Documentation portal). We would appreciate advice on the following: Is a "Dual-Pathway" approach still the recommended architecture for modern MDM servers to handle this transition (i.e., detecting OS version, sending traditional ScheduleOSUpdate plist commands for iOS 15 and below, and sending DDM Declarative configurations for iOS 16+)? Since the official documentation for legacy ScheduleOSUpdate and related commands has been deleted, where can we officially find the archived technical specifications and plist schemas for these commands to ensure proper backward-compatible implementation? Thank you so much in advance for your guidance!

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'm a third-party MDM developer using the Automated Device Enrollment (DEP) cloud service API. My flow is the standard token exchange: I upload my public key to Apple Business Manager, download the encrypted server token, and store the resulting OAuth credentials (consumer_key, consumer_secret, access_token, access_secret) to authenticate and fetch device information. Recently I've started seeing authentication failures on tokens whose access_token_expiry still has 6+ months of validity remaining. The credentials were working fine and then began getting rejected, with no change on my side. My questions for anyone who has seen this: Has anyone else observed DEP/ADE server tokens being rejected well before their stated access_token_expiry? What are the known triggers for early invalidation? (e.g., the ABM user who created the MDM server being deactivated or having a role change, the token being re-downloaded/regenerated, edits to the MDM server record, or Apple-side session invalidation.) Is there a supported way to detect that a still-unexpired token has been invalidated, other than catching the auth failure at request time? I want to confirm whether this is expected behavior tied to the ABM account/server lifecycle rather than the token's expiry date, so I can handle it correctly (i.e., prompt for a token re-download) instead of treating it as a bug. Any confirmation, similar reports, or official guidance would be appreciated. Thanks.

We're migrating our MDM-managed app from Enterprise (In-House) to App Store distribution and encountering error 9610 when using InstallApplication with iTunesStoreID. What worked (Enterprise) RequestType InstallApplication ManifestURL https://server/app.plist Configuration CompanyCode example This installed the app and delivered Managed App Configuration simultaneously. ✅ What fails (App Store) RequestType InstallApplication iTunesStoreID 6783649530 ChangeManagementState Managed Configuration CompanyCode example Result: Error 9610 (ASDServerErrorDomain — "Unhandled exception") We tried with/without PurchaseMethod (0 and 1), and without the Options key entirely — same error every time. Environment MDM: Custom (fully approved, case #102814667075) Device: iPhone 12 mini, iOS 18.5, non-supervised App: Already installed via TestFlight VPP/ABM: Not enrolled Questions Does InstallApplication with iTunesStoreID require a VPP license to work at all (even just for managing the app)? If VPP is required, is there an alternative to deliver Managed App Configuration (com.apple.configuration.managed) to an App Store app without Apple Business Manager? 3. Can Identifier (bundle ID) be used instead of iTunesStoreID to convert an already-installed app to managed state and push Configuration? Any guidance appreciated. The Enterprise → App Store migration is blocked solely by this issue.

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

Hi all: We use MDM profile to apply Full Disk Access permission for app on macOS, After profile deployed successfully, The App can get correct Full Disk Access permission, However, on "Privacy & Security" UI, we found that our app shown disabled, see as however, on some macOS, it showed correctly as below The issue happened on different os version. macOS 15 and macOS 26 When the item shown as disable, even reboot computer several times, the issue still persist. Thanks for your help

We are building a NETransparentProxyProvider system extension on macOS. The extension needs a certificate identity provisioned by MDM for cryptographic operations at runtime (signing and/or mTLS). We have hit a wall where a PKCS#12-delivered identity resolves correctly inside the extension but an ACME-delivered identity does not, and we want to understand whether this is a known limitation, a gap, or whether there is a supported path we are missing. We understand the implications of the data protection keychain on macOS but wonder if there is a carveout here that may not be documented well. We deploy the extension via MDM (profile traditionally but could be via DDM on macOS27). A VPN profile delivers an identity reference to the extension at runtime via PayloadCertificateUUID which surfaces an identity reference within protocolConfiguration.identityReference. When referencing a PKCS#12 identity (com.apple.security.pkcs12 payload): the identityReference is 196 bytes, beginning with the 4-byte prefix 73737569 (ASCII "ssui"). The reference is self-describing — it embeds the keychain path (/Library/Keychains/System.keychain), the certificate subject (in our case, "Delegate Test CA"), the team ID, and a 20-byte SHA-1 hash at the tail. This format carries everything the Security framework needs to locate the item. Full reference (our test, redacted to structure): 73737569 00000020 <uuid-bytes> 00000000000000000000000000000006 64626e6d 00000023 2f4c696272…53797374656d2e6b6579636861696e00 ← /Library/Keychains/System.keychain 6974656d 00000069 80001000… ← item data incl. DER subject … 00000014 48b494ae47d1b7b07ed8c77a681337a3af8e92a8 ← 20-byte SHA-1 hash When referencing a ACME identity (com.apple.security.acme payload, ECSECPrimeRandom P-384, SE-backed): the identityReference is 20 bytes, beginning with the 4-byte prefix 63657274 (ASCII "cert"). The remaining 16 bytes are opaque — they do not embed a keychain path, certificate subject, or any other locator. Full reference (our test): 63657274 a4c7e569737944b1 ad464dc3bb398f14 Searching for the SecIdentity The PKCS#12 reference resolves using SecItemCopyMatching with kSecValuePersistentRef set to the 196-byte reference and kSecMatchSearchList pointing at System.keychain succeeds immediately, returning a SecIdentity with both SecIdentityCopyCertificate and SecIdentityCopyPrivateKey succeeding - this is obviously expected for an exportable software key type. The ACME reference fails using every path that we tried to search/load it as a SecIdentity. Primarily: kSecValuePersistentRef with kSecUseDataProtectionKeychain: true (no explicit keychain): -25291 (errSecNoDefaultKeychain) kSecValuePersistentRef with an explicit kSecMatchSearchList pointing at System.keychain: -50 (errSecParam) — combining kSecValuePersistentRef with an explicit keychain search list is an invalid parameter combination for the compact cert-format reference. kSecMatchItemList with an explicit kSecMatchSearchList: -25300 (errSecItemNotFound) SecKeychainItemCopyFromPersistentReference (legacy API): -25300 (errSecItemNotFound) kSecValuePersistentRef with no keychain qualifier at all: -25291 (errSecNoDefaultKeychain) com.apple.managed.vpn.shared access group (which i know has had entitled use on iOS): -34018 (errSecMissingEntitlement) Next steps The cert-format kSecValuePersistentRef produced by an ACME identity cannot be resolved in a root daemon context using any API path we can find. The ssui-format reference from a PKCS#12 identity works. With macOS 27, com.apple.configuration.network.vpn.vpn-plugin DDM declarations accept an Authentication.IdentityAssetReference which can point at an ACME identity asset. Traditional VPN profiles also support PayloadCertificateUUID referencing an ACME payload. Both paths result in the extension receiving a cert-format reference that it cannot resolve. Is there a supported API to resolve a cert-format kSecValuePersistentRef in a daemon context without a default keychain? Or is this just the reality of the DPK on macOS where ACME/SE-backed identities are not usable from system extensions, and the IdentityAssetReference and PayloadCertificateUUID fields only work for PKCS#12 or SCEP identity types in this context? For completeness: we have also explored ManagedApp.framework and ManagedAppIdentitiesProvider as an alternative delivery path, and believe this is the better method, but that hits a separate issue where managedappsd fails to verify the code signature of a system extension caller (filed separately as feedback FB23484530). Similar to this, we need to understand if the ExtensionConfigs in ManagedApp.framework are for appex user space app extensions only, and don't extend to System Extensions.