There are at least two common choices: Set the variable in onAppear instead of on the same line as the declaration Set the variable in init, like _user = State(initialValue: users.user1) See https://stackoverflow.com/questions/56691630/swiftui-state-var-initialization-issue

The second parameter to dispatch_queue_create() is used for DISPATCH_QUEUE_SERIAL or DISPATCH_QUEUE_CONCURRENT. As for dispatch_get_global_queue(), who knows? It could have been used internally or they thought they would need it but never did. ObjC doesn't support default values like Swift does, so a lot of old code requires extra parameters.

Did you ever solve this? I'm having the same issue.

With the help of Apple engineers during the WWDC, we determined that my primary problem was that I used both --target and --scheme parameters to xcodebuild. Turns out --scheme alone works much better. There was another problem in my bash script and xcodebuild didn't return errors well in that case, but that was a secondary issue.

Same issue here using the tvOS simulator. Haven't tried a real device yet.

We are having the same issues as everyone else. I had hoped the virtualization framework would be more useful, but the inability to login to our developer account means we can't sign our apps within Xcode or test them via the App Store. I filed FB11839055.

We are having the same issue. Same errors in the log. Did you ever figure out what was happening?

We are having similar problems on macOS Ventura. I see warnings in the console log from the apsd daemon, but nothing helpful.

I reported this as FB12350186.

As a temporary work-around just to get your app building and running, you can declare the function yourself: func Button(_ str: String, image: ImageResource, action: @escaping () -> () ) -> some View { Button(str, action: action) }

I had the same problem earlier today and it just magically went away. Try again now. It's June 19, 2025 at 10:40pm EDT. I'm assuming it was a server side issue.

Same issue here with a very simple sample app.

Some weird things are happening. Someone on the iOS-developers Slack channel figured this out: // This fails @State private var session = LanguageModelSession() // This works @State private var session = LanguageModelSession(guardrails:.default) I verified this fixed it a few hours ago, but now: After a few hours both started working fine, like Apple fixed the model remotely. Is that possible? There's a secondary problem where model results are cached EVEN IF AN ERROR OCCURS. This means that if the session returns an error for whatever reason, including a temporary Apple bug, the identical query will continue to return the same cached error even after quitting and re-running the app. Unfortunately I can't submit a bug report on this because I can't force an error any longer. Please let me know if this is fixed for you now or if you need to add the guardrails parameter.