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

Feedback not found.

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.

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.

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

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?

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 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?

Never mind the last question; further research shows that it does not necessarily execute on the main thread.

it seems like SwiftUI internally could ask to receive the published updates on the main queue and @Published shouldn't enforce a specific thread. I asked why publishing isn't done on the main thread automatically. The discussion is here for anyone interested.

As my work continues, I found that the MainActor solution is not a panacea because you can't make a Codable/Decodable class a MainActor. Often you need your data-model classes to conform to those protocols, and those classes are often full of published members to support display in SwiftUI. So it's back to hunting down all possible manipulations of them and enclosing them in a main-thread dispatch.

I'm trying to create a custom button where I can pass in a style. I have figured out how to pass a ButtonStyle as a parameter using a generic, but after that I can't do anything with it: struct SelectableButton: View { @Environment(\.isEnabled) private var isEnabled var text: String = "" var icon: Image? var onClick: (() -> Void) var selected: Bool = false var style: Any init<S: ButtonStyle>(label: String, icon: Image? = nil, onClick: @escaping (() -> Void), style: S) { text = label self.icon = icon self.onClick = onClick self.style = style } var body: some View { Button(action: onClick) { HStack { Text(text) icon } } .buttonStyle(self.style as! ButtonStyle) // DOES NOT WORK. "No exact matches" } }

It may be failing because the parent view's contents aren't embedded in a NavigationView. If you put the entire contents inside a NavigationView it'll probably work. I just encountered this when trying to raise a sheet from a sheet that didn't have a NavigationView. Interestingly, it failed on iOS 15 but not later.

I'm working with MusicKit right now, and found that while API calls fail in an iOS 15 simulator, they work in an iOS 16 one. Search queries do, at least.

Well, since there's inexplicably no way to delete or even edit this post, I'll follow up by saying that I found the problem. Some of my code was inadvertently reverted, and my app was creating a play-only (as opposed to record/play) audio session. This of course raises the question as to why I was allowed to create an AVAudioRecorder under an inapplicable session, when the attempt is already a "try" operation and could have thrown an informative error right there. And why was there no error message at any stage of this, saying "trying to record in a playback-only session?" Pretty lame.