I want to use incrementalUpdates for my app but store always returns false on my iPad with OS18.3.2.
I want to know what are th conditions in which store says its unable to perform incrementalUpdates?
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
I would like to confirm about fraud prevention using Device Check when publishing multiple apps.
If the Team ID and Key ID are the same, will the values be shared across all apps with Device Check?
With Device Check, only two keys can be created per developer account, and these two are primarily intended for key renewal in case of a leak, rather than for assigning different keys to each app, correct?
If both 1 and 2 are correct, does that mean that Device Check should not be used to manage "one-time-only rewards per device" when offering them across multiple apps?
Thank you very much for your confirmation.
In these threads, it was clarified that Credential Provider Extensions must set both Backup Eligible (BE) and Backup State (BS) flags to 1 in authenticator data:
https://developer.apple.com/forums/thread/745605
https://developer.apple.com/forums/thread/787629
However, I'm developing a passkey manager that intentionally stores credentials only on the local device. My implementation uses:
kSecAttrAccessibleWhenUnlockedThisDeviceOnly for keychain items
kSecAttrTokenIDSecureEnclave for private keys
No iCloud sync or backup
These credentials are, by definition, single-device credentials. According to the WebAuthn specification, they should be represented with BE=0, BS=0.
Currently, I'm forced to set BE=1, BS=1 to make the extension work, which misrepresents the actual backup status to relying parties. This is problematic because:
Servers using BE/BS flags for security policies will incorrectly classify these as synced passkeys
Users who specifically want device-bound credentials for higher security cannot get accurate flag representation
Request: Please allow Credential Provider Extensions to return credentials with BE=0, BS=0 for legitimate device-bound passkey implementations.
Environment: macOS 26.2 (25C56), Xcode 26.2 (17C52)
Topic:
Privacy & Security
SubTopic:
General
Tags:
Extensions
macOS
Authentication Services
Passkeys in iCloud Keychain
General:
Forums topic: Privacy & Security
Forums tag: Privacy
Developer > Security — This also covers privacy topics.
App privacy details on the App Store
UIKit > Protecting the User’s Privacy documentation
Bundle Resources > Privacy manifest files documentation
TN3181 Debugging an invalid privacy manifest technote
TN3182 Adding privacy tracking keys to your privacy manifest technote
TN3183 Adding required reason API entries to your privacy manifest technote
TN3184 Adding data collection details to your privacy manifest technote
TN3179 Understanding local network privacy technote
Handling ITMS-91061: Missing privacy manifest forums post
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
General:
Forums topic: Privacy & Security
Privacy Resources
Security Resources
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Topic:
Privacy & Security
SubTopic:
General
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
}
}
}
we develop extension "Autofill Credential Provider" function for passkey.
1.first step registe passkey
2.second step authenticate with passkey
step 1 & step 2 has finished and run success with provideCredentialWithoutUserInteraction.
But we want to prepare our interface for use to input password and select passkey what the want. however the func prepareInterfaceToProvideCredential in ASCredentialProviderViewController does call? what i missed? how can i do it?
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
Hello,
We received a rejection on one of our IOS applications because we were doing Microsoft MSAL login through the user's browser. The representative recommended that we use Webview to do in-app logins. However when we tried to handle the custom app uri redirection (looking like myapp://auth/), Webview does not seem to send the user back to the application. Does anyone have a fix for this?
Thanks!
Topic:
Privacy & Security
SubTopic:
General
Tags:
Safari and Web
UI Frameworks
Authentication Services
WebKit
Hello everyone,
I've noticed some unusual behavior while debugging my application on the iOS 26 beta. My standard testing process relies on the App Tracking Transparency (ATT) authorization status being reset whenever I uninstall and reinstall my app. This is crucial for me to test the permission flow.
However, on the current beta, I've observed the following:
1 I installed my app on a device running the iOS 26 beta for the first time. The ATTrackingManager.requestTrackingAuthorization dialog appeared as expected.
2 I completely uninstalled the application.
3 I then reinstalled the app.
Unexpected Result:
The tracking permission dialog did not appear. And more importantly, the device's advertisingIdentifier appears to have remained unchanged. This is highly unusual, as the IDFA is expected to be reset with a fresh app installation.
My question:
Is this an intentional change, and is there a fundamental shift in how the operating system handles the persistence of the IDFA or the authorization status? Or could this be a bug in the iOS 26 beta?
Any information or confirmation on this behavior would be greatly appreciated.
Hello,
I am developing a macOS menu bar window-management utility (similar in functionality to Magnet / Rectangle) that relies on the Accessibility (AXUIElement) API to move and resize windows and on global hotkeys.
I am facing a consistent issue when App Sandbox is enabled.
Summary:
App Sandbox enabled
Hardened Runtime enabled
Apple Events entitlement enabled
NSAccessibilityDescription present in Info.plist
AXIsProcessTrustedWithOptions is called with prompt enabled
Observed behavior:
When App Sandbox is enabled, the Accessibility permission prompt never appears.
The app cannot be manually added in System Settings → Privacy & Security → Accessibility.
AXIsProcessTrusted always returns false.
As a result, window snapping does not work.
When App Sandbox is disabled:
The Accessibility prompt appears correctly.
The app functions as expected.
This behavior occurs both:
In local builds
In TestFlight builds
My questions:
Is this expected behavior for sandboxed macOS apps that rely on Accessibility APIs?
Are window-management utilities expected to ship without App Sandbox enabled?
Is there any supported entitlement or configuration that allows a sandboxed app to request Accessibility permission?
Thank you for any clarification.
We are using SecPKCS12Import C API in our application to import a self seigned public key certificate. We tried to run the application for the first time on Tahoe and it failed with OSStatus -26275 error.
The release notes didn't mention any deprecation or change in the API as per https://developer.apple.com/documentation/macos-release-notes/macos-26-release-notes.
Are we missing anything? There are no other changes done to our application.
In the hopes of saving others time, the updated demo project (i.e. the new Shiny) can be found from the video 'Resources' section under 'Performing fast account creation with passkeys'. The beta documentation can also be found from there.
All of the new functionality is available only on *OS 26 at this time.
We are using Apple's PSSO to federate device login to out own IdP. We have developed our own extension app and deployed it using MDM. Things works fine but there are 2 issues that we are trying to get to the root cause -
On some devices after restarting we see an error message on the logic screen saying "The registration for this device is invalid and must be repaired"
And other error message is "SmartCard configuration is invalid for this account"
For the 1st we have figured out that this happens when the registration doesn't happen fully and the key is not tied to the user so when the disk needs to be decrypted at the FileVault screen the issue is raised.
For the "SmartCard configuration is invalid for this account" issue also one aspect is invalid registration but there has been other instances as well where the devices were registered completely but then also the the above error was raised. We verified the registration being completed by checking if the SmartCard is visible in the System Report containing the key.
Has anyone seen the above issues and any possible resolution around it?
Our business model is to identify Frauds using our advanced AI/ML model. However, in order to do so we need to collect many device information which seems to be ok according to https://developer.apple.com/app-store/user-privacy-and-data-use/
But it's also prohibited to generate a fingerprint, so I need more clarification here.
Does it mean I can only use the data to identify that a user if either fraud or not but I cannot generate a fingerprint to identify the device?
If so, I can see many SKD in the market that generates Fingerprints like https://fingerprint.com/blog/local-device-fingerprint-ios/
and https://shield.com/?
Topic:
Privacy & Security
SubTopic:
General
Tags:
Analytics & Reporting
DeviceCheck
Device Activity
Privacy
I modified the system.login.screensaver rule in the authorization database to use "authenticate" instead of "use-login-window-ui" to display a custom authentication plugin view when the screensaver starts or the screen locks.
However, I noticed an issue when the "Require Password after Display is Turned Off" setting is set to 5 minutes in lock screen settings:
If I close my Mac’s lid and reopen it within 5 minutes, my authentication plugin view is displayed as expected.
However, the screen is not in a locked state—the desktop remains accessible, and the black background that typically appears behind the lock screen is missing.
This behavior differs from the default lock screen behavior, where the screen remains fully locked, and the desktop is hidden.
Has anyone encountered this issue before? Is there a way to ensure the screen properly locks when using authenticate in the screensaver rule?
I need to open p12 file from other iOS applications to import private key to my application. My app is set up to be able to open nay file with following plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeName</key>
<string>Files</string>
<key>LSHandlerRank</key>
<string>Default</string>
<key>LSItemContentTypes</key>
<array>
<string>public.item</string>
<string>public.data</string>
<string>public.content</string>
</array>
</dict>
</array>
</dict>
</plist>
But my don't appear in share dialog from Files or Mail app for example. There are however other third party apps that can accept this file. Some of them use Share extension which I don't have, but some of them don't have it as far as I can understand. At least they don't present any UI and open apps directly.
Also I've tried to specify com.rsa.pkcs-12 UTI directly but it didn't help. Also noticed that *.crt files have similar behaviour.
Am I missing something about this specific file type?
I'm trying to setup device attestation. I believe I have everything setup correctly but the final step of signature validation never succeeds. I've added validation on the client side for debugging and it doesn't validate using CryptoKit.
After the assertion is created, I try to validate it:
assertion = try await DCAppAttestService.shared.generateAssertion(keyId, clientDataHash: clientDataHash)
await validateAssertionLocallyForDebugging(keyId: keyId, assertionObject: assertion, clientDataHash: clientDataHash)
In the validateAssertionLocallyForDebugging method, I extract all the data from the CBOR assertionObject and then setup the parameters to validate the signature, using the key that was created from the original attestation flow, but it fails every time. I'm getting the public key from the server using a temporary debugging API.
let publicKeyData = Data(base64Encoded: publicKeyB64)!
let p256PublicKey = try P256.Signing.PublicKey(derRepresentation: publicKeyData)
let ecdsaSignature = try P256.Signing.ECDSASignature(derRepresentation: signature)
let digestToVerify = SHA256.hash(data: authenticatorData + clientDataHash)
print(" - Recreated Digest to Verify: \(Data(digestToVerify).hexDescription)")
if p256PublicKey.isValidSignature(ecdsaSignature, for: digestToVerify) {
print("[DEBUG] SUCCESS: Local signature validation passed!")
} else {
print("[DEBUG] FAILED: Local signature validation failed.")
}
I have checked my .entitlements file and it is set to development. I have checked the keyId and verified the public key. I have verified the public key X,Y, the RP ID Hash, COSE data, and pretty much anything else I could think of. I've also tried using Gemini and Claude to debug this and that just sends me in circles of trying hashed, unhashed, and double hashed clientData. I'm doing this from Xcode on an M3 macbook air to an iPhone 16 Pro Max. Do you have any ideas on why the signature is not validating with everything else appears to be working?
Thanks
In our mobile we are using UUID as a device identifier . With this ID we using certain function like Primary device and secondary devices .
Primary device has more control to the app other than secondary device .
In our case user is getting new iPhone and the apps related data are moved to new device from old device from clone option.
While moving the keychain data is also moved , which is causing the new device also has same UUID and the customer are using both the devices in some cases ,
So both devices are considered as primary in our app .
Is there any way to identify the device is cloned ,
Needed suggestion
Topic:
Privacy & Security
SubTopic:
General
We recently upgraded OpenSSL from version 1.1.1 to 3.4.0. After this upgrade, we observed that PKCS#12 files generated using OpenSSL 3.4.0 fail to import into the macOS Keychain with the following error:
Failed to import PKCS#12 data: -25264
(MAC verification failed during PKCS12 import (wrong password?))
This issue is reproducible on macOS 14.8.2. The same PKCS#12 files import successfully on other macOS versions, including 15.x and 26.x.
Additionally, PKCS#12 files that fail to import on macOS 14.8 work correctly when copied and imported on other macOS versions without any errors.
PKCS#12 Creation
The PKCS#12 data is created using the following OpenSSL API:
const char* platformPKCS12SecureKey =
_platformSecureKey.has_value() ? _platformSecureKey.value().c_str() : NULL;
PKCS12* p12 = PKCS12_create(
platformPKCS12SecureKey,
NULL,
keys,
_cert,
NULL,
0, 0, 0, 0, 0
);
if (!p12)
{
throw std::runtime_error("Failed to create PKCS#12 container");
}
PKCS#12 Import
The generated PKCS#12 data is imported into the macOS Keychain using the following code:
NSString *certPassKey = [NSString stringWithUTF8String:getCertPassKey()];
NSDictionary *options = @{
(__bridge id)kSecImportExportPassphrase: certPassKey,
(__bridge id)kSecAttrAccessible:
(__bridge id)kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly,
(__bridge id)kSecAttrIsExtractable: @YES,
(__bridge id)kSecAttrIsPermanent: @YES,
(__bridge id)kSecAttrAccessGroup: APP_GROUP
};
CFArrayRef items = NULL;
OSStatus status = SecPKCS12Import(
(__bridge CFDataRef)pkcs12Data,
(__bridge CFDictionaryRef)options,
&items
);
Topic:
Privacy & Security
SubTopic:
General
Tags:
macOS
Signing Certificates
iCloud Keychain Verification Codes
Passkeys in iCloud Keychain