Using the SDK, I've printed out some log messages when I enter the wrong password: 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] invoke 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] general: 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] progname: 'SecurityAgentHelper-arm64' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] OS version: 'Version 15.5 (Build 24F74)' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] pid: '818' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] ppid: '1' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] euid: '92' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] uid: '92' 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] session: 0x186e9 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] attributes: 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] is root: f 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] has graphics: t 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] has TTY: t 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] is remote: f 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] auth session: 0x0 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] context: 2025-08-20 15:58:14.088 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] authentication-failure: --S -14090 2025-08-20 15:58:14.088 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] pam_result: X-S 9 2025-08-20 15:58:14.089 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] hints: 2025-08-20 15:58:14.089 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] authorize-right: "system.login.console" 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-path: "/System/Library/CoreServices/loginwindow.app" 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-pid: 807 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-type: 'LDNB' 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-uid: 0 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-audit-token: 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................ 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] 00 00 00 00 27 03 00 00 e9 86 01 00 68 08 00 00 ....'.......h... 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-pid: 807 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] flags: 259 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] reason: 0 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] tries: 1 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] immutable hints: 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-apple-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-firstparty-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-apple-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-firstparty-signed: true 2025-08-20 15:58:14.091 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] arguments: 2025-08-20 15:58:14.091 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] none 2025-08-20 15:58:14.108 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] LAContext: LAContext[4:8:112] 2025-08-20 15:58:14.119 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] token identities: 0 2025-08-20 15:58:14.120 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] token watcher: <TKTokenWatcher: 0x11410ee70> Specifically, is there a manual/link somewhere that can allow me to interpret: authentication-failure: --S -14090 and pam_result: X-S 9

I can see the user’s real daily Screen Time perfectly inside a DeviceActivityReport extension on a physical device. It’s right there. But the moment I try to use that exact total inside my main app (for today’s log and a leaderboard), it dosnt work. I’ve tried, App Groups, Shared UserDefaults, Writing to a shared container file, CFPreferences Nothing makes it across. The report displays fine, but the containing app never receives the total. If this is sandboxed by design, I’d love confirmation. Thanks a lot

My app Mocawave is a music player distributed through the Mac App Store. It declares specific audio document types (public.mp3, com.microsoft.waveform-audio, public.mpeg-4-audio, public.aac-audio) in its CFBundleDocumentTypes with a Viewer role. When a user sets Mocawave as the default app for audio files and double-clicks an MP3 downloaded from the internet (which has the com.apple.quarantine extended attribute), macOS displays the alert: "Apple could not verify [filename] is free of malware that may harm your Mac or compromise your privacy." This does not happen when: Opening the same file via NSOpenPanel from within the app Opening the same file with Apple's Music.app or QuickTime Player The app is: Distributed through the Mac App Store Sandboxed (com.apple.security.app-sandbox) Uses com.apple.security.files.user-selected.read-write entitlement The file being opened is a regular audio file (MP3), not an executable. Since the app is sandboxed and distributed through the App Store, I expected it to have sufficient trust to open quarantined data files without triggering Gatekeeper warnings — similar to how Music.app and QuickTime handle them. Questions: Is there a specific entitlement or Info.plist configuration that allows a sandboxed Mac App Store app to open quarantined audio files without this alert? Is this expected behavior for third-party App Store apps, or could this indicate a misconfiguration on my end? Environment: macOS 15 (Sequoia), app built with Swift/SwiftUI, targeting macOS 13+.

We have successfully deployed our Qt C++ application on Windows and Android using OpenSSL with TLS Pre-Shared Key (PSK) authentication to connect to our servers. However, I understand that apps submitted to the App Store must use SecureTransport as the TLS backend on iOS. My understandiunig is that SecureTransport does not support PSK ciphersuites, which is critical for our security architecture. Questions: Does SecureTransport support TLS PSK authentication, or are there plans to add this feature? If PSK is not supported, what is Apple's recommended alternative for applications that require PSK-based authentication? Is there an approved exception process that would allow me to use OpenSSL for TLS connections on iOS while still complying with App Store guidelines? The application requires PSK for secure communication with our infrastructure, and we need guidance on how to maintain feature parity across all platforms while meeting App Store requirements

