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?

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!

Hi everyone, We submitted our enrollment application for the App Store Small Business Program on August 9, 2026 (almost 1 month ago) and received the confirmation email, but have not had any status update since. Our Agreements, Tax, and Banking page in App Store Connect has been fully set up and Active since February 2026 (Paid Apps Agreement, Bank Account, W-8BEN, DSA Compliance all active). We are well under the $1M threshold with no associated accounts. We have open cases with Developer Support (Case #20000152216769) and Finance Support (Case #22032895, Team ID: N2WHU2B9BC). Could an Apple staff member or moderator kindly help escalate this to the Agreements & Contracts review team? Thank you!

Hi everyone, We submitted our enrollment application for the App Store Small Business Program on August 9, 2026 (almost 1 month ago) and received the confirmation email, but have not had any status update since. Our Agreements, Tax, and Banking page in App Store Connect has been fully set up and Active since February 2026 (Paid Apps Agreement, Bank Account, W-8BEN, DSA Compliance all active). We are well under the $1M threshold with no associated accounts. We have open cases with Developer Support (Case #20000152216769) and Finance Support (Case #22032895, Team ID: N2WHU2B9BC). Could an Apple staff member or moderator kindly help escalate this to the Agreements & Contracts review team? Thank you!

Hi Apple Team, We are using the Accounts MDM payload with: PayloadType: com.apple.MCX DisableGuestAccount: true On macOS 26, even after the MDM profile is successfully applied, a local Administrator can still toggle the Guest User setting in System Settings. Expected: The setting should be enforced by MDM and should not be modifiable by an Administrator. Interestingly, the same configuration works as expected on macOS 27 beta, where the Guest User setting is shown as “This setting has been configured by a profile” and cannot be modified. Could you please confirm whether this is a known issue/regression in macOS 26 and whether there is a workaround or any permanent solution in later patches ? Environment: macOS 26.x Payload: com.apple.MCX DisableGuestAccount = true macOS 27 beta: Works as expected

Hello, I'm trying to use a certificate provisioned through the com.apple.security.acme payload for TLS client authentication in Safari on macOS. Provisioning the certificate via ACME using the device-attest-01 challenge is working fine and the signed certificate includes the Extended Key Usage: TLS Web Client Authentication. Unfortunately on macOS in Safari I can't find a way to choose this identity when a server requests client authentication. Using the same method works flawlessly on iOS. If a server requests client authentication Safari prompts the option to use the certificate and the connection to the web server succeeds as intended. On macOS I have tried adding a com.apple.security.identitypreference payload to the profile, linking the certificate from the ACME payload to the domain name of a web server that requires client authentication, but that did not change the behavior in any way. The following payload is used to request the certificate on both my MacBook and iPhone: <?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>PayloadDisplayName</key> <string>ACME Certificate Request</string> <key>PayloadIdentifier</key> <string>com.example.net.acmeprofile</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>UUID-1111-1111-1111-111111111111</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadContent</key> <array> <dict> <key>PayloadType</key> <string>com.apple.security.acme</string> <key>PayloadIdentifier</key> <string>com.example.net.acme</string> <key>PayloadUUID</key> <string>UUID-2222-2222-2222-222222222222</string> <key>PayloadVersion</key> <integer>1</integer> <key>DirectoryURL</key> <string>https://acme.example.net/acme/apple-acme/directory</string> <key>ClientIdentifier</key> <string>XXXXXXXXX</string> <key>KeyType</key> <string>ECSECPrimeRandom</string> <key>KeySize</key> <integer>256</integer> <key>UsageFlags</key> <integer>1</integer> <key>ExtendedKeyUsage</key> <array> <string>1.3.6.1.5.5.7.3.2</string> </array> <key>HardwareBound</key> <true/> <key>Attest</key> <true/> <key>AllowAllAppsAccess</key> <true/> <key>Subject</key> <array> <array> <array> <string>CN</string> <string>XXXXXXXXX</string> </array> </array> </array> </dict> </array> </dict> </plist> And this is the identity payload I have added to the profile on macOS: <key>PayloadType</key> <string>com.apple.security.identitypreference</string> <key>PayloadIdentifier</key> <string>com.example.net.identitypreference</string> <key>PayloadUUID</key> <string>UUID-3333-3333-3333-3333333333333333</string> <key>PayloadVersion</key> <integer>1</integer> <key>Name</key> <string>mtls-endpoint.example.net</string> <key>PayloadCertificateUUID</key> <string>UUID-2222-2222-2222-222222222222</string> Neither device is managed by an MDM service and they run macOS 26.6.1 and iOS 26.6 respectively. Is there any additional configuration required on macOS to make an ACME-provisioned certificate available for client authentication in Safari? Or is this simply the expected behavior, and client authentication requires a traditional certificate-key pair in the macOS Keychain? Any help would be greatly appreciated!

We deploy WPA3-EAP for co-working spaces (EU/US). That means BYOD and no ability to enforce MDM. Each co-working space issue wifi credentials to their individual members, usually in the form of PEAP/TTLS. The user joins the SSID for EAP and is prompted to enter username + password, and then to accepts our radius certificate (prompted as "not trusted" of course). Does the certificate validity period of 825 days or fewer apply to our radius leaf certs? The question has come up as we read: https://support.apple.com/en-us/102028 --"This change will not affect certificates issued from user-added or administrator-added Root CAs" https://support.apple.com/en-ca/103769 --"Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:" ..... "TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate)." lastly, while PEAP/TTLS is the primary method. Second is delivering a .mobileconfig that can be downloaded by the user containing EAP-TLS authentication. These also require user acceptance as there again is no MDM possible. We dont have any issues currently, but are we going to wake up one morning and find that all apple devices have dropped off the networks?

This page: https://developer.apple.com/documentation/devicemanagement/installing-managing-updating-and-removing-apps#Pin-the-version-of-an-app States the following: To find the EVID of an App Store app, use one of these procedures: If the device management service manages the app using declarative management, look for the external-version-id key in the StatusAppManagedList status item that the device reports to the service. If the device management service manages the app using MDM commands, look for the ExternalVersionIdentifier key in the Installed Application List command response that the device returns to the service. Use the Apps and books metadata for organizations API to look up the externalVersionId key in the Apps.Attributes for the app. Ask the app developer to provide the value. The first 2 require access to an MDM and the third in order to use the Appsand books metadata you need to turn your account into an MDM vendor developer account. So the final option is to "ask the app developer". I am the app developer and have no idea how to get this value. As a normal iOS developer is there no other way than to either contract an MDM or turn your account into an MDM vendor?

Ever since tvOS 26.4, we've had some difficulties in discovering, pairing, and supervising Apple TV 4K devices using Apple Configurator 2.20. We submitted a feedback report about this issue (FB22525540). The issue has improved somewhat for me when using the latest tvOS 26.6, if the Apple TV is connected via Ethernet during the initial paring step. Sometimes the pairing still fails, but eventually I can get it to work. However, some others on our dev / QA teams haven't had the same luck in even seeing the device as available to pair (even when the Apple TV is at the welcome screen or Remote and Devices screen, nearby, and on Ethernet along with the Mac). I've seen other cases where the pairing seems to work, but then the device doesn't appear in the Apple Configurator devices list, and therefore it’s not possible to supervise and install profiles onto it. Are they any workarounds or other steps we can try?

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!

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!

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.