While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if present) let biometryType = context.biometryType // (4) let biometryStateHash = context.evaluatedPolicyDomainState // (5) } However, moving let biometryType = context.biometryType (4) before call to canEvaluatePolicy (3) still yields correct biometry type. This is in contradiction to article from Local Authentication documentation page Optionally, Adjust Your User Interface to Accommodate Face ID. Furthermore, biometryType documentation does not mentions such requirement. Another difference is that call to canEvaluatePolicy (3) might return an error, eg. LAError(.biometryLockout) (if implemented correctly) preventing as from returning biometryStateHash (5) with nil value. This is not the case for new API, where the same call (2) will yield nil as a result - LADomainStateBiometry documentation does not mention it. In summary, here are some questions: Which API should be used to retrieve biometry type?, and why the "older way" has not been deprecated? Is is safe to assume that calls to biometryType and stateHash from LADomainStateBiometry will produce meaningful results without prior call to canEvaluatePolicy? Should I assume that call to biometryType found on LAContext instance will always return biometryType without prior call to canEvaluatePolicy?, or perhaps those are only side effects of changes made to accommodate LADomainState, and prior to them (pre-iOS 18) we must call canEvaluatePolicy to get meaningful value. Are the stateHash properties found on LADomainState, LADomainStateBiometry and LADomainStateCompanion will return nil upon encountering any error under the hood? (which would be equivalent of below code, prior to iOS 18) func biometryStateHash() -> Data? { let context = LAContext() if #available(iOS 18, macOS 15, *) { _ = context.canEvaluatePolicy(policy, error: nil) return context.evaluatedPolicyDomainState } else { return context.domainState.biometry.stateHash } } 1.2 Deprecation of evaluatedDomainState There is a forum post LAContext.evaluatedPolicyDomainState change between major OS versions mentioning missing documentation (fixed), however there's still information missing of how they correlate to each other. From my findings, the deprecated evaluatedDomainState property value matches those of LADomainState stateHash (when no companion device is present), and LADomainStateBiometry stateHash (all the time). Are those assumptions correct? 1.3 LAContext (authenticated) session lifespan Theres is little information about it state when authenticated by the user. Documentation on LAContext does not mention this behavior, while there are hints that once authenticated, and context is reused, any farther calls will not prompt user with UI. The problem is that this behavior is little, to no documented. Here are few examples I have found: Logging a User into Your App with Face ID or Touch ID (code sample) contains comment // Get a fresh context for each login. If you use the same context on multiple attempts //  (by commenting out the next line), then a previously successful authentication //  causes the next policy evaluation to succeed without testing biometry again. //  That's usually not what you want. Recent forum post, where such approach is mentioned by Quinn 'The Eskimo!' "At the API level, one option you have is to create an LAContext and pass it in to each SecItemCopyMatching call via kSecUseAuthenticationContext." WWDC22 Streamline local authorization flows session "By binding the LAContext to our private key reference, we ensure that executing the signature operation will not trigger another authentication, while allowing the operation to continue without unnecessary prompts. These binding also means that no additional user interactions will be required for future signatures until the LAContext is invalidated." Furthermore this is complicated by the touchIDAuthenticationAllowableReuseDuration property from LAContext instance which states that "The default value is 0, meaning that no previous biometric unlock can be reused." which is in direct contradiction to what I have experienced while working with LAContext and sources mentioned above. While digging on this, whether this behavior is intended or not, I came across a post (I would love to share it, but the domain is not permitted) that shared the same findings (and concerns) regarding LAContext behavior as me. The author also provided a FB9984036 feedback number - although no further update was made on that topic. So my questions are: Is it safe to reuse LAContext (authenticated) instance? How long such instance is considered authenticated?, is it a time duration or perhaps it stays in authenticated state until explicitly invalidated using invalidate method. (its invalidated for sure when app is terminated, but this was to be expected :)) How does,touchIDAuthenticationAllowableReuseDuration work, and how does it correlate to "reusability" of the authenticated LAContext instance? In what scenarios, touchIDAuthenticationAllowableReuseDuration should be used and what is its expected behavior? (I have tried it both on iOS and macOS; from my perspective API this does not "work")

