I have been bitten by this repeatedly so I am finally going to ask: Is there a way to infer an error from its localizedDescription only? It sometimes happens that a user reaches out for support with just a localized error message, but no error code or error domain and it is really hard to correctly guess what the non-localized description may have been in order to search for it. For example I know from experience that "Der eingegebene Benutzername oder das Passwort ist ungültig." is the German localization of "The user name or passphrase you entered is not correct." which in turn is errSecAuthFailed (aka. -25293). It would be really helpful to be able to just look this up somewhere...

The CA/Browser Forum has voted (cf. https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/9768xgUUfhQ?pli=1) to eventually reduce the maximum validity period for a SSL certificate from 398 days to 47 days by March 2029. This makes statically pinning a leaf certificate rather challenging. What are the consequences for App Transport Security Identity Pinning as it exists today?

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

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?

We have found that on iOS 26 beta some of our app icons built from an Xcode 16 asset catalog containing a single 1024x1024 .png file have a Liquid Glass effect applied to them while others have not. The documentation states that If you choose not to use Icon Composer, you can still use an AppIcon asset catalog in your project containing individual app icon images and let the system apply the Liquid Glass material. and If you prefer, you can take advantage of the system’s automatically generated treatment that is applied to all app icons. Is there any insight into how the system treats app icons that have not yet been updated with Icon Composer?

The header documentation for the (deprecated) LAContext.evaluatedPolicyDomainState property contains the following: @warning Please note that the value returned by this property can change exceptionally between major OS versions even if the state of biometry has not changed. I noticed that the documentation for the new LAContext.domainState property does not contain a similar warning. I also found this related thread from 2016/17. Is the domainState property not susceptible to changes between major OS versions? Or is this generally not an issue anymore?

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?

OAEP (i.e. Optimal Asymmetric Encryption Padding) as defined in RFC 2437 is parameterized by the choice of hash function and mask generation function. The hash function is usually either SHA-1 or SHA-2 while the only mask generation function defined is MGF1 which itself is based on a hash function. In the Security.framework this padding scheme is available as OAEP (deprecated as of iOS 15) and as properties of the SecKeyAlgorithm structure, e.g. rsaEncryptionOAEPSHA1. The documentation for both only reads No overview available but from the comments in SecKey.h can be gleaned that at least for rsaEncryptionOAEPSHA1 data is padded using OAEP padding scheme internally using SHA1. So it seems that while using SecKeyAlgorithm the choice of hash function corresponds to selecting a property of the structure; the question that remains is whether this hash function is used for both the encoding scheme and the mask generation function. I suppose that this is in fact the case, but I am unable to find anything corroborating this.

The documentation states: iOS, iPadOS, macOS, and tvOS apps can share a single target. watchOS apps remain in a separate target. Why is that?

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 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%?

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.