Hi! Is it possible to disable the option for users to 'Sign in with Another Device'? I encounter this message during the authentication process and I want to prevent it from appearing. I appreciate your help and look forward to your response.
General
RSS for tagPrioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Is there any particular reason why ASWebAuthenticationSession doesn't have support for async/await? (example below)
do {
let callbackURL = try await webAuthSession.start()
} catch {
// handle error
}
I'm curious if this style of integration doesn't exist for architectural reasons? Or is the legacy completion handler style preserved in order to prevent existing integrations from breaking?
Hi Apple,
Currently we want to have enhancement for SMS OTP that we want to implement OTP Autofill, But after do some research we're stuck with option that the OTP only show in keyboard suggestion, is there any way for making OTP is automatically filled without user have to click the keyboard suggestion when receiving the SMS.
Thanks
Best Regards,
Admiral Sultano Harly.
Hi,
After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26.
Deployment target: iOS 15.0
Capability: Enhanced Security (added via Signing & Capabilities tab)
Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile.
It works fine on iOS 26 devices.
I’d like to confirm Apple’s intent here:
Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions?
Or should older systems ignore the entitlement, meaning this behavior might be a bug?
Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback.
When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue:
If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior).
If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session.
What I've Tried:
Attempted to imitate mouse movement after the push button was clicked to keep the session active.
Created a display sleep prevention assertion using IOKit to prevent the screen from turning off.
Used the caffeinate command to keep the display and system awake.
Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off.
I also checked the system logs when this issue occurred and found the following messages:
___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout
loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen
loginwindow: SleepDisplay | enter
powerd: Process (loginwindow) is requesting display idle___
These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely.
Questions:
Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override?
Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications?
Any guidance or insights would be greatly appreciated. Thank you!
I have been able to save and remove ASPasskeyCredentialIdentities in the ASCredentialIdentityStore. But after saving a ASPasskeyCredentialIdentity, when I retrieve the current identities stored, it always returns an empty list. I check to make sure the store is enabled. I am using this method which is available starting with iOS 17.4:
extension ASCredentialIdentityStore {
public func credentialIdentities(forService serviceIdentifier: ASCredentialServiceIdentifier? = nil, credentialIdentityTypes: ASCredentialIdentityStore.IdentityTypes = []) async -> [any ASCredentialIdentity]
}
I have called it like this:
store.credentialIdentities(forService: nil, credentialIdentityTypes: .passkey)
And this:
store.credentialIdentities()
Has anyone got this to work?
I have a binary executable which needs to be given Accessibility Permissions so it can inject keypresses and mouse moves. This was always possible up to macOS 15 - when the first keypress arrived the Accessibility Permissions window would open and allow me to add the executable. However this no longer works in macOS 26: the window still opens, I navigate to the executable file and select it but it doesn't appear in the list. No error message appears.
I'm guessing that this may be due to some tightening of security in Tahoe but I need to figure out what to change with my executable to allow it to work.
How can my password manager app redirect users to the “AutoFill Passwords & Passkeys” settings page?
Hi all,
I’m building a password manager app for iOS. The app implements an ASCredentialProviderExtension and has the entitlement com.apple.developer.authentication-services.autofill-credential-provider.
From a UX perspective, I’d like to help users enable my app under:
Settings → General → AutoFill & Passwords
What I’ve observed:
Calling UIApplication.openSettingsURLString only opens my app’s own Settings page, not the AutoFill list.
Some apps (e.g. Google Authenticator) appear to redirect users directly into the AutoFill Passwords & Passkeys screen when you tap “Enable AutoFill.”
1Password goes even further: when you tap “Enable” in 1Password App, it shows a system pop-up, prompts for Face ID, and then enables 1Password as the AutoFill provider without the user ever leaving the app.
Questions:
Is there a public API or entitlement that allows apps to deep-link users directly to the AutoFill Passwords & Passkeys screen?
Is there a supported API to programmatically request that my app be enabled as an AutoFill provider (similar to what 1Password seems to achieve)?
If not, what is the recommended approach for guiding users through this flow?
Thanks in advance!
Topic:
Privacy & Security
SubTopic:
General
Tags:
Wallet
Authentication Services
Passkeys in iCloud Keychain
Managed Settings
My app has been rejected by App Store review because the sign in with Apple functionality is not working properly. I'm able to reproduce the issue on my end but I don't understand why it's happening.
I have two other apps that implement the same OAuth flow in an identical manner, and those apps have no issues signing in with Apple.
I've copied my OAuth flow to a fresh project to see if that would make a difference, and it gives me the exact same error. In the simulator I get "invalid_request, invalid web redirect URL", and on-device the FaceID authentication fails with a very non-specific "Sign Up Not Completed" error.
I'm completely out of ideas here, so any guidance would be appreciated. Thanks!
I'm a bit confused about if using App Attest is possible in enterprise builds. It shows up under identifiers in the apple dev portal and I can add it to my provisioning file and entitlements file. But if I go to keys I cannot create a key for it.
This page implies it can be used for enterprise builds:
After distributing your app through TestFlight, the App Store, or the Apple Developer Enterprise Program, your app ignores the entitlement you set and uses the production environment.
The Passwords App is accessing websites found in the ASCredentialIdentityStore associated with a 3rd Party password management app (SamuraiSafe). This behaviour appears to be associated with looking up website favicons in order to display in Passwords. However the websites contacted are not stored in the Passwords App/iCloud KeyChain - only the 3rd Party password management app (SamuraiSafe). This is effectively leaking website information stored in the 3rd Party password management app.
I first noticed this behaviour on macOS, and it appears to happen every 8 days. Today it was seen on iOS.
The behaviour is revealed through the App Privacy Report on iOS (and LittleSnitch on macOS).
I would not be surprised to see the Passwords App do this for websites saved in the Passwords App/iCloud KeyChain, however I believe it should not be arbitrarily testing every website found in the ASCredentialIdentityStore as reference to that website url should be entirely under the control of the end user.
See attached screenshots from App Privacy Report.
Filed bug with Apple: FB16682423
Not getting ASCredentialServiceIdentifier in func prepareOneTimeCodeCredentialList(for serviceIdentifiers: [ASCredentialServiceIdentifier]) when trying to use ASCredentialProviderViewController for autofilling one time codes in iOS 18.
Dear Apple Developer Support,
We are currently encountering a recurring issue with the DeviceCheck API across multiple devices in our production environment.
The following error is frequently returned:
com.apple.devicecheck.error 0 We would like to ask the following:
What are the possible underlying causes that could lead to this specific error code (0) in the DeviceCheck API?
Is there any known behavior or condition where Wi-Fi network configurations (e.g., DNS filtering, proxy settings, captive portals) could result in this error?
Are there known timeouts, connectivity expectations, or TLS-level requirements that the DeviceCheck API enforces which could fail silently under certain network conditions?
Is this error ever triggered locally (e.g., client library-level issues) or is it always from a failed communication with Apple’s servers?
Any technical clarification, documentation, or internal insight into this error code would be greatly appreciated. This would help us significantly narrow down root causes and better support our users
I have had a password autofill app extension in production for years.
It still works fine.
Except when the user taps a username or password textfield and selects "AutoFill" from the context menu.
They are shown a modal error dialog, stating:
"AutoFill Unavailable - The developer needs to update it to work with this feature."
I cannot find any help on this issue.
The AutoFill extension works fine when tapping the "Passwords" bar above the iOS keyboard.
Any pointers would be appreciated.
Hi,
We are trying to open an application "xyz.app"
It worked fine until 15.1.1 versions. But facing issues with 15.2 and 15.3
The application is working fine when we navigate to xyz.app/Contents/MacOS/ and run applet in this directory.
But the error ""Not authorized to send Apple events to Finder"" occurs when we are trying to open the app directly.
Could someone please help me understand what might be causing this issue and how to resolve it?
Topic:
Privacy & Security
SubTopic:
General
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 <- 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
We're experiencing crashes in our production iOS app related to Apple's DeviceCheck framework. The crash occurs in DCAnalytics internal performance tracking, affecting some specific versions of iOS 18 (18.4.1, 18.5.0).
Crash Signature
CoreFoundation: -[__NSDictionaryM setObject:forKeyedSubscript:] + 460
DeviceCheck: -[DCAnalytics sendPerformanceForCategory:eventType:] + 236
Observed Patterns
Scenario 1 - Token Generation:
Crashed: com.appQueue
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010
DeviceCheck: -[DCDevice generateTokenWithCompletionHandler:]
Thread: Background dispatch queue
Scenario 2 - Support Check:
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008
DeviceCheck: -[DCDevice _isSupportedReturningError:]
DeviceCheck: -[DCDevice isSupported]
Thread: Main thread
Root Cause Analysis
The DCAnalytics component within DeviceCheck attempts to insert a nil value into an NSMutableDictionary when recording performance metrics, indicating missing nil validation before dictionary operations.
Reproduction Context
Crashes occur during standard DeviceCheck API usage:
Calling DCDevice.isSupported property
Calling DCDevice.generateToken(completionHandler:) (triggered by Firebase App Check SDK)
Both operations invoke internal analytics that fail with nil insertion attempts.
Concurrency Considerations
We've implemented sequential access guards around DeviceCheck token generation to prevent race conditions, yet crashes persist. This suggests the issue likely originates within the DeviceCheck framework's internal implementation rather than concurrent access from our application code.
Note: Scenario 2 occurs through Firebase SDK's App Check integration, which internally uses DeviceCheck for attestation.
Request
Can Apple engineering confirm if this is a known issue with DeviceCheck's analytics subsystem? Is there a recommended workaround to disable DCAnalytics or ensure thread-safe DeviceCheck API usage?
Any guidance on preventing these crashes would be appreciated.
We have a crash on DCDevice.current.isSupported
We want to try to make a serial queue to generate tokens but the side effect would be the same token would be used on multiple server API requests that are made within a few ms of each other?
Is this safe or will the Apple server immediately reject the same token being reused?
Can you share how long tokens are safe to use for?
Here is the code we want to try
final actor DeviceTokenController: NSObject {
static var shared: DeviceTokenController = .init()
private var tokenGenerationTask: Task<Data?, Never>?
var ephemeralDeviceToken: Data? {
get async {
// Re-using the token for short periods of time
if let existingTask = tokenGenerationTask {
return await existingTask.value
}
let task = Task<Data?, Never> {
guard DCDevice.current.isSupported else { return nil }
do {
return try await DCDevice.current.generateToken()
} catch {
Log("Failed to generate ephemeral device token", error)
return nil
}
}
tokenGenerationTask = task
let result = await task.value
tokenGenerationTask = nil
return result
}
}
}
Seeing the following error when attempting automatic passkey upgrade - [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
We're trying to enable Automatic passkey upgrade (https://developer.apple.com/videos/play/wwdc2024/10125/?time=38) for our website but it's not working from our testing on iOS 18.2 and 18.3 Beta Safari.
The flow on our website looks like:
the customers use autofill to fill out email and password on the sign-in page (abc.com/signin)
PublicKeyCredential.getClientCapabilities is called to check if conditionalCreate supported.
land on another page of our website (abc.com/pageX), which calls navigator.credentials.create with mediation conditional (Right after sign-in).
We checked that we followed the steps in above video: Allow automatic passkey upgrades is enabled, mediation is set to conditional and password autofill is used to signed in. However, Safari threw an error [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
Can Apple help guide us if anything is missed here?
Topic:
Privacy & Security
SubTopic:
General
Tags:
Passkeys in iCloud Keychain
Authentication Services
Hi,
The email attached
states that we need to add GoogleToolboxForMac's missing privacy manifest. I received the attached report
after running my app privacy report, however it is different and does not include GoogleToolboxForMac. I'm not sure if we need to add the privacy manifest for GoogleToolboxForMac alone or for both of them. If yes, what should I put in my privacy manifest for GoogleToolboxForMac?
IS IT BELOW CODE NEED TO ADD IN PRIVACY MANIFEST
OR
IS IT BELOW CODE NEED TO ADD IN PRIVACY MANIFEST
Please reply ASAP
Regards,
Viharshitha
Topic:
Privacy & Security
SubTopic:
General