"Privilege separation" is one of the "two main reasons to use XPC services" given by https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html — With traditional applications, if an application becomes compromised through a buffer overflow or other security vulnerability, the attacker gains the ability to do anything that the user can do. To mitigate this risk, Mac OS X provides sandboxing—limiting what types of operations a process can perform. […] Each XPC service has its own sandbox, so XPC services can make it easier to implement proper privilege separation. The idea (iiuc) being that if the main process is compromised, the spicier operations have been separated out to a separate process space, and this improves the security of the system. But if the main process is compromised, and that main process is trusted by the more-privileged XPC service, is not the system still compromised in practice? That is rather than the exploit being: exploit some vulnerability gain arbitrary code execution do something naughty isn't the same still possible with just one extra step: exploit vulnerability arbitrary execution ask the XPC service nicely… …to do something naughty?

While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if present) let biometryType = context.biometryType // (4) let biometryStateHash = context.evaluatedPolicyDomainState // (5) } However, moving let biometryType = context.biometryType (4) before call to canEvaluatePolicy (3) still yields correct biometry type. This is in contradiction to article from Local Authentication documentation page Optionally, Adjust Your User Interface to Accommodate Face ID. Furthermore, biometryType documentation does not mentions such requirement. Another difference is that call to canEvaluatePolicy (3) might return an error, eg. LAError(.biometryLockout) (if implemented correctly) preventing as from returning biometryStateHash (5) with nil value. This is not the case for new API, where the same call (2) will yield nil as a result - LADomainStateBiometry documentation does not mention it. In summary, here are some questions: Which API should be used to retrieve biometry type?, and why the "older way" has not been deprecated? Is is safe to assume that calls to biometryType and stateHash from LADomainStateBiometry will produce meaningful results without prior call to canEvaluatePolicy? Should I assume that call to biometryType found on LAContext instance will always return biometryType without prior call to canEvaluatePolicy?, or perhaps those are only side effects of changes made to accommodate LADomainState, and prior to them (pre-iOS 18) we must call canEvaluatePolicy to get meaningful value. Are the stateHash properties found on LADomainState, LADomainStateBiometry and LADomainStateCompanion will return nil upon encountering any error under the hood? (which would be equivalent of below code, prior to iOS 18) func biometryStateHash() -> Data? { let context = LAContext() if #available(iOS 18, macOS 15, *) { _ = context.canEvaluatePolicy(policy, error: nil) return context.evaluatedPolicyDomainState } else { return context.domainState.biometry.stateHash } } 1.2 Deprecation of evaluatedDomainState There is a forum post LAContext.evaluatedPolicyDomainState change between major OS versions mentioning missing documentation (fixed), however there's still information missing of how they correlate to each other. From my findings, the deprecated evaluatedDomainState property value matches those of LADomainState stateHash (when no companion device is present), and LADomainStateBiometry stateHash (all the time). Are those assumptions correct? 1.3 LAContext (authenticated) session lifespan Theres is little information about it state when authenticated by the user. Documentation on LAContext does not mention this behavior, while there are hints that once authenticated, and context is reused, any farther calls will not prompt user with UI. The problem is that this behavior is little, to no documented. Here are few examples I have found: Logging a User into Your App with Face ID or Touch ID (code sample) contains comment // Get a fresh context for each login. If you use the same context on multiple attempts //  (by commenting out the next line), then a previously successful authentication //  causes the next policy evaluation to succeed without testing biometry again. //  That's usually not what you want. Recent forum post, where such approach is mentioned by Quinn 'The Eskimo!' "At the API level, one option you have is to create an LAContext and pass it in to each SecItemCopyMatching call via kSecUseAuthenticationContext." WWDC22 Streamline local authorization flows session "By binding the LAContext to our private key reference, we ensure that executing the signature operation will not trigger another authentication, while allowing the operation to continue without unnecessary prompts. These binding also means that no additional user interactions will be required for future signatures until the LAContext is invalidated." Furthermore this is complicated by the touchIDAuthenticationAllowableReuseDuration property from LAContext instance which states that "The default value is 0, meaning that no previous biometric unlock can be reused." which is in direct contradiction to what I have experienced while working with LAContext and sources mentioned above. While digging on this, whether this behavior is intended or not, I came across a post (I would love to share it, but the domain is not permitted) that shared the same findings (and concerns) regarding LAContext behavior as me. The author also provided a FB9984036 feedback number - although no further update was made on that topic. So my questions are: Is it safe to reuse LAContext (authenticated) instance? How long such instance is considered authenticated?, is it a time duration or perhaps it stays in authenticated state until explicitly invalidated using invalidate method. (its invalidated for sure when app is terminated, but this was to be expected :)) How does touchIDAuthenticationAllowableReuseDuration work, and how does it correlate to "reusability" of the authenticated LAContext instance? In what scenarios touchIDAuthenticationAllowableReuseDuration should be used and what is its expected behavior? (I have tried it both on iOS and macOS; from my perspective API this does not "work")

