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?

Hi, We are using the MSAL library to authenticate users, with SSO authentication implemented through the Microsoft Authenticator app. The problem is that once or twice a day, a prompt for forced authentication appears, indicating that silent token acquisition is failing and resulting in a requirement for forced authentication. Below are some of the logs: ================================================= 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] Silent flow finished. Result (null), error: -51115 error domain: MSIDErrorDomain 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] acquireTokenSilent returning with error: (MSALErrorDomain, -50002) Masked(not-null) ==================================================== We initially raised this issue with Microsoft, but according to them: In the app's logs, the single one failure it contains, was when the SSO extension returned the error com.apple.AuthenticationServices.AuthorizationError, -6000 during a silent call. This error code is generated by the system framework (Apple), not by our code. It indicates that the framework encountered an unexpected internal issue before or after calling the SSO extension. MSAL returning interaction_required to the client app is the most effective way to recover from this error (as you mention, after the user selects the account the app continues working as expected). Additionally, as you also mention, the interactive call is made by switching to Authenticator (not displaying a "window" without leaving Eva Lite app), which means MSAL is not able to use the SSO extension and is using the fallback to legacy authentication. The recommended next step is for the customer to request support directly from Apple as this is an issue on their side. Additionally, the customer can also try to update to the latest iOS, in case Apple has already fixed this issue. ============================================= STEPS TO REPRODUCE There is no such steps its just that this is an enterprise application which is getting used on managed devices[iPhone 14]. The device are managed using some intune policy. Platform and Version: iOS Development Environment: Xcode 15, macOS 13.6.1 Run-time Configuration: iOS 18 Please let me know if there are any solutions to resolve this problem. Thank you.

