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.

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.