User Profile

Hello! Can someone please confirm whether or not an app will trigger background fetch after it has been force-quit by the user? Currently my app works performs background fetches correctly when it has been backgrounded, but after force-quitting the app it stops fetching. Specifically I am referring to scheduled background fetches, not fetches initiated by notifications - although I am interested to know if that would be an alternative. I've tried searching online and there's a lot of confusing and contradictory information about this - including old Apple documentation that explicitly says it will not launch, however that documentation has since been removed. The new documentation does not explicitly mention the force-quit scenario. Can anyone please confirm? Thanks!

Hello, We are attempting to use the SecTrust APIs to extract the public key from a certificate and evaluate a certificate chain. However, we are running into an issue where this is failing due to a "weak key size". For example, once we have created a SecTrust object for our certificate and attempt to extract the public key using SecTrustCopyKey we get this error in the console: [seckey] SecKeyCreate init(ECPublicKey) failed: -26275 Additionally when we attempt to run SecTrustEvaluateWithError we get: Optional<CFDictionaryRef>  ▿ some : 3 elements   ▿ 0 : 2 elements    - key : TrustResultDetails    ▿ value : 1 element     ▿ 0 : 2 elements      ▿ 0 : 2 elements       - key : WeakKeySize       - value : 0      ▿ 1 : 2 elements       - key : MissingIntermediate       - value : 0   ▿ 1 : 2 elements    - key : TrustResultValue    - value : 6   ▿ 2 : 2 elements    - key : TrustEvaluationDate    - value : 2021-12-06 23:10:09 +0000 For reference the certificate we are using has the following attributes: Signature algorithm: sha384ECDSA Public key: ECC (384 bits) We have done some research and found this notice regarding key sizes here: https://support.apple.com/en-au/HT210176 However as far we can tell that should only apply to RSA keys and not ECC. We're also not using these certificates for TLS connections. We have done some further testing using OpenSSL and didn't run into any issues using these certificates, so we suspect this issue is specific to Apple's APIs. Any advice would be appreciated. Thanks!

Hi, I am developing an app that requires manually checking if a certificate has been revoked via a CRL (certificate revocation list). However, I'm running into an issue where my revocation check fails due to my root certificate "not meeting pinning requirements". After some searching I found this article: https://support.apple.com/en-us/HT210176 That article indicates that iOS requires certificates to have certain key sizes, etc. which my root certificate seemingly does not. Is there any way to get around that when you are performing a trust evaluation manually? (i.e. via SecTrustEvaluateWithError). Note that the certificates I am working with are NOT used for TLS connections, which is why I was hoping there was a workaround for this. For reference, I am using code similar to the following: // Create policies let basicPolicy = SecPolicyCreateBasicX509() let crlPolicy = SecPolicyCreateRevocation(kSecRevocationOCSPMethod | kSecRevocationCRLMethod | kSecRevocationRequirePositiveResponse) // Create trust var trust: SecTrust? SecTrustCreateWithCertificates(cert, [basicPolicy, crlPolicy] as CFArray, &trust) SecTrustSetAnchorCertificates(trust, [rootCert] as CFArray) SecTrustSetNetworkFetchAllowed(trust, true) // Evaluate trust var error: CFError? guard SecTrustEvaluateWithError(trust, &error) else {   // Handle error } In the above code cert is the certificate I'm checking and rootCert is the root certificate that contains the CRL distribution points. The error I am getting is: Error Domain=NSOSStatusErrorDomain Code=-67635 ""<redacted>","<redacted>" certificates do not meet pinning requirements" Thanks!

Hello,We are developing an iOS app that stores password protected data in the keychain. Recently we integrated the SDK for an MDM (Citrix) into the app. After integrating the SDK our calls to `SecItemDelete` have started failing - they are now returning `errSecInteractionNotAllowed` where previously they succeeded.We have followed up with the SDK developers, but I am stumped as to how this can be happening.Here is how we delete keychain entries (where `service` and `account` are strings we generate in our app):NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword, (__bridge id)kSecAttrService: service, (__bridge id)kSecAttrAccount: account }; OSStatus status = SecItemDelete((__bridge CFDictionaryRef)query);After investigation we have found that if we pass in `kSecUseAuthenticationContext` (along with the password protecting the keychain entry) then the call succeeds:LAContext *context = [[LAContext alloc] init]; NSData *password = [@"foobar" dataUsingEncoding:NSUTF8StringEncoding]; [context setCredential:password type:LACredentialTypeApplicationPassword]; NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword, (__bridge id)kSecAttrService: service, (__bridge id)kSecAttrAccount: account, (__bridge id)kSecUseAuthenticationContext: context }; OSStatus status = SecItemDelete((__bridge CFDictionaryRef)query);My questions are:I thought `kSecUseAuthenticationContext` was only necessary when retrieving data from the keychain? In this case we just want to clear the keychain, not retrieve any data from it. Should this work the way we expect, or is needing to provide the password to delete password protected items from the keychain expected?Do you have any idea how the SDK could possibly be causing this to happen?My only lead at the moment is that the SDK requires the use of Keychain Access Groups. However, we have already successfully integrated a separate SDK (Microsoft Auth) that also used access groups, and I have confirmed that our private access group (of the form $(AppIdentifierPrefix)&lt;BUNDLE ID HERE&gt;) is at the top of our entitlements access groups list. I have tested explicitly specifying our private access group when creating/deleting keychain items, but it didn't seem to help.Any help would be greatly appreciated!Thanks,Joel