Post not yet marked as solved
Bug also exists in Xcode 14.1 Beta
Post not yet marked as solved
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.
Post not yet marked as solved
Also filed: "FB11508814" with attached minimal sample project.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
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.
Post not yet marked as solved
Experiencing the same here. Though Apple's dev status page shows it's operational. Is this only affecting some users?
Post not yet marked as solved
Finding the same. Apple's developer system status page shows it's operational though. Is this a partial outage only affecting certain users?
Post not yet marked as solved
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.
Workaround (got help from Apple DTS; they confirmed the bug in iOS 14.x):
First, don't have any subclass of UISplitViewController as the following workaround will fail if having a subclass. Thankfully, I no longer needed to subclass.
In your storyboard, set the split view controller's style to "Unspecified (Discouraged)".
That's it. But read on for workarounds to other issues that I found and needed to work out.
At least in Xcode 12.5, there's a bug when rendering view controllers in storyboards with split view controllers. I have my storyboard set to use "View as: iPhone 11". For split view controllers with the unspecified style, any navigation view controller connected to either the master or detail controller of the split view will not render correctly. Also the connected root view controller will also not render. Instead of seeing your view controller's content, the entire content area is blank, no navigation title is shown either, and you just see the back button.
To work around this issue, I created separate storyboards to hold both the master and detail navigation view controllers and their child controllers. Then, set up storyboard references. Not ideal, but it does make for smaller sized storyboards and the nav controllers and their children now render correctly so you can edit them.
Finally, in my app, I needed to preserve the bit of logic I initially had in my split view controller subclass. Which was to make it its own delegate and return 'true' from splitViewController(_:collapseSecondary:onto:) when dealing with compact size classes.
To deal with this as no subclass works, I created a separate class to represent my delegate:
final class IISplitViewControllerDelegate : NSObject, UISplitViewControllerDelegate {
func splitViewController(_ aSplitViewController: UISplitViewController, collapseSecondary aSecondaryViewController: UIViewController, onto aPrimaryViewController: UIViewController) -> Bool {
aSplitViewController.traitCollection.horizontalSizeClass == .compact
}
}
Then, in the storyboard, I added an object to each split view controller, set it's class to be my delegate, and control-dragged the view controller to that object and set it as the delegate. Now, when these split view controllers are awoken from the nib (storyboard), an instance of my delegate will be made and assigned as the delegate. All works perfectly now.
