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.

PermissionDefaults under Privacy for com.apple.configuration.app.settings , device reports Info.UnsupportedSettings for "$.Privacy.PermissionDefaults for macOS 27 device iMac manufactured 2024 Request from MDM : "Type": "com.apple.configuration.app.settings", "Payload": { "Privacy": { "PermissionDefaults": { "net.soti.mobicontrol.macOS": { "OrganizationJustification": "Message", "Accessibility": "Allow" }, "net.soti.mobicontrol.macOSHelper": { "OrganizationJustification": "Message", "Accessibility": "Allow" } } } }, "Identifier": "2adc58b3-f631-41b8-93d8-f55612055c30", "ServerToken": "4dc895cc-b7c2-4729-b8a4-f9e2f8dba5a9" } Response from Device: { "StatusItems": { "management": { "declarations": { "activations": [ { "active": true, "identifier": "77409e31-ff4f-4f86-a1bd-175515e3a3bd", "valid": "valid", "server-token": "b096dd48-a127-4f65-a60d-bd615911deb8-1" }, { "active": true, "identifier": "84992e13-edc2-4791-989e-0cc54bd18ab8", "valid": "valid", "server-token": "8460aca3-b263-43fe-b659-343c81a6479e" }, { "active": true, "identifier": "bfd661e8-b81f-4383-b243-00330fca13ae", "valid": "valid", "server-token": "38399079-5402-401a-83f4-c39e8b4807e8" } ], "configurations": [ { "active": true, "identifier": "00d217fe-f6e2-479f-89b5-73b479bd9f1d", "valid": "valid", "server-token": "c25104a2-6d13-44a1-ac00-ccc916490ae9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "2adc58b3-f631-41b0-93d8-f55612055c30", "valid": "valid", "server-token": "4dc895cc-b7c2-4429-b8a4-f9e2f8dba5a9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "c5bc77f6-745d-43ae-9e49-6e9100d3f6a5", "valid": "valid", "server-token": "e3a5cdb3-fd51-42a2-afb4-fe5f602a493d-1" } ], "assets": [], "management": [] } } }, "Errors": [] }

I am evaluating Apple Music integration for a paid Windows desktop application that lets users migrate playlists they own between music services. The app would not stream, download, cache, redistribute, or monetize Apple Music audio, artwork, or previews. The Apple Music integration would be limited to: reading the user’s playlists; matching songs using catalog identifiers and metadata; creating playlists in the user’s Apple Music library; reconstructing the user’s playlists on another music service at their explicit request. I would like to clarify whether this type of user-initiated playlist migration is compatible with MusicKit / Apple Music API terms, especially for a paid application. If this is not the correct forum for a policy question, could an Apple engineer please point me to the appropriate channel? Thank you.

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.