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.

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?

I am using the CryptoTokenKit API in order to communicate with smart cards through NFC, with TKSmartCardSlotNFCSession. I call the createNFCSlotWithMessage method from TKSmartCardSlotManager, which displays successfuly the NFC dialog. However, when I put any smart card next to the phone, the NFC dialog shuts down instantly. I notice the following log in the system console: -[_NFReaderSession(Entitlement) validateAID:allowsPrefixMatch:]:317 Non-permissible identifier: A000000308000010000100 When I add the A000000308000010000100 AID mentioned in the error message to the Info.plist of my application, the NFC dialog does not shut down anymore and I am able to communicate with the smart card (using TKSmartCard). This behavior has been reproduced on an iPhone 16e, iOS 26.4. This AID does not correspond to anything in the smart card. It seems to be related to PIV, but this behavior also occurs with cards that are not PIV (PKCS#15...). Also, with an implementation using CoreNFC API instead of CryptoTokenKit API, this AID is not needed to be able to communicate with the card, so it seems CryptoTokenKit-specific. I did not find anything related to this in the documentation, have I missed something here ? Is this a special AID that is required all the time to work with NFC through CryptoTokenKit ?

Hello Apple Developer: I encountered some issues during development. I encrypted the secret key and stored it in the Keychain, but it failed when I tried to read it. I would like to ask if there is any problem with the code I wrote. Below is my code, including the storage and retrieval NSMutableDictionary *query = [[NSMutableDictionary alloc] initWithObjectsAndKeys:(id)kSecClassGenericPassword,(id)kSecClass, serviceID,(id)kSecAttrService, @YES,(id)kSecReturnData,nil]; CFTypeRef dataTypeRef = NULL; NSLog(@"SecItemCopyMatching"); OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)(query), &dataTypeRef); NSLog(@"SecItemCopyMatching end status = %d",status); if (status == errSecSuccess) { *privateData = CFBridgingRelease(dataTypeRef); return 0; }else{ return status; } NSMutableDictionary *attributespri = [[NSMutableDictionary alloc] initWithObjectsAndKeys: (id)kSecClassGenericPassword, (id)kSecClass, serviceID, (id)kSecAttrService, outData, (id)kSecValueData, nil]; CFTypeRef dataRef = NULL; OSStatus priStatus = SecItemAdd((__bridge CFDictionaryRef)attributespri, &dataRef); if (dataRef) CFRelease(dataRef); return priStatus == noErr;

Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,

Can a macOS Platform SSO extension reliably identify the original app behind a Safari or ASWebAuthenticationSession-mediated request, or does ASAuthorizationProviderExtensionAuthorizationRequest only expose the immediate caller such as Safari ? We are seeing: callerBundleIdentifier = com.apple.Safari callerTeamIdentifier = Apple audit-token-based validation also resolves to Safari So the question is whether this is the expected trust model, and if so, what Apple-recommended mechanism should be used to restrict SSO participation to approved apps when the flow is browser-mediated.

We've filed FB22448572 for this, but posting here in case others are hitting the same issue. After upgrading macOS from 26.3.2 to 26.4, SecItemCopyMatching returns errSecAuthFailed (-25293) when reading kSecClassGenericPassword items from the default login keychain. The keychain reports as unlocked, but all authenticated operations fail. The error doesn't self-resolve — we've observed it persisting for 7+ minutes across repeated calls and process restarts. The only workaround we've found is SecKeychainLock(nil) followed by SecKeychainUnlock(nil, 0, nil, false), which prompts the user for their password and clears the stale state. Apple's own security CLI tool also fails while the keychain is in this state: $ security show-keychain-info ~/Library/Keychains/login.keychain-db security: SecKeychainCopySettings .../login.keychain-db: The user name or passphrase you entered is not correct. The trigger seems to be process lifecycle — a new process accessing the keychain early in startup (e.g., from the app delegate) can hit this state after the OS upgrade. It's probabilistic: not every machine and not every restart, but once it happens, it sticks until manual intervention. We're an enterprise app using legacy keychain APIs (SecKeychainCopyDefault, kSecUseKeychain) deployed to thousands of managed devices. We've reproduced this on multiple machines (M1, M2) and have reports from customers in the field after the 26.4 upgrade. I noticed a possibly related thread — Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4 — where SecKeychainUnlock stopped properly validating passwords after 26.4. Our symptom is different (reads fail on an unlocked keychain rather than unlock succeeding with wrong password), but both appeared after 26.4 and both point to something changing in securityd's authentication handling. Wondering if these could be related. A couple of questions: Is there a known issue with securityd's keychain authentication after 26.4? Could this be related to the CVE-2026-28864 fix ("improved permissions checking" in the Security component)? Would migrating to the data protection keychain (kSecAttrAccessible instead of kSecUseKeychain) avoid this class of issue entirely? Is there a way to detect and clear this stale state programmatically without the user entering their password? Any guidance appreciated.