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.

Filed bug FB9094956. Will also file a tech support incident shortly as this is a show-stopper. Cannot find any workarounds.

One apparently now needs to go to appstoreconnect.apple.com. And now itunesconnect.apple.com seems to redirect to that.

Never got a reply from Apple, so got them on the phone today. Unfortunately, I still don't have a definitive answer to "is there, or isn't there a policy still in place that disallows developers from removing localizations in app updates." The person fielding my call ended up putting me on hold while they spoke with a senior advisor, and then oddly sent me email instructions on how to edit metadata in itunesconnect. Sad state of affairs. So I then took it upon myself to just create a new version for my app in itunesconnect. I then noticed that if I hoevered over the languages in the upper-right popup menu, there's a delete icon as you hover over the right side of each localization name. So I removed all except for English (my default and dev language). Pressed on Save. But, when returning to that page later, all the localizations for the new version were still there. So I performed the removals a second time and this time it stuck. Even when logging out, then back in. So definitely a bug in itunesconnect. Having said all that, I'm still months away from having an update for my main app, so I ultimately do not know if Apple will approve this version. I just wish we could get a straight answer from Apple ahead of time so we don't waste any time.

Unfortunately, Claude, any modifications to metadata or messages in the app itself would need to be localized as well. The cost of this is just too high and cannot be justified. I'm still awaiting a response from Apple. Hope to have information soon.

Very late reply, and I will seek a final answer as I'm in the same boat. I do recall many years back that developers were not allowed to remove localizations as that was deemed removing functionality. I'm hoping this will now be allowed. I localized my main app to eight other languages I believe back in 2011. But these days, the income made outside the US and Canada is effectively zero. And, I have yet to recoup the costs for these localizations. This is ultimately preventing me from adding new features to the app as my income per year is far less of what the additional localization work would cost (since I need eight languages).

Appears to be an Apple bug. I got this to happen in all my apps that have a navigation stack with two or more view controllers on it. Long press the back button and you'll get that UILog message. Doesn't matter if the menu has a single item, or multiple items. Also duplicated this in a sample master detail iOS project and attached that to feedback: FB9033847

Agreed Nick. I started with Swift when it first came out and there were some things that were indeed quite painful. I'm glad though to have started at that point though. And since around five years ago, I have only written Swift code. Nokey4, understood, but I would only move to SwiftUI if I can completely move to it. If having to deal with hosting view controllers and write code to work with the underlying UIKit items, I prefer to stick with pure UIKit instead. Agree that SwiftUI is the future. All we can for now though is to keep filing those bugs.

Thank you very much nokey4 and Claude31. I hadn't got to the part of working with keyboards yet, but my app does indeed need to modify the return button type as well as to have control over the first responder. And agreed, Claude, in that it seems SwiftUI is only ready for either static displays of information, or very basic interactions. What I will do is to continue to build out a sample app with all the things I need. Then file bugs and annotated the code with FIXMEs referencing the feedback numbers. Hopefully we'll all see these things fill in over time. Once my sample is all working, that should then be the trigger to move to SwiftUI.

Solution found: At most one Xcode project can be open that contains your shared SwiftUI views. Read on for final details on this crazy journey The plot thickens... Now the project where it started to magically work now fails again. I also found no differences in project settings between all my attempted projects. Also, the original project the houses that shared SwiftUI view... it too now fails with cannot preview in this file... Zapping that project's derived data fixes the issue. Re-opened separate project that had worked above. Still fails. Zapped its derived data. Preview still fails. Zapped shared project's derived data. Preview works! Appears that derived data that is messing up everything. NOTE: For my shared views, I had "wrapped them" inside their own project. But this is most likely messing things up since I have a single SwiftUI file I want to share, but the build system cannot deal with that setup. Then tried the following (also fails). Created a simple folder structure on my data drive (IIKit folder containing a Views subfolder containing IIAboutView.swift). Deleted all derived data. If I open one of my app project, preview works. Once I try to work on another project (even when closing the first), preview dies there. Re-opening the original project, preview dies there too. My derived data is set to "Unique". Tried "Shared" same issues... but then... Previews started to work again. Then it finally clicked. As long you only have one Xcode project open at any given time that uses the shared SwiftUI view source, all is well! I can easily now repeat the issue by opening a second Xcode project. Previews now fail with that error. You have to then close all Xcode projects and just open one. I believe during this morning's vast majority of attempts, I had my IIKit project open. Not a huge deal to only have a single Xcode project open at a time. At least a workaround exists. Will though still file a bug.