Dear Apple Developer Support Team, We are experiencing a recurring issue with the DeviceCheck API where the following error is being returned: com.apple.devicecheck.error 0 Upon analyzing our logs, we have noticed that this error occurs significantly more often when users are connected to Wi-Fi networks, compared to mobile networks. This leads us to suspect that there might be a relationship between Wi-Fi configuration and the DeviceCheck service’s ability to generate or validate tokens. We would like to know: Is this error code (0) known to be caused by specific types of network behavior or misconfigurations on Wi-Fi networks (e.g., DNS filtering, firewall restrictions, proxy servers)? Are there any recommended best practices for ensuring reliable DeviceCheck API communication over Wi-Fi networks? Additionally, could you please clarify what general conditions could trigger this com.apple.devicecheck.error 0? The lack of specific documentation makes debugging this issue difficult from our side. Any guidance or internal documentation on this error code and its potential causes would be greatly appreciated. IDE: Xcode 16.3 Looking forward to your support. Best regards,

Hi everyone, I'm experiencing an intermittent issue with Keychain data loss on the latest iOS Beta 2. In about 7% of cases, users report that previously saved Keychain items are missing when the app is relaunched — either after a cold start or simply after being killed and reopened. Here are the key observations: The issue occurs sporadically, mostly once per affected user, but in 3 cases it has happened 4 times. No explicit deletion is triggered from the app. No system logs or error messages from Apple indicate any Keychain-related actions. The app attempts to access Keychain items, but they are no longer available. This behavior is inconsistent with previous iOS versions and is not reproducible in development environments. This raises concerns about: Whether this is a bug in the beta or an intentional change in Keychain behavior. Whether this could affect production apps when the final iOS version is released. The lack of any warning or documentation from Apple regarding this behavior. Has anyone else encountered similar issues? Any insights, workarounds, or official clarification would be greatly appreciated. Thanks!

Apple Sign In - "Sign up not completed" Error in Development Build (React Native / Expo) Problem Summary I'm implementing Apple Sign In in a React Native app using expo-apple-authentication. The Apple sign-in dialog appears as expected, but after tapping "Continue," it displays the message: "Sign up not completed". No credential is returned, and the promise eventually rejects with ERR_REQUEST_CANCELED. App Configuration Platform: React Native (Expo SDK 52) Library: expo-apple-authentication v7.1.3 Target: iOS development build (not Expo Go) Bundle ID: com.example.appname.nativetest (new App ID created for testing) Apple Developer Console Setup (Reviewed Carefully) App ID Explicit App ID (not a wildcard) "Sign In with Apple" capability enabled No associated Services IDs or Sign In with Apple Keys Provisioning Profile Development profile created for the test App ID Profile includes the test device and development certificate Installed successfully and used to sign the app Certificates and Signing Valid Apple Developer Program membership Development certificate installed and selected during build App installs and launches properly on the test device Implementation Attempts Attempt 1: Supabase OAuth Method Initially tried using Supabase’s built-in Apple OAuth provider: Configured with team ID, key ID, and JWT credentials Proper redirect URLs and scheme were in place Resulted in OAuth URL pointing to Supabase instead of Apple, with incomplete client ID Ultimately moved to native implementation for improved control and reliability Attempt 2: Native Apple Sign In (Current Approach) Using expo-apple-authentication with the following code: const credential = await AppleAuthentication.signInAsync({ requestedScopes: [ AppleAuthentication.AppleAuthenticationScope.FULL_NAME, AppleAuthentication.AppleAuthenticationScope.EMAIL, ], }); Relevant app.config.js Section: ios: { bundleIdentifier: 'com.example.appname.nativetest', usesAppleSignIn: true, infoPlist: { NSAppTransportSecurity: { NSAllowsArbitraryLoads: true, NSAllowsLocalNetworking: true, }, }, }, plugins: ['expo-apple-authentication'] Observed Behavior AppleAuthentication.isAvailableAsync() → true Credential state → NOT_FOUND (expected for new user) Apple Sign In dialog appears and allows interaction User taps "Continue" → dialog reports "Sign up not completed" Eventually returns: [Error: The user canceled the authorization attempt], code ERR_REQUEST_CANCELED Confirmed Working Aspects AppleAuthentication API is available and initialized App is signed correctly and launches on the physical test device Apple Sign In dialog appears with correct styling and options Same result observed across both Wi-Fi and cellular networks Clean Setup and Debugging Performed Removed all previous build artifacts Created a new App ID and new provisioning profile Rebuilt the app using expo run:ios --device Validated entitlements and provisioning assignments Removed any Services IDs and Apple Sign In keys used in previous attempts Verified ATS (App Transport Security) policies allow dev-time communication Environment Information Device: iPhone (not simulator) iOS Version: 18.5 Xcode: Latest version Apple ID: Developer account with 2FA enabled Build Method: EAS CLI using expo run:ios --device Open Questions Has anyone experienced the "Sign up not completed" issue with a clean native implementation in Expo? Are there known limitations when testing Apple Sign In in local development builds? Could prior Apple ID authorization attempts impact sign-in behavior during testing? Are there any additional configuration steps, Info.plist changes, or entitlements required beyond those listed above? Thank you in advance for any suggestions or guidance. We’re hoping this is simply a configuration detail that needs to be adjusted.

