@SergioDCQ Thanks for the interesting observation. I didn't copy your code but looking at the dark setting I got the idea of what is happening, I think. When iOS suggests and fills a strong password, it forces the underlying TextField's background to yellow and its text color to black (to ensure the text is readable against the yellow highlight). When the yellow highlight fades out, the system is supposed to restore the original text color. However, because you are using a hardcoded color (colorScheme == .dark ? .white : .black) Since SwiftUI's state hasn't changed, it never re-applies the .white color, leaving you with invisible black dots on a black background. Instead of manually switching between .white and .black, use SwiftUI's semantic .primary color (or Color(uiColor: .label)). Replace your .foregroundColor modifiers on the TextFields with .foregroundStyle(.primary) you can force SwiftUI to re-apply the text color by slightly changing the color value when the password is autofilled. By toggling between pure white and 99% opaque white, SwiftUI detects a state change and pushes the correct color back to the text field. Would be very interesting to play with a simple focus project to see if I understand correctly. Albert
  Worldwide Developer Relations. Thank you Albert. I tried foregroundStyle primary and systemBackground but the dots remain invisible on the confirm password field after autofill. I discovered that textFieldDidChangeSelection only fires on whichever field has focus when the password is suggested. The confirm field gets filled silently with no delegate callback or SwiftUI state change, so I have no hook to trigger the color re-apply. How would you suggest forcing the color update on a field that receives autofill without focus?

But this would require I am using something like NavigationStacks, correct? I'm not using those. One view calls another and so on.

I've been scouring the web for days. Is there any solution to this? Having to shut off WiFi every debugging session is ridiculous.

So it's definitely that Xcode wins the debugger over the phone via WiFi, and not the cable. Now if I could just figure how to turn that part off, without having to disable WiFi on my entire phone at the start of every work day.

Don’t know how that happened: FB15739562 https://feedbackassistant.apple.com/feedback/15739562

Posted it just now: FB8988208

No message whatsoever....getting annoying as it hasn't worked properly in the past hour. Have do manually airdrop all the files from phone to Mac.

plug your phone into Finder itself I'm not sure if this means something in particular. Viewing the iPhone in Finder shows nothing of files, etc etc. Just all about syncing. If there is another mode or something would love to find out.

As I stated in the OP , this doesn’t work.

I just went through this today! Go to https://developer.apple.com/news/?id=jxky8h89 and scroll to Configure exception domains Walks you step by step how to if you don't have info.plist anymore.

It appears I asked this in the wrong forum, my apologies

I despise finding the answer less than 15 minutes after I posted the question. It's so embarrassing. Anyway, I really did a lot of Googling, with plenty of wrong answers. And then buried within the useless pile I found this: In Xcode's Project Navigator Window simply right-click the file you wish to view and select Open In a New Window. Not sure which is more embarrassing, that I found the answer after posting the question, or that the solution was so obvious and I didn't try it.

I will do the above next time it occurs. Of course I just tried it, and all works normally. Go figure. Thanks

Just to close this thread out: I was booting off of an external SSD drive. The drive itself was slow, so that was this issue.

So I went to ChatGPT to see if it could help me solve this problem. Encased the code that causes the alert to popup with: DispatchQueue.main.async { [self] in ... } and now I no longer get this warning. Is it that simple? Is CHatGPT that scary?