I am developing a library called MemoryCryptor for macOS. Its purpose is to protect sensitive data of the calling process (including launchd daemons), e.g. user passwords and other secrets, from being written to disk or read directly by debuggers or malware. This is a mandatory security requirement from our internal Security Team. On Windows we rely on DPAPI, which stores a per‑process cryptographic key outside the calling process’s address space, ensuring that key material and ciphertext never coexist in the same memory space. I have evaluated the following macOS options, but each presents limitations for our threat model: Secure Enclave (CryptoKit.framework). Keys generated using the Secure Enclave are not bound to the creating app. The dataRepresentation of a PrivateKey resides in the caller’s memory, allowing another process that can read a memory dump on the same machine to decrypt the data. Keychain API. Keys are always loaded into the calling process’s address space before any cryptographic operation, exposing them to memory‑dump attacks. Separate helper via XPC. While this could isolate key material, it requires full control of IPC implementation - plaintext may remain in the implementation's internal buffers. Given these constraints, are there any macOS‑native mechanisms or recommended architectures that allow us to keep cryptographic keys completely out of the calling process’s memory while still performing encryption/decryption on behalf of that process? Any guidance, best‑practice references, or alternative APIs would be greatly appreciated. Thank you for your assistance.

Dear Apple Developer Support Team, I would like to inquire whether there is a stable and official method to obtain the correct Team ID. When my app attempts to store data in the Keychain on a physical device, the retrieved Team ID is an unknown one and does not match the Team ID of my developer certificate. This issue consistently results in Keychain access failure with error code -34018. Could you please advise the root cause and provide a reliable solution to fix this Team ID mismatch and resolve the -34018 Keychain error? NSDictionary *query = [NSDictionary dictionaryWithObjectsAndKeys: kSecClassGenericPassword, kSecClass, @"bundleSeedID", kSecAttrAccount, @"", kSecAttrService, (id)kCFBooleanTrue, kSecReturnAttributes, nil]; CFDictionaryRef result = nil; OSStatus status = SecItemCopyMatching((CFDictionaryRef)query, (CFTypeRef *)&result); if (status == errSecItemNotFound) status = SecItemAdd((CFDictionaryRef)query, (CFTypeRef *)&result); if (status != errSecSuccess) return nil; NSString *accessGroup = [(__bridge NSDictionary *)result objectForKey:kSecAttrAccessGroup]; NSArray *components = [accessGroup componentsSeparatedByString:@"."]; NSString *bundleSeedID = [[components objectEnumerator] nextObject]; CFRelease(result); return bundleSeedID;

I have enabled FileVault on macOS having a custom authorisation plugin , which will load our multi-factor authentication (MFA) window . This third-party custom authorisation plugin replaced loginwindow:login mechanism from authorisation db (system.login.console) .After these changes, during reboot, we observed that the focus isnt on our custom Xib window.We noticed that the custom Xib window is rendered on a completely black background . End user has to use mouse to click on the custom Xib window, so that the textbox gains its focus. The possible solutions we have tried, Simulating mouse click Making Window to gain focus using makeKeyAndOrderFront Steps to reproduce: Enable Filevault on the machine Remove loginwindow:login and add your custom authorisation plugin in its place with a textbox to capture password 3.Perform reboot of the machine 4.The custom xib window is rendered on a black window but the window doesnt gain focus. The user has to perform a mouse click on the window to gain its focus Any help would be greatly appreciated on the above mentioned issue