Apple has repeatedly ignored my reports about a critical privacy issue in Spotlight on macOS 26, and the problem persists in version 26.3 RC. This is not a minor glitch, it is a fundamental breach of user trust and privacy. Several aspects of Spotlight fail to respect user settings: • Hidden apps still exposed: In the Apps section (Cmd+1), Spotlight continues to display apps marked with the hidden flag, even though they should remain invisible. • Clipboard reactivation: The clipboard feature repeatedly turns itself back on after logout or restart, despite being explicitly disabled by the user. • Excluded files revealed: Most concerning, Spotlight exposes files in Suggestions and Recents (Cmd+3) even when those files are explicitly excluded under System Settings > Spotlight > Search Privacy. This behavior directly violates user expectations and system settings. It is not only a major privacy issue but also a security risk, since sensitive files can be surfaced without consent. Apple must address this immediately. Users rely on Spotlight to respect their privacy configurations, and the current behavior undermines both trust and security.

[Q] When is the kTCCServiceEndpointSecurityClient set by macOS and in which conditions? From what I'm gathering, the kTCCServiceEndpointSecurityClient can not be set by a configuration profile and the end user can only grant full disk access. I searched for documentation on Apple's develop website (with the "kTCCServiceEndpointSecurityClient" search) and did not get any useful result. Using a more complete search engine, or the forum search engine, only points to the old annoying big bug in macOS Ventura. The problem I'm investigating is showing a process being listed as getting granted kTCCServiceEndpointSecurityClient permissions in the TCC database when: it's not an Endpoint Security client. it does not have the ES Client entitlement. the bundle of the process includes another process that is an ES Client and is spawn-ed by this process but I don't see why this should have an impact. This process is supposed to have been granted kTCCServiceSystemPolicyAllFiles via end user interaction or configuration profile. AFAIK, the kTCCServiceEndpointSecurityClient permission can only be set by macOS itself. So this looks like to be either a bug in macOS, an undocumented behavior or I'm missing something. Hence the initial question. macOS 15.7.3 / Apple Silicon

Hi, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

On iOS 26, QuickLookAR (ARQuickLookPreviewItem) shares the actual .usdz file via the system Share Sheet instead of the original website URL. This is a regression from iOS 17–18, where sharing correctly preserved and sent only the source URL. Repro steps: 1. Open a web-hosted USDZ model in QuickLookAR (Safari). 2. Tap Share. 3. Share via any messenger. 4. The full .usdz file is sent. Expected: Share Sheet sends only the original URL. Actual: Share Sheet sends the USDZ file. Impact: Uncontrolled distribution of proprietary 3D assets. Critical IP / data leak. Blocks production AR deployments relying on QuickLook. Environment: iOS 26.0–26.1, iPhone 14 / 15. Works as expected on iOS 17–18. Test case: https://admixreality.com/ios26/

Hi Apple, Currently we want to have enhancement for SMS OTP that we want to implement OTP Autofill, But after do some research we're stuck with option that the OTP only show in keyboard suggestion, is there any way for making OTP is automatically filled without user have to click the keyboard suggestion when receiving the SMS. Thanks Best Regards, Admiral Sultano Harly.

I've made my first app and encountered an unexpected (potentially existential) issue. The Manager app is designed to tag 3rd party "plugins" used by a DAW, storing metadata in a local SQLite database, and move them between Active and Inactive folders. This allows management of the plugin collection - the DAW only uses what's in the Active folder. Permissions are obtained via security-scoped bookmarks on first launch. The app functions as intended: plugin bundles move correctly and the database tracks everything. No information is written to the plugins themselves. The Problem:
When moving plugins using fs.rename() , the MAS sandbox automatically adds the com.apple.quarantine extended attribute to moved files. When the DAW subsequently rebuilds its plugin cache, it interprets quarantined plugins as "corrupt" or potentially malicious and refuses to load them. Technical Details: Moving files with NSFileManager or Node.js fs APIs within sandbox triggers quarantine Sandboxed apps cannot call xattr -d com.apple.quarantine or use removexattr() The entitlement com.apple.security.files.user-selected.read-write doesn't grant xattr removal rights User workaround: run xattr -cr /path/to/plugins in Terminal - not acceptable for professional users Question:
Is there any MAS-compliant way to move files without triggering quarantine, or to remove the quarantine attribute within the sandbox? The hardened-runtime DMG build works perfectly (no sandbox = no quarantine added). Any insight appreciated!

