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?
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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.
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect API
Tags:
App Store Connect API
I am trying to retrieve the numbers displayed in "App Analytics" under "Metrics" > "Active Devices" using the API.
Since there does not seem to be a dedicated report for this metric I am using the daily "App Sessions Standard" report and by looking at the "Sessions" field I am able to recreate the numbers displayed for the "Sessions" metric.
However if I try to infer the active devices by looking at the "Unique Devices" field my numbers for individual days are in the same ballpark (deviations may be attributable to privacy reasons?), but the total number of devices is way off. Is there a better way to recreate this metric?
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect API
I am trying to use the NFCTagReaderSession to SELECT the master file of a ISO 7816 smartcard by sending a corresponding NFCISO7816APDU after connecting to the card, but I am running into errors:
Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement}
Error Domain=NFCError Code=103 "Session invalidated" UserInfo={NSLocalizedDescription=Session invalidated}
I know that in order to communicate with a NFCISO7816Tag I need to declare the supported AIDs in the Info.plist, but what am I supposed to declare here?
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?