What the... when searching forums earlier, had a typo, but finally found some threads regarding the preview error. For example: active scheme does not build this file - https://developer.apple.com/forums/thread/117487 In that thread, one solution was to ensure that the file's location (in the Xcode Identity and Type inspector) is set to Relative to Project instead of Relative to Group. So... I re-created groups without folders in my Xcode project. Re-dragged in the shared source. But the preview then worked! Location is set to Relative to Group which makes sense. So why oh why did the first several times of doing this all fail? I had even restarted Xcoded, deleted all derived data earlier this morning during the above trials. Makes not sense that this would just magically start to work. ARG... Created a brand new project to see if now repeatedly will work. Nope! In the project that just started to work, I had previouslly tried the Swift package (but have since deleted that package). So my new theory is that this Xcode project got some configuration added whereas the new project doesn't. Time to compare the project files for clues.

Nope; the only reason the above worked was because I was using a workspace. But dragging around the shared files ultimately messed that all up. When I recreated an App project, no matter how I drag in the shared source, it cannot be previewed. Folder reference, In a group with/without a folder. An alias also fails since Xcode just dumps the alias file's contents itself into the Xcode editor. Finally, for good measure, tried a swift package as follows, but that also fails. I can live with some of the SwiftUI issues I've been experiencing; most have decent workarounds. But this issue is a deal killer if I cannot share code across my projects. At least with the shared Storyboard file in my UIKit projects, each project would display that storyboard a-ok. So why should a SwiftUI preview be any different? Swift package steps... Created a brand new iOS single view app project. Added a new SwiftUI file (MyView) that simply uses the defaults from the template (i.e. body has a single Text element). Preview at this point works a-ok. Created a new Swift package and added it to the exiting project. Dragged MyView.swift into the package Sources and it will now no longer preview (Cannot preview in this file - active scheme does not build this file).

Thankfully, shortly after writing the above, I found a working solution. Inside your app project (that wants to use shared SwiftUI views) you cannot use folder references or create "new group without folder" that will contain the shared items. Instead, I created a regular group inside my app project (just for organization). Then, dragged in the shared views/items. File system: IIKit Views IIAboutView.swift MyApp MyApp.xcodeproj MyApp IIKit + Views (note that this folder is empty; doesn't contain a copy of the IIKit items) Xcode main window: MyApp IIKit Views IIAboutView.swift (location of this is the "real" IIKit shared folder items) MyApp Views ... Completely non-intuative. Going to file a bug since in all my trials, the shared code resides in the same location on disk. Xcode should have worked with either folder references are when placing the shared items inside folders created with "new group without folder".

Just stumbled upon this myself. I know I have recently created fresh projects and set the deployment to 14.0. I want to say it was with earlier Xcode 12.x versions? Anyhow, I haven't done any testing with such a setting, but you can select 'Other' and type in a version. e.g. 14.0 or 12.0 Still, it's curious as to why Apple is hiding those initial versions. Perhaps those OS versions are not recommended to have anymore? e.g. enough serious issues found where they are hoping developers will just target the dot versions instead. Just a guess. For me, I'll just pick 14.1 for my new projects. By the time I'm done, iOS 15 release will be right around the corner. For iOS 12.0, I see no problems in requiring 12.1 or even 12.3. The quantity of iOS 12 years is very small and for those that cannot update past 12.x, I would assume they'd probably at least be applying all the security and other updates.

Thanks for finding that highlighting issue, BabyJ. You're correct in that it appears that when initially presented, an alert or action sheet will not be using the proper accent for the button normal states. But during interaction, the accent is then used. I have created a sample Xcode project showing the issue and filed feedback: FB8994751