I'm now lamenting ever supporting the iPad. It seems that device is just not playing nice. In SwiftUI you're supposed to be able to use .windowResizability(.contentSize). On macOS, I use that along with modifying my main view with .frame(idealWidth: 1024, idealHeight: 768) and this forces the window to have a content area of that size. tvOS is a non-issue since you're always dealing with 1920 pt x 1080 pt screens. iPhone also a non-issue at least for my games. But with iPad and iOS 26, even if attempting something similar as for macOS, you really don't have ultimate control. I was able to at least set a min of 360 and max of around 500 for the iPad window. But attempting say 720 x 720 will fail since a user and/or system can resize the window. And even when using Canvas, content will now be offscreen. Example (see attached). The actual window height is around 560 pt. So querying the size parameter to Canvas seems to be useless if wanted to use to drive how big to render things. Apple made a huge mistake in not allowing full screen apps on iPad for iOS 26.

swiftlang/swift issue: https://github.com/swiftlang/swift/issues/83610 Swift Forum: https://forums.swift.org/t/insight-needed-for-equatable-with-default-mainactor-isolation/81675

Agreed that moving away from awakeFromNib would be best here. Thank you both!

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.