I’m implementing passkey registration and authentication in an iOS 17 app with a credential provider extension, but I’m running into an issue. Setup: I have a credential provider target configured. The app correctly shows the pop-up to register the passkey with my app. My Info.plist is set up properly. Issue: When the following function is triggered: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { "code to generate registrationRequest..." let controller = ASAuthorizationController(authorizationRequests: [registrationRequest]) controller.delegate = self controller.presentationContextProvider = self controller.performRequests() } I get the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 I do not own the relying party domain (e.g., https://webauthn.io), so I cannot configure an apple-app-site-association file on the website. Question: How can I register and authenticate passkeys on any site that allows passkeys (such as webauthn.io) when I don’t control the webpage? Are there any workarounds or best practices for handling this in iOS 17? Any insights would be greatly appreciated!

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!

We are working on a PoC iOS App to use "Sign in with Apple" on iOS. The app needs to authenticate the current user on MDM managed corporate iPads (with Shared iPad enabled) and each user having a Managed Apple ID (created in Apple Business Manager). We have started with Apple's example app: https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple When we run it on a normal iPad (without MDM supervision) it works fine. When we run the same code on a managed iPad with Shared iPad enabled and Managed Apple ID's the app errors out when a user taps the "Sign in with Apple" button. A User-facing error message is displayed: “Your Apple Account cannot be used to create accounts for other apps.” And when we run the app from Xcode we see the following logs: Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" Could not authenticate: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) We have confirmed that in ABM "Sign in with Apple" feature is enabled with "Allowed apps": "All apps". We have also confirmed that the Managed AppleIDs created in ABM have no field to provide the birthday of the user and therefore ruling out age restrictions for "Sign in with Apple". Is "Sign in with Apple" supported in MDM managed iPADs with Shared iPad enabled and managed AppleIDs? If it is supported, do we know what other configurations we need to get it to work? Do we know why "Sign in with Apple" would error out with Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, Environment: • iPadOS version: IPadOS Version 18.7 • Xcode version: Version 26.0 (17A324) • Device type: iPad Air 11-inch (M3) in Shared iPad mode • Account type: Managed Apple ID created in ABM enrolled with Intune MDM) Thank you

Sign up not completed when I log to an app using apple id. What should i do?

When an app is trying to access identities put in the keychain by cryptotokenkit extension, the user gets asked a permission pop-up which reads 'Token Access Request" would like access a token provided by: " with 2 options 'Don't allow' and 'OK' I accidently clicked "Don't allow" and now can't access identities put in crypto token kit. How can I reset the preference?

Hi everyone, I’m looking for clarification on best practices for storing API keys in an iOS app — for example, keys used with RevenueCat, PostHog, AWS Rekognition, barcode scanners, and similar third-party services. I understand that hard-coding API keys directly in the app’s source code is a bad idea, since they can be extracted from the binary. However, using a .plist file doesn’t seem secure either, as it’s still bundled with the app and can be inspected. I’m wondering: What are Apple’s recommended approaches for managing these kinds of keys? Does Xcode Cloud offer a built-in or best-practice method for securely injecting environment variables or secrets at build time? Would using an external service like AWS Secrets Manager or another server-side solution make sense for this use case? Any insights or examples of how others are handling this securely within Apple’s ecosystem would be greatly appreciated. Thanks for considering my questions! — Paul

I have a project with a single app target that serves two environments, and two schemes, one for each env, using xcconfig files for defining environment-specific stuff. I'm trying to figure this out for months, so I've tried multiple approaches throughout this period: Have a single domain in "Associated domains" in Xcode, defined as webcredentials:X where X gets replaced using a value from xcconfig. Have two domain entries in "Associated domains" webcredentials:PROD_DOMAIN and webcredentials:STAGING_DOMAIN. Have a different order of domains Results are very interesting: whatever I do, whatever approach I take, password autofill works on staging, but doesn't work on production. I'm aware that we need to test production on Test Flight and AppStore builds. That's how we're testing it, and it's not working. Tested on multiple devices, on multiple networks (wifi + mobile data), in multiple countries.. you name it. The server side team has checked their implementation a dozen times; it's all configured properly, in the exact same way across environments (except bundle ID, ofc). We tried a couple websites for validating the apple-app-site-association file, and while all of those are focused on testing universal links, they all reported that the file is configured properly. Still, password autofill doesn't work. I prefer not to share my app's domains publicly here. Ideally I would contact Apple Developer Support directly, but they now require a test project for that, and since 'a test project' is not applicable to my issue, I'm posting here instead.

Hello, I’m storing some values in the Keychain with the attribute ‘ksecattraccessibleafterfirstunlockthisdeviceonly’ (https://developer.apple.com/documentation/security/ksecattraccessibleafterfirstunlockthisdeviceonly). When I migrate user data between iPhones via iCloud, this behaves as expected and the keys are not preserved. However, when I migrate using a direct connection between two devices, the keys are preserved, which seems to contradict the attribute’s intent. Is this a known behavior, and if so, is there a workaround?

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?

Hello, I am at wits' end with the Apple Sign-in api. I have tested in stage and it works beautifully, but when i push to production it gives me the error "invalid_client". I'm confident the setup is correct, when I asked Apple for help over the phone, they sent me a few forums with no answers. Has anyone had the same issue? How did you resolve? Could it be because I have two app IDs and two service IDs? (prod + stage) Help!

We are currently experiencing an unexpected issue with the DeviceCheck query_two_bits endpoint. According to the official documentation (Accessing and Modifying Per-Device Data), the last_update_time field should represent the month and year when the bits were last modified. The Issue: For several specific device tokens, our server is receiving a last_update_time value that is set in the future. Current Date: April 2026 Returned last_update_time: 2026-12 (December 2026) Here is a response: { "body": "{\"bit0\":false,\"bit1\":true,\"last_update_time\":\"2026-12\"}", "headers": { "Server": ["Apple"], "Date": ["Thu, 02 Apr 2026 06:05:23 GMT"], "Content-Type": ["application/json; charset=UTF-8"], "Transfer-Encoding": ["chunked"], "Connection": ["keep-alive"], "X-Apple-Request-UUID": ["53e16c38-d9f7-4d58-a354-ce07a4eaa35b"], "X-Responding-Instance": ["af-bit-store-56b5b6b478-k8hnh"], "Strict-Transport-Security": ["max-age=31536000; includeSubdomains"], "X-Frame-Options": ["SAMEORIGIN"], "X-Content-Type-Options": ["nosniff"], "X-XSS-Protection": ["1; mode=block"] }, "statusCode": "OK", "statusCodeValue": 200 } Technical Details: Endpoint: https://api.development.devicecheck.apple.com/v1/query_two_bits (also occurring in Production) Response Body Example: JSON { "bit0": true, "bit1": false, "last_update_time": "2026-12" } Observations: This occurs even when our server has not sent an update_two_bits request for that specific device in the current month. Questions: Is there a known issue with the timestamp synchronization or regional database propagation for DeviceCheck? Does the last_update_time field ever represent an expiration date or any value other than the "last modified" month? Best regards,

Hello, I am using the prf extension for passkeys that is available since ios 18 and macos15. I am using a fixed, hardcoded prf input when creating or geting the credentials. After creating a passkey, i try to get the credentials and retrieve the prf output, which works great, but i am getting different prf outputs for the same credential and same prf input used in the following scenarios: Logging in directly (platform authenticator) on my macbook/iphone/ipad i get "prf output X" consistently for the 3 devices When i use my iphone/ipad to scan the qr code on my macbook (cross-platform authenticator) i get "prf output Y" consistently with both my ipad and iphone. Is this intended? Is there a way to get deterministic prf output for both platform and cross-platform auth attachements while using the same credential and prf input?

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?

Hello, I'm developing an iOS app that includes a Sign In with Apple feature. I’ve completed the following setup steps: Enabled Sign In with Apple for the app’s Bundle ID in the Apple Developer Console. Added Sign In with Apple capability in Xcode under Signing & Capabilities. Tested the feature on a real device, not a simulator. Registered the real device ID in the Developer Console just in case any hidden permission issues exist. Despite following all the necessary steps (and even using the official Apple sample code) the Sign In bottom sheet displays a "Sign Up Not Completed" message. Unfortunately, I don’t receive any further error details to help diagnose the issue. After searching through StackOverflow and this forum, I came across posts suggesting that the feature might take up to 48 hours to become active after setup. Is this still the case in 2025? Or is there something I might be missing? For additional context: other features such as APNs (Push Notifications) are working as expected. Thank you in advance for any help or insight!

Hello, Thanks for the new video on Memory Integrity Enforcement! Is the presented app's sample code available (so that we can play with it and find & fix the bug on our own, using Soft Mode)? Thanks in advance!

Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18 I install and launch my private MAUI App I ask for example Bluetooth permissions (can be any other permission) I tap Allow button on native settings (or Don't Allow) I unistall app from real phone (we can wait for a while) I install and launch My Private MAUI App I ask for example Bluetooth permissions &lt;- here is an issue. Bluetooth is already granted, so I cannot ask for it again. Occurrence: This issue occurs inconsistently: On iOS 18.5: approximately 5 out of 10 times On iOS 17: approximately 1 out of 50 times Tested using my automated system using Appium latest. After each scenario I unistall app using: "mobile: removeApp" with bundleId

Our app uses Sign in with Apple. In recent weeks (or months), we've noticed that emails sent to @privaterelay.appleid.com addresses are not being delivered. We're not receiving any bouncebacks or error messages from the mail server, but the emails never reach the user's mailbox. We've also checked spam folders, with no luck. We have verified that our Email Sources are configured correctly in Apple Developer settings. Is there any way to debug or trace what might be happening with these messages? Thanks in advance!