General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

We generate Secure Enclave keys via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave on macOS. We need to prove to a remote server that the key is genuinely hardware-bound, not a software key claiming to be one. Is there any API on macOS for an app to obtain an Apple-signed certificate or attestation statement for such a Secure Enclave key, similar to how ASAuthorizationProviderExtensionLoginManager.attestKey() works within Platform SSO but available to general apps? Or other possible workaround for this? Thank you!

เนื่องจากได้อ่านรายละเอียดเกี่ยวกับแล้วตรงและสิ่งที่เจอทั้งหมดหลังจากได้ทีการแจ้งไปเรื่องโดนแฮ็กข้อมูลและถูกโจรกรรมข้อมูลส่วนบุคคลทั้งหมด เจอสถานณ์ตรงตามส่วน คำเตือนเนื้อหาที่ละเอียดอ่อนทั้งหมด ตอนนี้สภาพจิตใจย้ำแย่เป็นอย่างมากและท้อใจอย่างที่สุดเพราะโดเดี่ยวสู้กับปัญหาและพยายามหาหลักฐานเพียงผู้เดียวซึ่งไม่เหลืแคนที่ไว้วางใจได้แม้แต่คนเดียว เพราะโดนใส่ร้ายทุกรูปแบบจนเสียงชื่อเสียงเหมือนกับผลักทุกคนออกไปจากชีวิตจนไม่เหลือแม้คนเดียวที่รับฟังทำให้พูดความจริงทั้งหมดไม่มีใครเชื่อและรับฟังแม้แต่คนเดียว เหตุที่แจ้งไปก่อนหน้านี้เป็นเวลาเกือบ 8 เดือนกว่าๆแล้วจนถึงปัจจุบันนี้ ยังไม่ได้รับกาคช่วยเหลือหรือไม่มีการช่วยเหลือใดๆทั้งสิ้น

