I've made my first app and encountered an unexpected (potentially existential) issue.
The Manager app is designed to tag 3rd party "plugins" used by a DAW, storing metadata in a local SQLite database, and move them between Active and Inactive folders. This allows management of the plugin collection - the DAW only uses what's in the Active folder.
Permissions are obtained via security-scoped bookmarks on first launch. The app functions as intended: plugin bundles move correctly and the database tracks everything. No information is written to the plugins themselves.
The Problem:
When moving plugins using fs.rename() , the MAS sandbox automatically adds the com.apple.quarantine extended attribute to moved files. When the DAW subsequently rebuilds its plugin cache, it interprets quarantined plugins as "corrupt" or potentially malicious and refuses to load them.
Technical Details:
Moving files with NSFileManager or Node.js fs APIs within sandbox triggers quarantine
Sandboxed apps cannot call xattr -d com.apple.quarantine or use removexattr()
The entitlement com.apple.security.files.user-selected.read-write doesn't grant xattr removal rights
User workaround: run xattr -cr /path/to/plugins in Terminal - not acceptable for professional users
Question:
Is there any MAS-compliant way to move files without triggering quarantine, or to remove the quarantine attribute within the sandbox? The hardened-runtime DMG build works perfectly (no sandbox = no quarantine added).
Any insight appreciated!
Prioritize 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
Hello everyone,
I'm working on a project where I intend to use Secure Enclave-based, device-bound private keys within a Webauthn flow. I have the following question:
Is it possible to generate private keys in the Secure Enclave with integrated attestation in order to reliably prove to a relying party the authenticity and uncompromised state of the key?
If so, I would appreciate details on the implementation—specifically, any prerequisites, limitations, or particular API calls and configuration options that need to be considered.
I look forward to any advice, best practices, or pointers to further documentation on this topic.
Thank you in advance for your support!
Best regards,
Alex
Topic:
Privacy & Security
SubTopic:
General
Tags:
Authentication Services
Passkeys in iCloud Keychain
Hi,
I'm using webauthn.io to test my macOS Passkey application. When registering a passkey whichever value I set for User Verification, that's what I get when I check registrationRequest.userVerificationPreference on prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest).
However, when authenticating my passkey I can never get discouraged UV on prepareInterfaceToProvideCredential(for credentialRequest: any ASCredentialRequest).
In the WWDC 2022 Meet Passkeys video, it is stated that Apple will always require UV when biometrics are available. I use a Macbook Pro with TouchID, but if I'm working with my lid closed, shouldn't I be able to get .discouraged?
Topic:
Privacy & Security
SubTopic:
General
Tags:
Authentication Services
Passkeys in iCloud Keychain
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
https://developer.apple.com/news/?id=j9zukcr6
starting from Jan 2026 there is change in requirements for account notifications for Sign in with Apple.
Does this apply only to developers based in South Korea or all apps which are avai via the korean App Store?
The One-time codes documentation details how to enable autofill for SMS based codes. However, there is no details about how to correctly implement autofill for email based codes.
I am observing the email based autofill works inconsistently when using email based OTC. In my application:
There is latency of 10-15 seconds from when the email arrives to when it is available for autofill.
After the autofill feature is used, the OTC email is not being deleted from the inbox automatically.
Without documentation, it's unclear to me what I might be doing wrong that is causing these side effects.
I found an ietf proposal for how autofill with email based codes might work, but it’s unclear if this is how Apple has implemented the feature: https://www.ietf.org/archive/id/draft-wells-origin-bound-one-time-codes-00.html#name-email
Existing docs for Autofill using SMS: https://developer.apple.com/documentation/security/enabling-autofill-for-domain-bound-sms-codes
There’s a critical, actively exploited vulnerability in Apple’s iOS activation servers allowing unauthenticated XML payload injection:
https://cyberpress.org/apple-ios-activation-vulnerability/
This flaw targets the core activation process, bypassing normal security checks. Despite the severity, it’s barely discussed in public security channels.
Why is this not being addressed or publicly acknowledged? Apple developers and security researchers should urgently review and audit activation flows—this is a direct attack vector on device trust integrity.
Any insights or official response appreciated.
I noticed, that even though my AutoFill Credential Provider Extension works with Safari for both Passwords and Passkeys, it doesn't work in context menus inside arbitrary textfields, meanwhile the same is true for the Apple Passwords app. This is a great hit to AutoFill productivity, as my extension is unable to fill textfields by just going to the context menu and clicking AutoFill > Passwords..
Is this a feature only available to Apple via private APIs, or is this something I can interface with?
I checked and the Passwords app does use some undocumented but non-private entitlements:
[Key] com.apple.authentication-services.access-credential-identities
[Value]
[Bool] true
I also checked the responsible executable for some hints (AutoFillPanelService) however found nothing that would lead me to believe this is a public extension point.
Another idea I had was trying to use a macOS Service for this, however Services in the "General" category won't show up in any context menu, only in the Application's Main Menu.
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?
On iOS 26, QuickLookAR (ARQuickLookPreviewItem) shares the actual .usdz file via the system Share Sheet instead of the original website URL.
This is a regression from iOS 17–18, where sharing correctly preserved and sent only the source URL.
Repro steps:
1. Open a web-hosted USDZ model in QuickLookAR (Safari).
2. Tap Share.
3. Share via any messenger.
4. The full .usdz file is sent.
Expected:
Share Sheet sends only the original URL.
Actual:
Share Sheet sends the USDZ file.
Impact:
Uncontrolled distribution of proprietary 3D assets.
Critical IP / data leak.
Blocks production AR deployments relying on QuickLook.
Environment:
iOS 26.0–26.1, iPhone 14 / 15.
Works as expected on iOS 17–18.
Test case:
https://admixreality.com/ios26/
Topic:
Privacy & Security
SubTopic:
General
Hi everyone,
I'm currently working on a native macOS app (built with SwiftUI) and I'm trying to implement Password AutoFill functionality so users can use their saved credentials from Keychain or third-party password managers.
I've gone through Apple's documentation, WWDC sessions, and sample code, but I've noticed that the resources primarily focus on iOS and web implementations. There's very limited guidance specifically for macOS.
I've set up:
Associated Domains entitlement with the webcredentials: service
The apple-app-site-association file on my server
TextField with .textContentType(.username) and SecureField with .textContentType(.password)
However, I'm still not seeing the expected AutoFill behavior on macOS like I would on iOS.
Has anyone successfully implemented Password AutoFill on a native macOS app? Are there any macOS-specific considerations or additional steps required that differ from iOS?
Any guidance, sample code, or pointers to documentation I might have missed would be greatly appreciated.
We are currently trying to fix a bug when using SignIn with Apple. It appears that on some occasions we are not receiving a user's profile info (name, email) when a new account is created.
After doing some investigation we believe this bug is due to the same Apple login being used as an already deleted account. ASF only appears to send profile info the very first time an Apple login is used. If that account is deleted and another is created with the same apple login we won't receive the profile info.
As a result we are not in compliance with Apple's guidelines requiring that we use the provided profile info with Apple SigIn, and need to prompt users to enter it again.
Is there a process in place to properly "clear" a user after their account is deleted in our system, so that the next time a user creates an account with the same Apple login, we receive their profile info again?
Hello everyone.
Hope this one finds you well)
I have an issue with integrating a FIDO2 server with ASAuthorizationController.
I have managed to register a user with passkey successfully, however when authenticating, the request for authentication response fails. The server can't validate signature field.
I can see 2 possible causes for the issue: ASAuthorizationPlatformPublicKeyCredentialAssertion.rawAuthenticatorData contains invalid algorithm information (the server tries ES256, which ultimately fails with false response), or I have messed up Base64URL encoding for the signature property (which is unlikely, since all other fields also require Base64URL, and the server consumes them with no issues).
So the question is, what encryption algorithm does ASAuthorizationController use? Maybe someone has other ideas regarding where to look into?
Please help. Thanks)
If a user triggers account revoke on their Apple ID—but does not perform an in-app account deletion—will Apple send a server-to-server notification to inform us of this revoke event?
Additionally, in this scenario, if the user later wants to restore access to their existing game account data (for example, by re-binding Sign in with Apple or switching to another login method), are developers expected to restore all previously linked game data, or should the revoke event be treated as a permanent loss of authorization?
Hi! We're having issues with the sign in flow, starting today. As per the documentation, the issuer of the tokens should be https://appleid.apple.com sign in docs.
But in the published configuration, it is now stated as https://account.apple.com metadata endpoint.
Once the token is received through the sign in flow, the issuer is however still appleid.apple.com. This is causing problems for us where we expect the issuer in the metadata endpoint to be the same as the actual token issuer. What is correct here?
Topic:
Privacy & Security
SubTopic:
Sign in with Apple
Hello Team, We’ve recently started receiving reports from our customer base (Trellix) regarding issues with Full Disk Access (FDA) for Trellix binaries on macOS devices running Tahoe 26.1 (released on November 3, 2025).
The issue occurs when users attempt to add Trellix CLI binaries under FDA to grant the required permissions; the binaries fail to appear under the FDA settings, even after selection.
Upon further investigation, this appears to be a macOS 26.1–specific issue and not observed in earlier versions. Similar reports have been noted across various forums, indicating that the issue affects multiple binaries, not just Trellix:
Some of the discussions on the same issue I see online.
https://developer.apple.com/forums/thread/806187
https://developer.apple.com/forums/thread/806156
https://forum.logik.tv/t/macos-26-1-installation-issue-wait-before-updating/13761
https://www.reddit.com/r/MacOS/comments/1os1ph3/cant_add_anything_to_privacy_security_full_disk/
I have also logged FB21009024 for the same. We would like to understand when we can expect this to be fixed, since the issue persists even in 26.2 Beta and also whether the workaround of dragging and dropping the binaries can still be suggested?
Topic:
Privacy & Security
SubTopic:
General
Hi.
We are writing to report a critical issue we've encountered following the recent release of iOS 26 beta 6.
After updating our test devices, we discovered that our application is no longer able to establish HTTPS connections to several of our managed FQDNs. This issue was not present in beta 5 and appears to be a direct result of changes introduced in beta 6.
The specific FQDNs that are currently unreachable are:
d.socdm.com
i.socdm.com
tg.scodm.com
We have reviewed the official iOS & iPadOS 26 Beta 6 Release Notes, particularly the updates related to TLS. While the notes mention changes, we have confirmed that our servers for all affected FQDNs support TLS 1.2, so we believe they should still be compliant.
We have also investigated several of Apple's support documents regarding TLS connection requirements (e.g., HT214774, HT214041), but the information does not seem to apply to our situation, and we are currently unable to identify the root cause of this connection failure.
https://support.apple.com/en-us/102028
https://support.apple.com/en-us/103214
Although we hope this issue might be resolved in beta 7 or later, the official release is fast approaching, and this has become a critical concern for us.
Could you please provide any advice or insight into what might be causing this issue? Any guidance on potential changes in the networking or security frameworks in beta 6 that could affect TLS connections would be greatly appreciated.
We have attached the relevant code snippet that triggers the error, along with the corresponding Xcode logs, for your review.
Thank you for your time and assistance.
#import "ViewController.h"
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
NSURL *url = [NSURL URLWithString:@"https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js"];
NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL:url
cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
timeoutInterval:30.0];
[self sendWithRequest:req completionHandler:^(NSData *_Nullable data,
NSHTTPURLResponse *_Nonnull response,
NSError *_Nullable error) {
if (error){
NSLog(@"Error occurred: %@", error.localizedDescription);
return;
}else{
NSLog(@"Success! Status Code: %ld", (long)response.statusCode);
}
}];
}
- (void) sendWithRequest:(NSMutableURLRequest *)request
completionHandler:(void (^ _Nullable)(NSData *_Nullable data,
NSHTTPURLResponse *response,
NSError *_Nullable error))completionHandler {
NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
NSURLSession *session = nil;
session = [NSURLSession sessionWithConfiguration:configuration
delegate:self
delegateQueue:nil];
NSURLSessionTask *task = [session dataTaskWithRequest:request
completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
[session finishTasksAndInvalidate];
NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
if (error) {
if (completionHandler) {
completionHandler(nil, httpResponse, error);
}
}
else {
if (completionHandler) {
completionHandler(data, httpResponse, nil);
}
}
}];
[task resume];
}
@end
error
Connection 1: default TLS Trust evaluation failed(-9807)
Connection 1: TLS Trust encountered error 3:-9807
Connection 1: encountered error(3:-9807)
Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> HTTP load failed, 0/0 bytes (error code: -1202 [3:-9807])
Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> finished with error [-1202] Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=(
"<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>",
"<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>"
), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSErrorFailingURLStringKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSUnderlyingError=0x1062bf960 {Error Domain=kCFErrorDomainCFNetwork Code=-1202 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x10609d140>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9807, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9807, kCFStreamPropertySSLPeerCertificates=(
"<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>",
"<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>"
)}}, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>"
), _kCFStreamErrorCodeKey=-9807, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x10609d140>, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk.}
Error occurred: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk.
折りたたむ
Hi,
In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant.
We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally.
Environment
iOS 26.3
Real device
App Attest capability enabled
Correct App ID, Team ID and App Attest entitlement
Production environment
Characteristics:
appears constantly
affects only unique user
-Don't resolves after time or reinstall
not reproducible on our test devices
NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)")
We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier.
Please, help us any guidance for solution. Thank you
Our background monitoring application uses a Unix executable that requests Screen Recording permission via CGRequestScreenCaptureAccess(). This worked correctly in macOS Tahoe 26.0.1, but broke in 26.1.
Issue:
After calling CGRequestScreenCaptureAccess() in macOS Tahoe 26.1:
System dialog appears and opens System Settings
Our executable does NOT appear in the Screen Recording list
Manually adding via "+" button grants permission internally, but the executable still doesn't show in the UI
Users cannot verify or revoke permissions
Background:
Unix executable runs as a background process (not from Terminal)
Uses Accessibility APIs to retrieve window titles
Same issue occurs with Full Disk Access permissions
Environment:
macOS Tahoe 26.1 (worked in 26.0.1)
Background process (not launched from Terminal)
Questions:
Is this a bug or intentional design change in 26.1?
What's the recommended approach for background executables to properly register with TCC?
Are there specific requirements (Info.plist, etc.) needed?
This significantly impacts user experience as they cannot manage permissions through the UI.
Any guidance would be greatly appreciated. Thank you
Hi,
I'm trying to implement web-browser SignIn with Apple with my new app.
I'm trying to "Associate your website to your app" like described in this doc: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web
So I created a Service ID for this specific login. I want this login page to display my app icon and name when presented to users.
My issue:
When I associate my new app the the service, the link is somehow not working.
The login page show the "service" login (with a generic apple logo and the Service ID's name) instead of the actual App name.
I'v been able to link my new service to older apps succesfully !!! (the login page correctly shows the old apps icons and names)
Why is my new app not associated with the service ?
I am missing something here ? is there an additionnal step that I need to take in order to link the service to my newest app ?
Thanks !