Bug also exists in Xcode 14.1 Beta

Interesting. Apple's system here is auto-generating a hyperlink for the Feedback identifier. Yet it is excluding the last digit in the link. Guess I'll file another bug. Putting the identifier in quotes was an experiement to see if the link would get fixed.

Also filed: "FB11508814" with attached minimal sample project.

This happens in a brand new project. I created a basic iOS app. In the storyboard, added a navigation bar controller, set that as the initial view controller, and set its root to the original view controller. Log is spammed once with that warning. Seems Apple needs to clean something up; especially if newly created projects will exhibit the same issue.

Calling makeKeyAndVisible does nothing in my apps to silence this. There must be another reason for it. Could it be apps where the interface files were created a long time ago?

Got Beta 3 installed tonight and so far all is going well alongside Xcode 13.4.1. In Xcode 14, the Simulator does respond to Command-Shift-A to toggle light/dark mode. Opened two of my projects, built and ran a-ok. Closed Xcode 14, then launched Xcode 13.4.1 and opened the same projects. No more crashes there. Building and running with Xcode 13.4.1 also had no issues. No crashes when debugging. And the Simulator also responds to Command-Shift-A.

I've had nothing but issues with Xcode 14 (first beta and now even the second one). I no longer have it installed. After installing and launching it, it renders Xcode 13.4.1 (presumably any 13.x version) unstable (crashes, unexpected behavior at runtime, hot keys no longer working in the simulator). I've traced it down to something with /Library/Developer that gets messed up. After uninstalling Xcode 14, I delete that folder, then manually launch and instal from Xcode 13.4.1, Xcode.app/Contents/Resources/Packages/XcodeSystemResources.pkg

No change with Xcode 14 Beta 2. Don't know why they cannot put more urgency in fixing this issue.

It wasn't the project in any way though. It turned out that Xcode 14 Beta messed up files in /System/Library/Developer. It destabilized Xcode 13.x such that it would crash or do unexpected behavior.

Have filed feedback: FB10229268 Also, when I mentioned "/System/Developer", that should have instead been "/System/Library/Developer". That's the folder I deleted and what XcodeSystemResources.pkg recreates.

This also affected a second computer (MacBook Pro with M1 Max). The first computer was an iMac Pro. Both with macOS 12.4. For the second computer, I didn't experience crashes, but had the same issue with Shift Command A not working in the Simulator. And Xcode's builds seemed to fail more often (could not really identify a root cause). Anyhow, I was able to delete /System/Developer, then re-install those files by running Xcode.app/Contents/Resources/Packages/XcodeSystemResources.pkg So this issue appears to be isolated to files that are stored in /System/Developer

After restoring all project files, things were still messed up. So I completely purged any Developer or Xcode folder found in /System/Library, ~/Library, etc. Then, restored from a backup. Chose June 1st which was back when I had Xcode 13.4. Also re-restored all projects (archiving off any source file changes though). Re-installed Xcode 13.4.1 and so far things are working as expected. So between messing up my project files, Xcode 14 must have also messed up something in ~/Library, or elsewhere. And hurray! The hot key Shift Command A in the simulator is once again toggling dark mode. I didn't mention that ealier, but that was another function I had lost. Executing the hot key briefly flashed the Features menu in the Simulator, but the appearance didn't change. Workaround was to go into Preferences | Developer, but that got annoying.

Experiencing the same here. Though Apple's dev status page shows it's operational. Is this only affecting some users?

Finding the same. Apple's developer system status page shows it's operational though. Is this a partial outage only affecting certain users?

Completely agree. In the entire history of iOS/iPadOS devices, Apple has never made the short edge of the screen narrower in terms of resolution. Every single iPhone and iPod touch has always had a minimum width of 320 points. For iPads, this was 768 points. 768 minus 744 is only 24 points which I believe is around 1/8 inch physical size. Clearly they could have made the new mini at tad less tall and a tad wider; i.e. preserve the 768 width. It could still have slightly more than 1024 points in its height. For one of my apps, this will be a trivial fix to change content of some very large buttons. It uses autolayout, but I assumed a minimum short edge of 768. For a game app though, 768 was such a nice number. I needed at least 8 game pieces across, so each piece was rendered at 96 point. I believe Apple's fix is to now letterbox apps (if set to run full screen) which will then render images at 96.875%. Hopefully not too many drawing artifacts show up for folks due to this.