I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): `let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes.

I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes. so, how can I access a hardware-bound ACME identity？

We just got a rejection on our VoIP calling app (think Boss Revolution / Rebtel style/Yolla — prepaid credits, app-to-app calls free, calls to real landline/mobile numbers charged per minute). Apple's rejection (Guideline 3.1.1.1): "We noticed that the app includes or accesses paid digital content, services, or functionality by means other than In-App Purchase... The credits for VoIP calls can be purchased in the app using payment mechanisms other than In-App Purchase... The app includes intermediary currencies, such as points, coins, or gems, without using In-App Purchase." Our current setup: Users buy "credits" (shown in real USD, e.g. $10 = stored balance) Credits are spent calling real phone numbers (landline/mobile) over standard internet data (SIP/WebRTC) — not the device's native cellular dialer Payment was happening in an in-app webview (likely the actual issue) rather than opening external Safari Questions: Has anyone successfully shipped a prepaid VoIP/calling-credit app using ONLY external browser links (Safari, not webview) under the post-May-2025 US storefront ruling (3.1.1/3.1.1(a))? Or does Apple still reject "stored balance" models even with proper external links? Does anyone know HOW Rebtel, Boss Revolution, Dingtone, or similar apps are technically structured to avoid this? Is it because they trigger the native cellular dialer for the local access number leg of the call (qualifying under a different guideline) rather than using pure data/SIP the whole way through? Is "intermediary currency" purely about NAMING (coins/points) or does ANY stored prepaid balance — even shown in real currency — count, regardless of payment method used to acquire it? Does 3.1.3(f) ("Free Stand-alone Apps" for VoIP) actually prohibit ANY in-app call-to-action for purchase (even an external link), forcing us to have NO purchase flow in the app at all, with credits only purchasable via a fully separate website experience the user finds on their own? Has anyone gotten clarity from Apple directly (App Review Board call, or written response) on where VoIP termination minutes fall — "real-world service" (3.1.3 exception) vs "digital content consumed in-app" (requires IAP)? Any war stories, links to Apple's actual decisions, or technical breakdowns would be hugely appreciated. We're a small Canadian startup and don't want to burn anot

I’m developing a macOS application that contains an embedded User Service Login Item: Outer app bundle ID: com.xxx.app Embedded User Service bundle ID: com.xxx.app.service Team ID: DE8Y96K9QP The User Service is embedded at: OuterApp.app/Contents/Library/LoginItems/UserService.app I deployed a com.apple.configuration.app.managed declaration through an MDM server, with an asset declaration of type: com.apple.asset.credential.identity, the declaration uses: "AppComposedIdentifier": "com.xxx.app (DE8Y96K9QP)" When the ManagedApp APIs are called from the outer ZTA app, the app successfully receives the identity. However, when the same ManagedApp APIs are called from the embedded User Service, the identity list is empty. When I instead use the embedded service’s identifier: "AppComposedIdentifier": "com.xxx.app.service (DE8Y96K9QP)", macOS reports either Error.InvalidCodeSignature or Error.NotPresent. My questions are: Can an embedded Login Item or embedded subsystem be the target of an app.managed declaration and access managed identities through ManagedAppIdentitiesProvider? Or must AppComposedIdentifier always identify the top-level application that contains the embedded Login Item? If the declaration targets the outer application, is there a supported way for the embedded User Service to access the same managed identity—for example, through XPC communication with the outer application? The outer application and embedded User Service are signed by the same Team ID, and both signatures validate successfully when checked with codesign. Thanks, Ying

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}

Environment macOS 27.0, build 26A428. Platform SSO via an MDM-managed third-party SSO extension (Microsoft Entra ID / Company Portal), Apple Silicon (Mac16,x family). Not seen on macOS 26 or 15 with the same configuration. Symptom When the identity provider expires a user's password under Platform SSO (Secure Enclave method), the expected flow is: unlock with the old or new password at the login window, then get prompted to reconcile the local credential. Instead, no password-change UI ever appears. The user is logged out and can't log back in with either password. Only Recovery Mode or an MDM-driven reset gets the device usable again. Reproducibility Confirmed independently on several separate Macs (some migrated from another MDM, others freshly provisioned), on and off corporate network — ruling out a local network/proxy cause. Diagnostic evidence (from sysdiagnose, both devices) com.apple.PlatformSSOUIAgent — the per-user LaunchAgent that renders Platform SSO's interactive prompts — shows runs = 0 for the entire session in launchctl dumpstate, even though the backend PlatformSSO.daemon-xpc/service-xpc endpoints are alive. It's simply never invoked. opendirectoryd shows multiple unrelated processes system-wide blocked via kernel turnstile, "after 2 hops," waiting on specific opendirectoryd threads, while those threads themselves show almost no CPU time across a 10-second spindump — consistent with the daemon idling while blocked rather than working. This reproduced within minutes of a fresh reboot/reset on one device, suggesting an immediately-recurring condition rather than a one-off. What's been ruled out Deprecated Password-type PSSO auth (already on Secure Enclave), the new OpenID-based PSSO login-window mode (IdP doesn't support it yet), TLS-inspecting proxies, and the MDM-side SSO profile itself (rebuilt and validated against current vendor docs).

We had a number of personnel changes in our startup back in December. One of the people who left the company was our Chief Product Officer, and the account owner for our developer account. I have admin privileges but need to change the ownership to me so I can pay the renewal fee and conduct other tasks associated with account owner. Our prior employee cannot be reached. He has gone off-grid it seems and is not responding to our inquiries and pleas for help. Who can I speak/correspond with at Apple to get this account updated to reflect our new organization?

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!