It seems like with Swift files the compiler flags that are added via the Build Phases pane on a per file basis are simply ignored. If say I add a nonsensical flag to the Swift file in question, everything builds fine. Adding the same nonsensical gibberish to say an Objective-C file in the pane, and then I get the expected "Unknown argument: " compiler error. Is this expected, is there no way to add specific compiler flags to individual Swift files? In particular, I would like to add the new deprecation warning suppression flags to a specific file in my framework as documented by this Swift Proposal... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0443-warning-control-flags.md

Yes, say an informational list that may present data such as a user's contact info in a "stack" or grid, alongside other types of list items. Some folks will also say that VoiceOver should announce "List Start" and "List End", which to me seems unnecessary and redundant because iOS will provide haptic / sound feedback when you reach the end of the list, and excessive or "chatty" VoiceOver announcements I know can be annoying. I always use the screen curtain to test at the end of the day, and so if I find something annoying or difficult to use with the screen curtain, I know others will also feel similar. However, sometimes Accessibility Auditors will insist on putting such announcements such as "List Start/End".

Any updates on this or Radars that have been filed for this enhancement? I'm starting to see pieces of code where people simply instantiate a UIHostingController, grab the view from it and put it in their view hierarchy without properly adding the hosting controller instance as a child view controller of a parent view controller and such. I'm working on internal UI Framework and we'd like to provide some pre-built chart component (via the SwiftChart framework) views for our company developers to use. It would be great if say _UIHostingView was public to allow us to do that. I'm getting feedback that our internal developers want a UIView instance to make integration into their UI's easier, which I understand their feedback, and is a perfectly reasonable expectation.

Thank you, great advice on Log Noise. Given the wording of the console message, it made it sound like I was doing something wrong, and yet the app behaved correctly. After looking over my code and implementation, everything seemed fine. At that point I went to check and compare sample code only to see the same message. With that said, I have filed Feedback #: FB13456050.

Just an update here after my original post this morning. I've been trying to use this new UI all day, and the more I use it, the more I hate it. And I'm constantly afraid I'm going to accidentally perform an action I didn't intend. One issue I ran into today, was code that I had deleted, was showing up in the UI. I could have sworn I deleted it and was wondering why it was appearing as though it had been added. Looking in the SourceTree app, the lines in question were clearly marked in Red. But the Xcode UI instead shows it as a faint background, the exact issue that I see @YukonJJR describing above. Maddening. Unlike the original side-by-side editor (which existed as such for years and no one complained about), this new version as far as I can tell is no longer a live editor either. I can't simply go and fix a typo in a comment right there as I'm reviewing the diff, as I normally would with the functional commit interface in prior versions of Xcode. I also ran into many of the issues @keithburgoyne described, terrible scrolling, not showing files properly, etc. And its not like I was making major changes. I just don't understand these decisions and how something so shoddy and questionable like this can be released. Especially when there are plenty of other areas in Xcode that are buggy that need fixing (as far as I can tell, none of the bugs I reported in the virtual labs this year at WWDC to the team seem to have been fixed). But yet, the team had the time to "fix" something that wasn't broken. And its not just the dev teams, some of these product decisions like the "Fine Woven" case seem to be becoming a debacle that should have been spotted a mile away. Like what some friends repeatedly say to me as of late, the quality of everything has just gone downhill, and so have the standards. I went and filed a Radar anyway requesting they revert back (or at least provide a setting to enable the previous version). Thats really all I can do that this point, and hope others do the same.

Glad to see I'm not the only one. I very much prefer the side by side, and found the old interface to be great as it was, and this current implementation unusable.

Literally just happened to me last week as well. I've got another Radar I need to draft up this week as well, so while I'm doing that one I'll knock out this one real quick as well.

I still haven't had time to create a sample project for a Radar, I will try to get to it this week. I will post the Radar number here when I file it. Seems like I'm hitting a strange edge case because I am not seeing the issue outlined above with another one of my IBDesignable views. I think I will also need to file a Radar on the ability to remove a post that was accidentally marked as "Accepted". Seems like others have been having the same issue for quite some time per this post. https://developer.apple.com/forums/thread/662659

I just upgraded to Xcode Version 14.0.1 (14A400) last week, and now I too am seeing this error message. Whats also frustrating is when copying and pasting the error message into the search bar on the main page of these forums, no threads are found. I paste the exact same text into Google and this thread is first on the list. I'm assuming many of you found your way here as a result of a Google search as well. Well, either way, glad to see I'm not the only one encountering this. My project is a very basic "sample app" for developers using our Framework, setup entirely in a Storyboard with a handful of scenes. I did double check the Deployment Target as mentioned above, this was already properly set.

Some more findings, if I change the class type to that of my Designable, and then right click on my Storyboard and choose Open As > Source Code and then right clicking on the Storyboard once again and selecting Open As > Interface Builder - Storyboard the IBDesignable begins rendering properly. Whats strange though is if open the storyboard into a tab or window in Xcode, close that window or tab and re-open the Storyboard, that doesn't work. But if I view the Storyboard as source code, then toggle back, it works. Clearly some sort of a bug. I suppose at this point I need to write a note in my documentation containing instructions documenting this workaround to developers using my UI component. Because if I file a Radar with a sample project containing my code, it'll just sit in Radar for years and years, along with all my other Zombie Radars that have just been sitting there.

Not sure why the above reply was marked as "Accepted". Perhaps I clicked something on accident, but there appears to be no way to undo that or edit any existing posts on these forums. Very frustrating.

Just a update, I am seeing the same issue in Version 14.0.1 (14A400). And while my attributes appear in Attributes Inspector, it also appears when clicking on the view and going to the Editor menu that the "Debug selected views" menu item is disabled.