My implementation was not including the "show password" button in the UI when VoiceOver was enabled. @kthchew that's a good point about letting the user manage their risk. Especially if they're wearing headphones. Should I were to include it again, and give the option to the user to speak the password; I probably wouldn't want the accessibility label to be "Show Password" Perhaps something such as "Speak Password"? Where the accessibility hint would then indicate that by double tapping the system will speak their password out. Does that sound reasonable or would something else be better for the accessibility label? What about password requirements? My thoughts are if you have a list of password requirements, that UI containing the accessible list of Password requirements should come before the actual password field when VoiceOver is enabled. This way the user knows what the requirements are before they start entering a password.

Are there any examples of Apple designed apps that behave in this manner? I can't seem to find any. If I go to any screen that is asking for my Apple ID Password, there are no buttons or UI allowing for VoiceOver to speak the password. These types of buttons in general to me seem to defeat the purpose of "secure text entry".

This is not working for me on Xcode 16.4. How is this still broken? Does Apple not have tests for their testing features? Are there any workarounds that can be provided?

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.