I also filed a report on this, referring to the one above.

I second the OP's call for this, which is even more important with Catalyst. At the moment I don't know how to selectively implement serial communications on the Mac while using Bluetooth under iOS (which is what the app does currently). Filed feedback FB8385366. I can hear the wheels of industry turning already.

This isn't an iOS-14-specific problem. I uploaded a new build of an app that's been relatively unchanged for months, and the build is never shown in App Store Connect. I can upload it (with Xcode reporting success) over and over with the same build number and no complaint about duplicates. Apple is aware of the problem. Support told me this is "an emerging trend," and sent me a questionnaire soliciting more info (much of it inapplicable). However, you should still contact them and report it, so its seriousness is clear. The thing is... it isn't a new problem. You can find copious reports of this going back years. Even worse is that the only workaround for testing, ad-hoc distribution, is essentially undocumented. It's also pretty much unusable, because there's no apparent way for users to give you their phones' UDIDs... except physically plugging them into a Mac!

There's already a thread here: https://developer.apple.com/forums/thread/660664 This is a frequent daily FAQ Mmmm, it's an "emerging trend" that Apple is investigating, per their support reps. They sent me an investigative questionnaire. So... apparently not.

I had this too. It took a full minute for the app to launch on the iPhone from the debugger. The phone screen was blank the whole time, and there was no console output. I have no idea what it was doing. This behavior mysteriously stopped at some point, and the app now deploys in a reasonable amount of time.

I had the same problem. It took a full minute to launch my app on an iPhone from the debugger. The screen was blank the whole time, and there was no debugging-console output. I have no idea what it was doing. I also have no idea why this behavior suddenly stopped; now the app launches in a reasonable amount of time.

Deleting the ~/Library/Developer/Xcode/iOS DeviceSupport directory for iOS 14 did not work for me.

What behavior are you seeing in the UI? I may be seeing the same thing. Keychain Access presents a dialog asking for your password, but there's no cursor in the password field and it doesn't accept any input. You have to kill Xcode to get out of the state. I don't see that message in the console though.

Apple pulled the same thing a few iOS updates ago, and again didn't warn anybody. Talk about disregard for developers, who may have a critical deadline for a release.

Talk about obscure. I especially appreciate having my time wasted by the Xcode "validation" process's reporting success and uploading the whole product, only to be told on submission that an obvious item is missing.

If you look carefully, you'll notice that the additional row of Mac icon images doesn't end with a 512 x 512 one. That last one has fine print that specifies a 1024 x 1024 "2x" one. Unbelievable.

Yep. Clearly this is a major issue. I did find an apparent workaround: Open up the xcodeproj as a directory and delete xcworkspace. That appears to fix it. Bug filed with Apple. Report this, folks: feedbackassistant.apple.com

Feedback not found.

I encountered this today, and found that it was caused by loading a view controller from a storyboard by name... as the base view-controller class and not the derived class that it is specified as in the storyboard. So I understand why the overridden methods wouldn't get called. What I don't understand is why, when instantiated with the exact same method, some other derived controllers' overrides DO get called.

Thanks a lot for the reply. I did set up a CA. Maybe that's different from "self-signed," but I used mkcert to create a CA and install it. I then added it to the Keychain and set it to "always trust" for all applications. I also used mkcert to generate server certificates for localhost and the name of my computer on the local network. I did get the CA onto a simulator by uploading it to a Web server and then hitting it by URL in the simulator's Safari. I have it installed on the simulator, and I confirmed that its serial number matches that of the CA on my Mac. But the certificate is still flagged as "invalid" when my application tries to hit my server at localhost... Aha, looking at your comment again and assuming you noticed I said iOS 17... I went back and looked in the settings area you mentioned. Sure enough, there is now the Trust switch there, and it was off. It's some bad UI to scatter these certificate functions between "VPN and Device Management" and "About." But your comment clued me in, so now it works! The CA remains shown on "VPN and Device Management," by the way; it's not the blank screen that bounces out anymore. In case that's useful to you. Thanks again.