Thanks again @eskimo . I have revised my code and have it working, with both model and controller as MainActors. And most of the work I'm doing does indeed boil down to a URLSession, so that's good per your remarks. Now... when I do want to move work off the main actor (but instigate it from said actor), what is the recommended way to do so? If I call another actor from a main one, does that call not execute on the main thread?

Further experiments reveal more shenanigans. If I make the model a MainActor, I can't access any member of it without "await." This means even examining a member variable must be couched in "await." Not exactly tidy. After more reading, I thought that maybe my concerns about making the controller a MainActor were misguided, because I can mark long-running functions async and await them, so they don't block the main thread even though they're in a MainActor... right? So I took @MainActor off the model and put it on the controller. Do I need to worry about starting long-running processes in a MainActor if the processes are marked async?

Thanks for that info @eskimo ! I don't consider concurrency to be the big issue in what I'm attempting to do. Yes, concurrent things are happening, but I'm reasonably comfortable with where they are. I just want to make SwiftUI work. My model is passive, but it is not observed and manipulated by the UI directly. Between the two I have a controller (or "viewmodel" or whatever you want to call it), and the UI observes things in it and then conveys the user's intent through the controller. This is the arrangement I've seen recommended by the vast majority of materials on the subject. The controller understands the model, kicks off potentially long-running async processes (which is why making it a MainActor seems unwise), and then updates things that the UI is observing (in itself). Otherwise, are we to couple the UI to both the model and to a controller?

Isn't it great how the text in the pane itself refers to it as "preview," but nothing else does?

Thanks a lot for the reply. I did set up a CA. Maybe that's different from "self-signed," but I used mkcert to create a CA and install it. I then added it to the Keychain and set it to "always trust" for all applications. I also used mkcert to generate server certificates for localhost and the name of my computer on the local network. I did get the CA onto a simulator by uploading it to a Web server and then hitting it by URL in the simulator's Safari. I have it installed on the simulator, and I confirmed that its serial number matches that of the CA on my Mac. But the certificate is still flagged as "invalid" when my application tries to hit my server at localhost... Aha, looking at your comment again and assuming you noticed I said iOS 17... I went back and looked in the settings area you mentioned. Sure enough, there is now the Trust switch there, and it was off. It's some bad UI to scatter these certificate functions between "VPN and Device Management" and "About." But your comment clued me in, so now it works! The CA remains shown on "VPN and Device Management," by the way; it's not the blank screen that bounces out anymore. In case that's useful to you. Thanks again.

I encountered this today, and found that it was caused by loading a view controller from a storyboard by name... as the base view-controller class and not the derived class that it is specified as in the storyboard. So I understand why the overridden methods wouldn't get called. What I don't understand is why, when instantiated with the exact same method, some other derived controllers' overrides DO get called.

Feedback not found.

Yep. Clearly this is a major issue. I did find an apparent workaround: Open up the xcodeproj as a directory and delete xcworkspace. That appears to fix it. Bug filed with Apple. Report this, folks: feedbackassistant.apple.com

If you look carefully, you'll notice that the additional row of Mac icon images doesn't end with a 512 x 512 one. That last one has fine print that specifies a 1024 x 1024 "2x" one. Unbelievable.

Talk about obscure. I especially appreciate having my time wasted by the Xcode "validation" process's reporting success and uploading the whole product, only to be told on submission that an obvious item is missing.

Apple pulled the same thing a few iOS updates ago, and again didn't warn anybody. Talk about disregard for developers, who may have a critical deadline for a release.

What behavior are you seeing in the UI? I may be seeing the same thing. Keychain Access presents a dialog asking for your password, but there's no cursor in the password field and it doesn't accept any input. You have to kill Xcode to get out of the state. I don't see that message in the console though.

Deleting the ~/Library/Developer/Xcode/iOS DeviceSupport directory for iOS 14 did not work for me.

I had the same problem. It took a full minute to launch my app on an iPhone from the debugger. The screen was blank the whole time, and there was no debugging-console output. I have no idea what it was doing. I also have no idea why this behavior suddenly stopped; now the app launches in a reasonable amount of time.

I had this too. It took a full minute for the app to launch on the iPhone from the debugger. The phone screen was blank the whole time, and there was no console output. I have no idea what it was doing. This behavior mysteriously stopped at some point, and the app now deploys in a reasonable amount of time.