SecKeyRef tmpprivatekeyref = [KeyInterface lookupPrivateKeyRef];      OSStatus signStatus = SecKeyRawSign(tmpprivatekeyref,                       kSecPaddingNone,                       [digest bytes],                       [digest length],                       [signature mutableBytes],                       &signatureLength); if tmpprivatekeyref is nil then on older versions of the OS signStatus used to return success or failure, on OS 15 it is crashing with the error mentioned in the post's heading. This is the bug. Why tmpprivatekeyref is nil you ask? because we store device id in a keychain to uniquely identify a device, so when an app gets transferred from one iphone to another keychain gets replicated even if we set thisiphoneonly flag (not through icloud), but the privatekey reference for SecKeyRef doesn'te get transferred to the new iphone. I have mentioned this before as well, but apple keeps insisting on providing a sample code, how can i provide a sample code for an issue that occurs when an app is transferred from one device to another?

There is this app, which is a financial app, we use UUID to uniquely identify the app, since there no way of extracting IMEI etc on apple to identify a device. We store this UUID in a keychain, because in one instance of apple OS upgrade the UUID changed after the OS upgrade, this I think is well documented. Hence we cannot rely on this if it happens again, because honestly I can’t explain these things to our clients (who don’t understand the technical aspect of things) .  So our servers uniquely identify each device/user based on this UUID, and redirects him/her to either the login page or to the registration page. We also have enabled biometric , we ask the Secure enclave to generate a public and a private key and we store the public key in our servers. So once server stores this public key it assumes the user has enabled biometric login. On launch of the app our server generate a token and sends it to the device. User then tries to login using face/Touch ID, we request the private key reference from the secure enclave (upon which biometric gets launched) get the private key reference , sign the token and send it to server , which will use the public key to check if the token is valid and that is our biometric authentication process.  Now the same user now buys a new iPhone, and then transfer his data from the old iPhone using iphone to iPhone transfer, guess what happens, the UUID in the Keychain gets transferred to the new iPhone even though I have specifically stated not to. i.e via kSecAttrAccessibleAlwaysThisDeviceOnly. Now the Secure enclave doesn’t gets transferred to the new iPhone. Now the user tries to access the app on his new phone, it directly goes to the login page instead of registration page because our server gets the original UUID that was used on the old iPhone. Then server assumes the user has already enrolled in biometric sends the token and then the device tries to access the private key reference ,it returns nil and our app crashes only on iOS 15. Used to return failure now it doesn’t.  Now there are other users who transfer (using the above same app which is in store by the way) their data via iCloud for them the UUID (Stored in keychain) doesn’t get transferred because of kSecAttrAccessibleAlwaysThisDeviceOnly, so all is well, it behaves as expected. Now is my approach wrong? Or is it a bug at apple’s end?

Not sure what you mean by API contract? By definition a contract shouldn't change willy-nilly, why was it working till now!! prior to ios 15 , i can see examples created by other programmers who were passing nil, its a bug , let's just leave it at there. And as far as either item is missing, i need to rollback, how will i come to know if a secure enclave is erased without prompting the user to do a biometric authentication, this is not an elegant solution, i don't think anyone should design apps in such fashion., this is like going into a rabbit hole, end user will get confused, prompting user to use face id, and then informing him his app will get deregistered! . why have you proposed this specific key kSecAttrApplicationTag i am not sure, i am storing the UUID as kSecClassGenericPassword. Also if possible make it clear as to why that on icloud restore the keychain gets erased but on iphone to iphone transfer it doesn't, i have witnessed this in multiple apps , designed by other companies. So clearly i am not the only one who is designing apps this way. Am i doing something wrong? is it a mistake to store it as kSecClassGenericPassword?

hi there, i am also facing this issue, did you happen to find any solution? on upgrade of ios 15.x users are unable to access the contents read from the sql database. reinstalling resolves the issue

Its UPI related issue (for indian apps only)

Anyone has any idea on how to achieve this? Afnetworking is now listed but this is is now archived, how would one go about adding manifest file for this?

hi, did you by any chance get any information on this?

Asset validation failed Invalid Version. The build with the version “1.9” can’t be imported because a later version has been closed for new build submissions. Choose a different version number. (ID: 0cb9ef1a-e4af-48ed-9279-f31686169f20) Asset validation failed Invalid Pre-Release Train. The train version '1.3' is closed for new build submissions (ID: 67f71f7f-e21c-4495-8a3a-38f7ccf0222f) Asset validation failed This bundle is invalid. The value for key CFBundleShortVersionString [1.3.0] in the Info.plist file must contain a higher version than that of the previously approved version [1.20]. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring (ID: 8cb5cafe-f932-4dc5-a9a7-eca59fbe4137) Getting this error now!!!!! the app itself was invisibile, dont know what is 1.9? it is not mentioned anywhere, we have given it as 1.3

got resolved, my mistake, previous version was 1.20 so next version must be 1.21

Same above has been raised via Feedback assistance, Recent Similar Reports used to be more than 10, now its None, nobody responds on Feedback assistance, nor are they informing if we need to raise a TSI, what is going on?

We are using uikit and on pro max devices we are facing this issue, pushing a viewcontroller from a rootviewcontroller, pretty much freezes in between transitioning of viewcontrollers. 18.4.1, such type of bugs which are not acknowledged are become exceedingly difficulty to convince customers, as apple insulates itself and we are stuck bearing the brunt.

can setUPIVerificationCodeSendCompletion be made available for non upi apps?

Its a private API which is given behind an entitlement, we dont have a lot of documentation or discussion about this API in the public forums, nor does the documentation state in which case it may or may not fail, the only thing we have are back end logs where we see the API being triggered on success of this setUPIVerificationCodeSendCompletion function, which was not supposed to be triggered for that person. We dont know how to simulate it. Which is why i am asking here. Do you want me to raise a bug report? I cant simulate it, but the logs say otherwise. And answering if in the chain has raised it with apple, its above my pay grade, i am not aware of this, i assuming it has been. If you're not in a position to answer this, i understand.

As per our logs the user has not successfully sent the SMS from his device, which is an iphone, the payload has come from another device, which is not an iphone, just like how this MFMessageComposeViewController was working before setUPIVerificationCodeSendCompletion, irrespective of wether an sms was sent or not, callback was given as sent on dismissal of MFMessageComposeViewController(on send button tap), so i can copy the SMS payload and ask someone else to send it to the number, thats the behaviour we are seeing in our back end logs. Fine its a "public" api. Can we discuss about how i can raise a bug simulating this? raising a bug would require me to provide video evidence of this? If i could i would.

no we are not able to reproduce it, which is why i am seeking your expertise on this.