Hi all, We are developing an iOS app that includes private user-to-user chats, commercial offer details with monetary value, and customer identification data. In line with OWASP MASVS-PLATFORM-3 requirements regarding unintentional sensitive data exposure, we need to protect these specific screens from screenshots and screen recording. We have carefully reviewed the relevant App Review Guidelines (2.5.1 on public APIs, 2.5.2 on self-contained bundles, 5.1.1 on privacy) and the related Human Interface Guidelines. From this analysis we have observed the following: iOS does not expose a public API to globally disable screen capture (no direct equivalent of Android's FLAG_SECURE). The SwiftUI .privacySensitive() modifier is effective for Lock Screen widgets and Always-On Display, but it does not appear to prevent screenshots or screen recording of an app's main UI while in the foreground. A number of widely distributed App Store apps (banking, authenticator, secure messaging) implement some form of screenshot protection on sensitive screens. Several established open-source libraries leverage the system behavior of UITextField with isSecureTextEntry as a wrapping container for arbitrary views, in order to achieve pixel-level protection for sensitive content. We would appreciate clarification on the following points: For privacy-driven protection of sensitive screens (private chats, customer data, monetized offers), is there an officially recommended approach we may have missed? Are there public APIs intended specifically for this use case beyond .privacySensitive()? Is the practice of leveraging UITextField with isSecureTextEntry as a wrapping container for arbitrary views considered an acceptable use of public APIs under Guideline 2.5.1, or does it carry App Review risk? Are there official recommendations or documentation for apps handling sensitive personal data that wish to align with industry standards such as OWASP MASVS-PLATFORM-3 for screenshot and screen recording leakage prevention? The intended use is strictly limited to a small number of screens marked as containing sensitive data (private messages, deal details, customer information). The protection would be selective and clearly communicated to the user via in-app messaging, not global to the app. Thanks in advance for any clarification, including pointers to existing documentation or threads we may have missed. Deployment target: iOS 15+

Hello, We are reaching out as a company providing Wi-Fi connectivity services through captive portals to report a potential issue identified after upgrading to iOS 26. Since the release of this version, we have received multiple reports from customers who are unable to complete the authentication process on captive portal networks. The observed behavior is as follows: The device correctly detects the Wi-Fi network. The connection is established at the link level, but after entering access credentials and proceeding to the next login step, an “error opening page” message is consistently displayed. When the user taps “OK,” the captive portal mini-browser closes. As a result, the user is unable to authenticate or gain internet access. We have verified that: Our network infrastructure and captive portals function correctly on other operating systems (Android, Windows, and previous iOS versions). No recent changes have been made to our platforms that could explain this behavior. The issue appears to be consistently reproducible on devices running iOS 26. Additionally, we have identified similar reports from users in public communities like reddit, suggesting this is not an isolated case. https://www.reddit.com/r/ios/comments/1no4vzt/switched_to_ios_26_and_now_i_cant_connect_to/ Given the direct impact on user experience and services relying on web-based authentication, we would appreciate any information on whether this behavior is being investigated or if there are any technical recommendations to mitigate the issue. Thank you for your attention.

Hi Apple Developer Forums, We are developing a managed macOS security/monitoring agent for enterprise customers (deployed only to MDM-managed endpoints). Our goal is to collect per-process network connection metadata (e.g., which process initiated a TCP connection, destination IP/port, timestamps). We are not intercepting or collecting network payload/content—only connection metadata for security telemetry/compliance. We previously explored options like: sysctl PCB lists (e.g., net.inet.tcp.pcblist_n) / kernel structs (not stable ABI; appears private/fragile) Aggregate TCP stats (sysctl net.inet.tcp.stats) which are public but system-wide only proc_pidinfo() / PROC_PIDFDSOCKETINFO for per-PID socket snapshots (polling-based; limited / not event-driven) It seems the supported, event-based approach for per-process connection visibility is EndpointSecurity.framework, but it requires the entitlement: com.apple.developer.endpoint-security.client Questions: Is EndpointSecurity.framework the recommended/supported approach for per-process TCP connection events on macOS for a managed enterprise security agent? What is the correct process to request approval for the Endpoint Security client entitlement under an Apple Developer Program team? (We were directed to post here.) Which Endpoint Security event types are appropriate for capturing connect/accept/close style network events per-process, strictly for metadata telemetry? Are there any platform/privacy constraints or best practices Apple expects us to follow for this use case (MDM-managed enterprise deployments)? We can provide additional details (distribution method, signing, MDM deployment model, privacy disclosures) if needed. Thanks!

We are implementing Platform SSO with Secure Enclave–based authentication. In a standard (post-enrollment) flow, everything behaves as expected: Authentication uses urn:ietf:params:oauth:grant-type:jwt-bearer The Secure Enclave–backed credential is used correctly However, when using Automated Device Enrollment (ADE) with Simplified Setup, we observe different behavior: After device registration, Platform SSO triggers a login request to our IdP That request uses grant_type=password Instead of the expected urn:ietf:params:oauth:grant-type:jwt-bearer This occurs even though: The configuration specifies Secure Enclave as the authentication method The same configuration works as expected outside ADE Questions: Is this password grant during ADE / Simplified Setup an expected bootstrap flow? Is there any official documentation describing this? This behavior is currently undocumented, and clarification would help ensure correct IdP implementation.

Hello, We are currently unable to access our Apple account. We previously initiated an account recovery request. According to the notification we received, the recovery process was scheduled to be completed on April 26, 2026, and we were informed that we would receive a phone call or SMS to proceed. However, we did not receive any call, SMS, or email communication. Details from the recovery notification: Recovery request date: April 16, 2026 Expected contact date: April 26, 2026 As of now: We still do not have access to the account No follow-up communication was received The recovery process appears to be stalled We would like to understand: What is the current status of the account recovery request? Why no contact was made on the scheduled date? What steps we should take next to regain access to the account? This account is critical for our Apple Developer operations, so we would appreciate your assistance. We can provide any additional verification information if required. Thank you.

Hi, I’m working with an SSO extension (ASAuthorizationProviderExtension) and am looking for clarification on how Apple determines whether the calling app is considered managed for ASAuthorizationProviderExtensionAuthorizationRequest.isCallerManaged. In my test, the authorization request is triggered from an app that is managed by our organization. We are using Jamf. However, in the SSO extension, I see the following caller metadata isCallerManaged=false I’d like to understand what conditions must be met for isCallerManaged to return true. Thanks.

We are using an SFAuthorizationPluginView-based authentication plug-in for screen unlock, and we are seeing focus/activation behavior on macOS Tahoe 26.4.1 that appears different from earlier macOS releases. In our lock-screen plug-in UI, the view is displayed correctly, but keyboard input does not go to our password field until the user physically clicks inside the plug-in view. We have already tried the documented focus-related hooks and standard AppKit approaches, including: Overriding firstResponder Overriding firstKeyView / lastKeyView Calling becomeFirstResponder Calling makeFirstResponder on the host window during activation Setting up the key view loop between controls Despite this, on Tahoe 26.4.1 the password field still does not accept typing until the first mouse click inside the plug-in view. Could you clarify the following: On macOS Tahoe 26.4.1, are there any known changes in SecurityAgent / SFAuthorizationPluginView behavior that affect firstResponder, firstKeyView, or keyboard activation during screen unlock? Is a physical click now required before keyboard input is delivered to an SFAuthorizationPluginView in this context? If not, what is the recommended supported way to ensure the password field becomes keyboard-active immediately when the plug-in view is shown? Are becomeFirstResponder / makeFirstResponder expected to work in this host context, or are only the SFAuthorizationPluginView hooks (firstResponder, firstKeyView, lastKeyView) supported? Is there any recommended host-window or activation API for this scenario, or is this considered a regression in Tahoe?

tl;dr: The title and/or can I even add a keychain entitlement to a cli app? I'm trying to store a generated private key and certificate properly in a CLI app. The call to SecItemAdd always results in an error with message A required entitlement isn't present. I assume this is errSecMissingEntitlement, and its docs say it happens "when you specify an access group to which your app doesn’t belong". But I'm not even specifying one. Here's a small excerpt (I know it's not a MVCE but the question is pretty general anyway): func storeCert(_ cert: Data) throws { let addQuery = [ kSecClass: kSecClassCertificate, kSecValueRef: cert, kSecAttrLabel: CERT_USER_LABEL, kSecAttrApplicationLabel: CERT_APP_LABEL ] as [String: Any] let status = SecItemAdd(addQuery as CFDictionary, nil) guard status == errSecSuccess else { let msg = SecCopyErrorMessageString(status, nil) as String? ?? "" throw MyErr.generic(message: "Unable to store cert: \(msg)") } } I can't add the keychain entitlement to my CLI target, it doesn't show as an option in the add capability window. Disclaimer: I'm quite new to macOS / Apple development, so if there's something obvious I'm missing, my bad.

I’m encountering an issue where my app does not show the Contacts permission prompt in the production environment. This has been observed on iPhone 16 Pro Max and iPhone 17 Pro Max devices, while other iPhone models appear to behave correctly. The behavior is consistent across Xcode builds, TestFlight, and the App Store version when using the production bundle identifier. Instead of returning .notDetermined, the app receives the device’s previous Contacts authorization status, so the system permission prompt is never shown. Expected behavior On first launch after install, the app should prompt the user for Contacts access. Actual behavior (Production build) The app does not prompt for Contacts permission and instead appears to reuse the previous permission state: If the user previously had no access → after uninstall/reinstall, still no access (no prompt shown) If the user previously had limited access → after reinstall, access becomes empty (0 contacts), still no prompt If the user previously had full access → after reinstall, still has full access without being prompted Additional observations This issue only occurs in Production Staging and Dev builds (TestFlight + Xcode) behave correctly and prompt for permission If I set my Dev build to use the same bundle identifier as Production, the issue reproduces (no permission prompt) Current workaround The only way for users to change Contacts access is via the Settings app. The permission prompt is never shown in-app. Has anyone encountered this behavior before, or is there something specific to production builds (or bundle identifiers) that could cause the system to skip the permission prompt?

We’re investigating a Platform SSO registration issue on macOS and wanted to check whether others have seen similar behavior or know whether this is expected system behavior. Scenario: Our extension implements ASAuthorizationProviderExtensionRegistrationHandler for device and user registration. On failure we complete with ASAuthorizationProviderExtensionRegistrationResult.failed, and on success we complete with .success. What we’re seeing: If registration fails multiple times, macOS shows multiple system dialogs saying: Registration failed and will automatically retry in a few minutes. If we do not close those earlier failure dialogs and then start another registration that succeeds, the old failure dialogs remain visible and do not dismiss automatically. They have to be closed manually one by one. From our side, these appear to be system-owned Platform SSO dialogs, not app-owned windows. We only return the registration result via the handler completion. Any guidance on whether macOS is expected to reconcile/dismiss earlier failure dialogs after a later success would also be helpful.

When implementing a custom right in macOS authorizationdb, the mechanism array element builtin:authenticate is displaying the message 'Enter the name and password of a user in the "(null)" group to allow this.' on the macOS credential prompt UI popup. I am trying to find a fix to avoid the reference to null group in the message label that is displayed just above the username and password input fields. The current plist uses class as the key and value as the evaluate-mechanisms. The mechanisms array includes mechanism array with elements "builtin:login-begin", "mycustombundle:mycustompreaction", "builtin:authenticate", "mycustombundle:mycustommechanism". I have tried specifying group in the plist, have tried setting hint in the MechanismInvoke for group, username, security, authority, prompt, reason among several other hints into the context duing the execution of mycustombundle:mycustompreaction, but none seem to fix the "(null)" in the message label. Any help is greately appreciated. There is not much of any documentation for developers implementing custom authorization in macOS.

Hi Apple Developer Community, Quick question — is there currently a way to disable the “Save Password” prompt in iOS while keeping AutoFill enabled? From what I can see, the only available setting under General → AutoFill & Passwords controls AutoFill as a whole, with no option to turn off just the save prompt. I’m using a third-party password manager and would prefer to keep AutoFill but avoid the repeated prompts to save credentials. Has anyone found a workaround for this, or is this simply not configurable at the moment? Thanks!

Hi Apple Developer Community, Quick question — is there currently a way to disable the “Save Password” prompt in iOS while keeping AutoFill enabled? From what I can see, the only available setting under Settings → Passwords → Password Options controls AutoFill as a whole, with no option to turn off just the save prompt. I’m using a third-party password manager and would prefer to keep AutoFill but avoid the repeated prompts to save credentials. Has anyone found a workaround for this, or is this simply not configurable at the moment? Thanks!

Apple's submission for FIPS140-3 (https://support.apple.com/guide/certifications/macos-security-certifications-apc35eb3dc4fa/web) has no mention of review for Intel or Intel T2 in FIPS Compliance on Tahoe. Is there any effort for this or will there be any effort? Has there any been any word that Intel as an architecture is completely out of the picture for FIPS140-3?

Hi, I created an app and want to use Google Admob to show ads. I am a little bit confused how exactly tracking, more specifically, the ATT-framework and Google Admob relate to each other. The current work flow is: ATT-permission given -> show google ad mob consent form However, I am confused what I should do if the ATT permission is denied. Can I still show the consent form of google admobs or is that forbidden? If so what do I need to then? Thank you!

I'm following up from an old existing post per the recommendation by DTS Engineer I'm referencing that comment specifically because i'm only able to reproduce this issue when using a device through browserstack. (a service that allows remote access to physical ios devices for testing, etc) I haven't been able to reproduce the issue on my physical device. When attempting to launch an ASWebAuthenticationSession using callback: .https(host: path:), The session immediately fails (before even presenting the web modal) with the error: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 NSLocalizedFailureReason=Application with identifier com.builderTREND.btMobileAppAdHoc is not associated with domain test.buildertrend.net. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for test.buildertrend.net. Which doesn't make sense, since our AASA file does specify that url and has the app ID listed in webcredentials Our app's entitlements file also contains webcredentials:*.buildertrend.net So it seems like everything is set up properly, but this issue is persistent.

Is anyone else seeing 403 errors for PCC VRE when trying to pull assets for Release 41303? My pccvre audit of the Transparency Log passes (valid root digests for 41385), but the download fails consistently on specific CDN URLs: Failed to download SW release asset... response: 403 I’ve verified csrutil allow-research-guests is active and the license is accepted. Release 41385 seems fine, but 41303 is a brick wall. Is this a known pull-back or a CDN permissions sync issue?

Hi, it's very urgency! https://developer.apple.com/forums/thread/818346 After long time preparation, We finally execute this transfer operation today. Works fine at preliminary stage, lots of users had been transferred successfully. However, about 25% users transferred failed at the end, 'invalid_request' response from https://appleid.apple.com/auth/usermigrationinfo. No matter how many times we retry, it does work. Please help! 700,000 users are waiting us!