I am using the CryptoKit SecureEnclave enum to generate Secure Enclave keys. I've got a couple of questions: What is the lifetime of these keys? When I don't store them somewhere, how does the Secure Enclave know they are gone? Do backups impact these keys? I.e. can I lose access to the key when I restore a backup? Do these keys count to the total storage capacity of the Secure Enclave? If I recall correctly, the Secure Enclave has a limited storage capacity. Do the SecureEnclave key instances count towards this storage capacity? What is the dataRepresentation and how can I use this? I'd like to store the Secure Enclave (preferably not in the Keychain due to its limitations). Is it "okay" to store this elsewhere, for instance in a file or in the UserDefaults? Can the dataRepresentation be used in other apps? If I had the capability of extracting the dataRepresentation as an attacker, could I then rebuild that key in my malicious app, as the key can be rebuilt with the Secure Enclave on the same device, or are there measures in place to prevent this (sandbox, bundle id, etc.)

In macOS Tahoe 26.4.1 we noticed that when we use our custom authorisation plugin to perform unlock using SF Authorisation Plugin View, the SF window isnt focused. User has to manually click on it to type in the password. We also noticed that this wasnt the case in macOS Tahoe 26.2 . Can you kindly suggest us if any flags have to be enabled for the same? Any help on this issue is highly appreciated

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?

Hi! Is there currently any public API for product engineers to query for Guest User mode?^1 Is there an API product engineers can query at runtime to determine if their app is running as a Guest User on visionOS? I am not able to find any API that directly returns this information. But it does look some APIs can indirectly return this. HealthKit can condition some of its response values on Guest User mode.^2 It is possible that querying through HealthKit might be a workaround. But it would require asking for health data even in Vision Apps that do not really need health data. I would still be looking for something like a direct Guest User API if that was available. Thanks!

Background We're building a macOS application that acts as a CryptoTokenKit software token. The architecture follows the documented pattern: a container app (a long-running agent process) manages token registration and identity updates via TKTokenDriverConfiguration, and a separate appex extension process handles the actual signing operations for client sessions. What we're doing At agent startup, the container app calls [TKTokenDriverConfiguration driverConfigurations] to obtain our token driver, then registers a token instance ID: NSDictionary<TKTokenDriverClassID, TKTokenDriverConfiguration *> *driverConfigurations = [TKTokenDriverConfiguration driverConfigurations]; TKTokenDriverConfiguration driver = / first value from driverConfigurations */; [driver addTokenConfigurationForTokenInstanceID:@"setoken"]; When the agent renews a certificate, it pushes updated TKTokenKeychainItem objects to ctkd by setting keychainItems on the TKTokenConfiguration: TKTokenConfiguration *tokenCfg = driver.tokenConfigurations[@"setoken"]; tokenCfg.keychainItems = updatedItems; This works correctly during normal operation. The failure When ctkd is restarted (e.g., killall ctkd, or the system restarts the daemon), all subsequent calls through the existing TKTokenDriverConfiguration reference silently fail. Specifically: [TKTokenDriverConfiguration driverConfigurations] returns the same stale object - it does not establish a new connection to the newly-started ctkd process. There is no error, no exception, and no indication the returned object is invalid. driver.tokenConfigurations[@"setoken"] still returns a non-nil value reflecting the pre-restart state - so any nil check intended to detect "token not registered with ctkd" does not fire. [driver addTokenConfigurationForTokenInstanceID:@"setoken"] appears to succeed (no error) but the token is not actually registered with the new ctkd instance. Setting tokenCfg.keychainItems = updatedItems appears to succeed but the new ctkd instance has no knowledge of the update. The only reliable recovery we've found is restarting the container app process itself, at which point [TKTokenDriverConfiguration driverConfigurations] returns a fresh object connected to the new ctkd instance. What we've investigated There is no public API on TKTokenDriverConfiguration to invalidate or refresh the internal XPC connection to ctkd TKTokenWatcher can observe token insertions/removals, but we found no documented way to use it to detect a ctkd process restart specifically The NSXPCConnection invalidation handler pattern is not accessible through the TKTokenDriverConfiguration abstraction Moving credential management into the appex extension. Since the appex extension is recreated when the ctkd process restarts, we are able to update keychainItems from the extension. However, this comes with it's own set of problems: the extension is ephemeral and using the keychain APIs directly from the extension is not well documented and does not appear to be a supported pattern. Questions Is there a supported API to detect that ctkd has restarted and that the existing TKTokenDriverConfiguration reference is no longer valid? Is there a supported way to obtain a fresh TKTokenDriverConfiguration without restarting the container app? Should the container app be re-architected to avoid holding long-lived TKTokenDriverConfiguration references?

