Never mind. Turns out you can't actually do this directly with SecKeyCreateWithData, you have to switch to Swift CryptoKit. See: https://developer.apple.com/forums/thread/680572 func createSecKeyWithPEMSecp256r1Private(_ pem: String) throws -> SecKey { let privateKeyCK = try P256.Signing.PrivateKey(pemRepresentation: pem) let x963Data = privateKeyCK.x963Representation var errorQ: Unmanaged<CFError>? = nil guard let privateKeySF = SecKeyCreateWithData(x963Data as NSData, [ kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeyClass: kSecAttrKeyClassPrivate, ] as NSDictionary, &errorQ) else { throw errorQ!.takeRetainedValue() } return privateKeySF }

Never mind. My mistake. I left some old testing schemes around (11 months ago), and didnt' quite remember the correct way to run these tests. All is good.

Same problem for me. I could not figure out how to find an older version of Xcode, so created class files and changed them by hand.

I experienced this issue a couple of days ago. The message about "CoreAudioTypes" is completely misleading. In my case, the cause was that while removing some old code I had accidentally deleted a class that was still required. However, the only message that popped up when building was about "CoreAudioTypes" - when I restored the missing class, the message went away and the app built successfully. You can try hunting around in the build logs for more detail when you see this. Bottom line: When you see "CoreAudioTypes" it's almost certainly a red herring - you've messed up something else.

I had all the settings correct. Ultimately fixed the issue by creating a new project and moving all the existing code over there. It's possible that it was caused by having one target for iOS, and a second for Mac, and trying to share the same umbrella header file between the two. But it's fixed now, so I'm not going to bother with verifying the problem ;-)

I've been going through this, trying to move an app from a corporate account to a personal account. Could not transfer because it used CloudKit. First try was to just build the app on the new account - Apple rejected it as spam, probably because they figured out it was similar to the app on the corp account. DTS said basically to delete the old app, then quickly grab the name for the new one. For now, I've built a "premium" version of the app without CloudKit on the corp account, will try to migrate users there, then transfer that new app. I'll be back to let you know how it goes.

If you have a scheme per country say, for generating appropriate screenshots and testing, this can be somewhat annoying. I believe running UITests always restarts the device first, so this behavior only appears if you are running the simulator manually. Probably explains why Apple has not found and fixed this one.

With Xcode 12.3 and iOS 14.3, the TZ environment variable seems to work only the first time after you erase settings & content on the Simulator - after that, if you run a different scheme with a different TZ value, it "sticks" to the first value you used. So it works, but if you have a scheme per country, let's say, then you will have to restart the simulator to correctly simulate a new country. Would sure be nice if it worked properly.

Xcode 12 GM does this too. Has anyone found a reasonable fix???