I currently have two valid Apple Distribution certificates (old and new, say) in my login keychain (which Xcode recognises in Settings > Accounts) and a project with a manual code signing setup such that a provisioning profile which references the old certificate is specified for the PROVISIONING_PROFILE_SPECIFIER build setting. While building, though, Xcode complains about the profile not containing some signing certificate (which I assume refers to the new one and which would be expected since I have yet to update it) and fails the build. This effectively means that I cannot have two valid certificates in the keychain and use two profiles where one references the old and the other the new certificate. Am I missing something here?

As a follow-up to a Networking lab conversation I had on Tuesday I have the following question: Is there a way to use nscurl to connect to a server that requires client authentication by providing a client certificate? None of the documented options seem to allow that, but maybe there is an undocumented one...

I am slightly confused as to how I am supposed to maintain persistent access to a SecureEnclave.P256.Signing.PrivateKey. Do I have to persist the key myself (using its dataRepresentation property and code along the lines of Storing CryptoKit Keys in the Keychain or is there another persistent reference to the key inside the Secure Enclave that I can use later?

Is it possible to send remote notifications via APNs to an iOS app from two provider servers one of which uses certificate-based authentication while the other uses token-based authentication? The documentation states: To send notifications, your provider server must establish either token-based or certificate-based trust with APNs However, this only applies to one server and not two. StackOverflow: https://stackoverflow.com/a/51726097

Is there an API to create a .logarchive file from the contents of e.g. a OSLogStore?

We are seeing crashes lately that seem to be caused by PAC, but we are not yet building for the arm64e architecture as advertised here. Is it likely that adopting that architecture will alleviate these crashes?

If a host is pinned by specifying its SPKI fingerprint under NSAppTransportSecurity > NSPinnedDomains > <hostname> > NSPinnedLeafIdentities and pinning fails the following errors are raised: Error Domain=NSURLErrorDomain, Code=-1200 (i.e. NSURLErrorSecureConnectionFailed) Error Domain=kCFErrorDomainCFNetwork, Code=-1200 (i.e. kCFURLErrorSecureConnectionFailed) _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802 (i.e. errSSLFatalAlert) The topmost error's UserInfo dictionary contains a NSLocalizedRecoverySuggestion of "Would you like to connect to the server anyway?". How would I go about doing so given that urlSession(_:task:didReceive:completionHandler:)has already been called at this point?

The (archived) Local and Remote Notifications Programming Guide contains the following: To support a background update notification, make sure that the payload’s aps dictionary includes the content-available key with a value of 1. If there are user-visible updates that go along with the background update, you can set the alert, sound, or badge keys in the aps dictionary, as appropriate. The current documentation however reads: To send a background notification, create a remote notification with an aps dictionary that includes only the content-available key, as shown in the sample code below. You may include custom keys in the payload, but the aps dictionary must not contain any keys that would trigger user interactions. What caused this change and why is no longer supported to send additional keys (e.g. an alert dictionary) in the aps dictionary of a background notification?

If on iOS an app protects a keychain item with an access control list that specifies .biometryCurrentSet in its SecAccessControlCreateFlags the app loses access to the item if the set of currently enrolled fingers (for Touch ID) or the currently enrolled user (for Face ID) changes - which corresponds to a change of the evaluatedPolicyDomainState. We have users reporting loss of such items even though - as they assure us - they have not touched (no pun intended) anything under "[Touch|Face] ID & Code" in Preferences.app. Is there another reason why an app may lose access to such items?

I recently re-read Performing manual server trust authentication and noticed that it does not mention having to call SecTrustEvaluate (or its replacements) in client code (anymore). Is that implicitly taken care of by ATS?

I noticed that the numbers given for the individual states do not add up; i.e. if I add everything other than "Received by APNs" I get what amounts to ~95% of that. Is that expected? And if so what happened to the remaining 5%?

I am trying to implement BLE communication between installations of an iOS app and I am following Transferring Data Between Bluetooth Low Energy Devices since the data I need to transfer exceeds the 512 byte limit for attribute values. I already have this working based on an older version of the app, however after I integrated with the mainline of development I am getting CBATTErrorRequestNotSupported which seems to be caused by OSStatus 65535 (which is kBluetoothSDPErrorCodeReservedEnd, but that is documented to not even be present on iOS). So it seems that a change on our end is causing these errors, but I am completely stumped as to what change that might be. Is anyone able to enlighten me?

The sample code uses a static variable of the PeripheralViewController class to account for congestion in the BLE stack - which is frowned upon by the Swift 6 compiler. Why does this variable need to be static in the first place?

On iOS Bundle.main.preferredLocalizations returns the list of languages the application bundle supports in user-preferred order with the first element being the language the application is running in. Additionally Locale.preferredLanguages returns the list of languages in the order they are presented in Preferences.app > General > Language & Region > Preferred Languages with the first element being the user's "primary language" (i.e. the language the system is running in). However this only seems to be true unless the user has chosen a per-app language which is different from the primary language in which case Locale.preferredLanguages.first is equal to Bundle.main.preferredLocalizations.first - regardless of the latter's position in the Preferred Languages list. Furthermore this seems to change depending on the value of the "AppleLanguages" key in the User Defaults' global domain (see c.f. https://stackoverflow.com/a/42648166). Is this behaviour documented anywhere? Addendum: I know that according to https://forums.developer.apple.com/forums/thread/718512?answerId=733680022#733680022 AppleLanguages is an implementation detail, not something that’s considered API. Locale.preferredLanguages is API, though.

Is there a way to view the opt-in rate via the API? I have been unsuccessful in finding one.