Hello! I do know apple does not support electron, but I do not think this is an electron related issue, rather something I am doing wrong. I'd be curious to find out why the keychain login is happenning after my app has been signed with the bundleid, entitlements, and provision profile. Before using the provision profile I did not have this issue, but it is needed for assessments feature. I'm trying to ship an Electron / macOS desktop app that must run inside Automatic Assessment Configuration. The build signs and notarizes successfully, and assessment mode itself starts on Apple-arm64 machines, but every single launch shows the system dialog that asks to allow access to the "login" keychain. The dialog appears on totally fresh user accounts, so it's not tied to anything I store there. It has happened ever since I have added the provision profile to the electron builder to finally test assessment out. entitlements.inherit.plist keys &lt;key&gt;com.apple.security.cs.allow-jit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.cs.allow-unsigned-executable-memory&lt;/key&gt; &lt;true/&gt; entitlements.plist keys: &lt;key&gt;com.apple.security.cs.allow-jit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.cs.allow-unsigned-executable-memory&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.automatic-assessment-configuration&lt;/key&gt; &lt;true/&gt; I'm honestly not sure whether the keychain is expected, but I have tried a lot of entitlement combinations to get rid of It. Electron builder is doing the signing, and we manually use the notary tool to notarize but probably irrelevant. mac: { notarize: false, target: 'dir', entitlements: 'buildResources/entitlements.mac.plist', provisioningProfile: 'buildResources/xyu.provisionprofile', entitlementsInherit: 'buildResources/entitlements.mac.inherit.plist', Any lead is welcome!

Hi community, I'm wondering how can I request the permission of "System Audio Recording Only" under the Privacy & Security -> Screen & System Audio Recording via swift? Did a bunch of search but didn't find good documentation on it. Tried another approach here https://github.com/insidegui/AudioCap/blob/main/AudioCap/ProcessTap/AudioRecordingPermission.swift which doesn't work very reliably.

Seeing the following error when attempting automatic passkey upgrade - [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. We're trying to enable Automatic passkey upgrade (https://developer.apple.com/videos/play/wwdc2024/10125/?time=38) for our website but it's not working from our testing on iOS 18.2 and 18.3 Beta Safari. The flow on our website looks like: the customers use autofill to fill out email and password on the sign-in page (abc.com/signin) PublicKeyCredential.getClientCapabilities is called to check if conditionalCreate supported. land on another page of our website (abc.com/pageX), which calls navigator.credentials.create with mediation conditional (Right after sign-in). We checked that we followed the steps in above video: Allow automatic passkey upgrades is enabled, mediation is set to conditional and password autofill is used to signed in. However, Safari threw an error [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Can Apple help guide us if anything is missed here?

Hello, we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally. Environment iOS 14+ Real devices only (no simulator) App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Relevant code let service = DCAppAttestService.shared service.generateKey { keyId, error in // key generation } service.attestKey(keyId, clientDataHash: hash) { attestation, error in // ERROR: com.apple.devicecheck.error 3 / 4 } service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in // ERROR: com.apple.devicecheck.error 3 / 4 } For some users we intermittently receive: com.apple.devicecheck.error error 3 com.apple.devicecheck.error error 4 Characteristics: appears random affects only some users/devices sometimes resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info Some questions: What is the official meaning of App Attest errors 3 and 4? Are these errors related to key state, device conditions, throttling, or transient App Attest service issues? Is there any recommended way to debug or gain more insight when this happens in production? Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose. Thank you.

Hi, It may be a stupid question, but we really wonder if there is a way for MDM to push a unique mTLS cert to our iOS application or if it can populate a client certificate in the iOS where our application can access it. Like browser app, how do browser mTLS certs get pushed? Thanks, Ying

Hello, I have a password manager app and would like to help my user's to enable the Safari autofill capability. I've made the password credential extension and that is working great. I just need to help my user's enable the feature. I could point them to Settings-&gt;General-&gt;AutoFill &amp; Password and instruct them to turn the feature on. However, I've noticed that my competitors are able to present an alert directly from their app to turn the feature on (without going to settings at all). I can't find any documentation on how to do this? Thanks for your help! //Ray

Hello, I have a password manager app and have noticed a new feature in AutoFill &amp; Passwords called "Set Up Codes In". I see that my competitors have been able to implement this feature but cannot find any documentation on how to do this. How can I make it so my app can support this feature. Any help to pointing me to the documentation or otherwise would be greatly appreciated. Thanks! //Ray