Post

Replies

Boosts

Views

Activity

TrustInsights: authorizationStatus returns .unavailable, but requestEvaluation returns .denied — feature missing from Settings (China mainland)
Hi, I'm integrating the TrustInsights framework (Impersonation Risk Detection, IsLikelyBeingCoachedInsight) announced at WWDC26. I'd like to confirm whether the behavior below is expected regional gating or a misconfiguration on my side. Environment Real device: iPhone 15 , iOS 27.2 Xcode 27.2 , SDK iOS 27.2 App has the Trust Insights capability added in Xcode; the embedded provisioning profile includes com.apple.developer.trustinsights.base (verified via security cms -D) Deployment target and device OS both satisfy the framework requirements Code (standard usage) **Observed behavior** 1. `authorizationStatus(for:)` always returns `.unavailable`. 2. `requestAuthorization(for:)` also returns `.unavailable` — no system permission alert is shown. 3. `requestEvaluation(context:)` throws with the framework log: 4. The Settings entry described in the user-facing docs (Settings → Privacy & Security → Impersonation Risk Detection → "Share with App Developers") **does not exist on this device**, including after search and after a failed evaluation attempt. 5. The documented testing launch argument does reach the process — `UserDefaults.standard.string(forKey: "TrustInsights.IsLikelyBeingCoachedValue")` returns `medium` when launched with `-TrustInsights.IsLikelyBeingCoachedValue medium` — but evaluation still fails with the same `denied`. **Questions** 1. Is TrustInsights / Impersonation Risk Detection currently unavailable in China mainland (or gated by region/Apple Account storefront)? Is that why `authorizationStatus` returns `.unavailable`? 2. Why do `authorizationStatus` and `requestAuthorization` return `.unavailable` while `requestEvaluation` gets far enough to return `.denied`? Which one reflects the actual gate? 3. If the per-app permission row in Settings is only created after the first `requestAuthorization` flow, how is that supposed to happen when the API returns `.unavailable` without presenting any UI? 4. Is there a supported way to exercise the evaluation pipeline (including the launch-argument overrides) on a device where the Settings entry is absent, so UI/UX work can proceed before regional rollout? 5. Is developer-side enablement required (entitlement request / Feedback) for regions where the feature is not yet live? Thanks!
0
0
162
15h
Question:evaluatedPolicyDomainState
Hello, Apple developer, I found in the documentation that the evaluatedPolicyDomainState API has been deprecated in iOS 18. In my project, many users rely on this value for comparison. I would like to ask, what does it mean that this API is deprecated? Will the value returned by this API be empty in the future? How should I adapt for existing users?" Let me know if you'd like any adjustments! Thank you. Good luck. [[context evaluatedPolicyDomainState] bytes]
0
0
804
Dec ’24
Issues related to slow keychain access.
Hello Apple Developer, I have some questions regarding slow keychain access. We recently launched a product, and users with certain specific device models have reported slow performance. I'm not sure what's causing this issue and would appreciate your help in analyzing it.When using keychain groups, I didn’t specify a group, and on some devices, the queries are particularly slow. I'm unsure of the reason for this.I’m using kSecAttrTokenIDSecureEnclave, and each time I execute SecItemCopyMatching or SecItemDelete, the operation is particularly slow, taking around 2 seconds.It’s strange that when setting the default keychain group (team ID + bundle ID), the access is not slow. However, since the project has enabled the keychain group, if I set a keychain group, I cannot access the data that was stored before setting the keychain group. Here is a snippet of my code: NSMutableDictionary *parameters = [[NSMutableDictionary alloc] initWithObjectsAndKeys:(__bridge id)kSecAttrTokenIDSecureEnclave,(__bridge id)kSecAttrTokenID, (__bridge id)kSecAttrKeyTypeEC,(__bridge id)kSecAttrKeyType, @256,(__bridge id)kSecAttrKeySizeInBits, PrivateKeyAttrs,(__bridge id)kSecPrivateKeyAttrs,nil]; privateKey = SecKeyCreateRandomKey((__bridge CFDictionaryRef)parameters, &error); Here is a search of my code: SecKeyRef privateKey = NULL; //CFTypeRef *private = &privateKey; NSDictionary *query = nil; query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassKey, (__bridge id)kSecAttrApplicationTag: serviceID, (__bridge id)kSecReturnRef: @YES }; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&privateKey); if (privateKey) { CFRelease(privateKey); }
2
0
692
Sep ’24
TrustInsights: authorizationStatus returns .unavailable, but requestEvaluation returns .denied — feature missing from Settings (China mainland)
Hi, I'm integrating the TrustInsights framework (Impersonation Risk Detection, IsLikelyBeingCoachedInsight) announced at WWDC26. I'd like to confirm whether the behavior below is expected regional gating or a misconfiguration on my side. Environment Real device: iPhone 15 , iOS 27.2 Xcode 27.2 , SDK iOS 27.2 App has the Trust Insights capability added in Xcode; the embedded provisioning profile includes com.apple.developer.trustinsights.base (verified via security cms -D) Deployment target and device OS both satisfy the framework requirements Code (standard usage) **Observed behavior** 1. `authorizationStatus(for:)` always returns `.unavailable`. 2. `requestAuthorization(for:)` also returns `.unavailable` — no system permission alert is shown. 3. `requestEvaluation(context:)` throws with the framework log: 4. The Settings entry described in the user-facing docs (Settings → Privacy & Security → Impersonation Risk Detection → "Share with App Developers") **does not exist on this device**, including after search and after a failed evaluation attempt. 5. The documented testing launch argument does reach the process — `UserDefaults.standard.string(forKey: "TrustInsights.IsLikelyBeingCoachedValue")` returns `medium` when launched with `-TrustInsights.IsLikelyBeingCoachedValue medium` — but evaluation still fails with the same `denied`. **Questions** 1. Is TrustInsights / Impersonation Risk Detection currently unavailable in China mainland (or gated by region/Apple Account storefront)? Is that why `authorizationStatus` returns `.unavailable`? 2. Why do `authorizationStatus` and `requestAuthorization` return `.unavailable` while `requestEvaluation` gets far enough to return `.denied`? Which one reflects the actual gate? 3. If the per-app permission row in Settings is only created after the first `requestAuthorization` flow, how is that supposed to happen when the API returns `.unavailable` without presenting any UI? 4. Is there a supported way to exercise the evaluation pipeline (including the launch-argument overrides) on a device where the Settings entry is absent, so UI/UX work can proceed before regional rollout? 5. Is developer-side enablement required (entitlement request / Feedback) for regions where the feature is not yet live? Thanks!
Replies
0
Boosts
0
Views
162
Activity
15h
Question:evaluatedPolicyDomainState
Hello, Apple developer, I found in the documentation that the evaluatedPolicyDomainState API has been deprecated in iOS 18. In my project, many users rely on this value for comparison. I would like to ask, what does it mean that this API is deprecated? Will the value returned by this API be empty in the future? How should I adapt for existing users?" Let me know if you'd like any adjustments! Thank you. Good luck. [[context evaluatedPolicyDomainState] bytes]
Replies
0
Boosts
0
Views
804
Activity
Dec ’24
Issues related to slow keychain access.
Hello Apple Developer, I have some questions regarding slow keychain access. We recently launched a product, and users with certain specific device models have reported slow performance. I'm not sure what's causing this issue and would appreciate your help in analyzing it.When using keychain groups, I didn’t specify a group, and on some devices, the queries are particularly slow. I'm unsure of the reason for this.I’m using kSecAttrTokenIDSecureEnclave, and each time I execute SecItemCopyMatching or SecItemDelete, the operation is particularly slow, taking around 2 seconds.It’s strange that when setting the default keychain group (team ID + bundle ID), the access is not slow. However, since the project has enabled the keychain group, if I set a keychain group, I cannot access the data that was stored before setting the keychain group. Here is a snippet of my code: NSMutableDictionary *parameters = [[NSMutableDictionary alloc] initWithObjectsAndKeys:(__bridge id)kSecAttrTokenIDSecureEnclave,(__bridge id)kSecAttrTokenID, (__bridge id)kSecAttrKeyTypeEC,(__bridge id)kSecAttrKeyType, @256,(__bridge id)kSecAttrKeySizeInBits, PrivateKeyAttrs,(__bridge id)kSecPrivateKeyAttrs,nil]; privateKey = SecKeyCreateRandomKey((__bridge CFDictionaryRef)parameters, &error); Here is a search of my code: SecKeyRef privateKey = NULL; //CFTypeRef *private = &privateKey; NSDictionary *query = nil; query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassKey, (__bridge id)kSecAttrApplicationTag: serviceID, (__bridge id)kSecReturnRef: @YES }; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&privateKey); if (privateKey) { CFRelease(privateKey); }
Replies
2
Boosts
0
Views
692
Activity
Sep ’24