Symptom Production iOS app (TestFlight) using App Attest. Devices generate assertions via DCAppAttestService (through Firebase App Check, which forwards to Apple's validation infrastructure). The fleet was attesting cleanly at ~100% verified for the first ~7 days post-first-install per device — then collapsed to ~0% verified once the initial token's natural TTL expired and devices were forced to re-attest. Has stayed at ~0% for 3+ days. Affects all 4 physical TestFlight devices; not reproducing on simulators (which is expected — App Attest unavailable there). The downstream validator's metric specifically categorizes these as "invalid" — meaning a token reached it and was rejected as cryptographically invalid — not as "no token sent" / "unrecognized origin" / "outdated SDK." Environment iOS 26.x (26.3.1 confirmed on multiple devices). Team ID T68SS8UY5J, bundle com.calimento.app, App ID has App Attest capability checked. Entitlements signed into binary: com.apple.developer.devicecheck.appattest-environment = production. Xcode would refuse this embed if the App ID lost the capability — so capability state is verifiably intact. Provisioning profile UUID byte-identical between the last verified-traffic build and the first invalid-traffic build (confirmed via Xcode build logs). Same code-signing identity hash across both builds. TestFlight builds approved by Apple Beta Review. What's been ruled out Provisioning / signing / certificate drift (UUID and cert hash unchanged across builds). App ID capability revocation (entitlement embed succeeded). Firebase iOS app config drift (GoogleService-Info.plist byte-identical across vault, local working tree, and Firebase Console download). Token attachment / SDK init race (0% of requests in the "no token" or "outdated client" buckets). Pod / dependency drift (package-lock byte-identical between verified and failing builds). The integration was producing valid assertions for ~7 days post-install per device — code-side bugs would have manifested from day one, not synchronized to the TTL boundary. Questions Are there known iOS 26.x server-side issues with App Attest assertion validation that would cause hardware-generated assertions to be rejected as cryptographically invalid? Is there a documented or undocumented abuse-mitigation behavior that downgrades or invalidates assertions for an App ID under specific conditions — e.g., after a volume threshold within a window, or after a fingerprint anomaly? Looking specifically at whether high attestation churn during development can leave an App ID's attestation state in a degraded mode. Is there any way to inspect Apple's reason for rejecting a specific assertion — through a developer tool, console log, or feedback channel? The downstream validator only surfaces"invalid"; it doesn't report Apple's underlying rejection reason. Recovery semantics: if a device's keyId ends up internally blocklisted, does it age out, or is the device permanently unable to produce valid assertions for that App ID? appattest-environment = production validation flow: any way the production environment validator could differ from development in a way that produces this signature? Why I'm filing here rather than only with the SDK maintainer: The SDK is reliably attaching tokens (0% in the "no token" bucket). Origin is being recognized (0% in the "unknown origin" bucket). The rejection is happening at signature validation — which is downstream of any client-SDK behavior. Cross-filed with the React Native Firebase maintainers at [https://github.com/invertase/react-native-firebase/issues/9008]; if the root cause turns out to be on the wrapper's side, that thread will be closed. Happy to provide raw build logs, validator metric exports, or a build for a test device on Apple's side privately.

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!

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!

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

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?

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.

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.

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.

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.