The issue is resolved in iOS 26.4.1. Let's hope they added some tests so it never happens again.

Since this is obviously a widespread issue and affects Apple's own apps, it might be useful to draw some public attention to it. Submitting a tip to the usual Apple news sites (the forums hilariously edit the names out!) seems like a good start. I know Apple likes to say, "Running to the press never helps," but....it absolutely does. The more high-profile the issue becomes, the more likely Apple is to push a 26.4.1 release to fix it. The alternative is waiting 1-2 months for the 26.5 release.

Same exact issue. Filed FB22390203. I hope there's some accountability for the engineers who shipped such a MASSIVE regression. They definitely ought to be reassigned to a less-critical, simpler project.

Update: I've reverted to using Claude in the Terminal. The implementation in Xcode 26.4 is just so godawful buggy that it's unusable. (I've discovered that if you quit and restart Xcode, the chat history suddenly contains TONS of text that wasn't showing up previously!) Whatever the reason, Xcode 26.4 is just crippled. I haven't tested the new 26.5 beta because you can't ship apps from it yet.

Zorast's post comes off very angry. I definitely understand why though: Apple steals a LOT of money from its developers and they justify that by saying, "It costs money to provide all the tools and frameworks." In that context, there is no excuse for shipping broken, hamstrung tools. Oauth token expiration is a decades-old solved problem. It was solved in Xcode 26.3, even! Allowing that to slip through QA is not excusable. These tools aren't free. They aren't volunteer projects. There is a standard that is expected and Apple is failing to meet it.

Chiming in to say three things: The Oauth token expiration happens to me as well. I can't find an exact pattern, but it seems to happen when I leave Xcode idle for a while. I'll go have lunch, come back, and suddenly I have to sign out and sign back in to Claude Agent. The AI seems to "lose itself" a lot. It'll begin responding to a prompt, I'll see output in the chat, but then it'll hang at "Thinking..." for a couple minutes. Suddenly, it'll pick up again and it always starts with: "I should resume..." or "I'll resume...", as if the original session got interrupted. My internet connection is rock-solid; that is NOT the issue. This happens very frequently and it's pretty annoying because it adds minutes of overhead to what should be very quick, easy requests. Unlike Xcode 26.3, version 26.4 now puts much of the AI's "thinking" into chat bubbles that cut off the text and are not expandable. This is very dumb. I WANT to see what the AI is thinking. Xcode 26.4's UI is actively harmful and in the way. The only bubbles that can be expanded are plans and checklists. There also doesn't appear to be much rhyme or reason for what goes in a bubble and what doesn't—some "thinking" text appears in the chat normally and other text is cut off in bubbles. Lay off the bubbles. Just give us the chat. ** All of the above applies to Claude Opus. I don't use Sonnet or Codex.

@FxFactory Thanks. It's infuriating that this kind of thing gets through QA because Apple turns right around and tells anyone who will listen that the billions of dollars they steal from third-party developers are needed to support all the APIs and tools that they offer. Tools that are frequently crippled and broken. The only way I've ever had any success getting Xcode/compiler bugs addressed is by emailing the head of the Developer Tools team directly and copying Craig on those emails. If you make a big enough visible stink at the company, you can get things seen. Update: I can confirm that it's sufficient to compile on any Mac running macOS 15.x. The architecture doesn't matter (which would have been extremely surprising.)

Has anyone notified Apple Engineering about this regression? We're getting very close to a GM release of both Xcode and macOS 26 and this is a show-stopping bug for older codebases. If there's a bug in a legacy framework that isn't the newest, shiniest, whiz-bang thing, it can languish for years because nobody at Apple cares.

This behavior continues to plague iOS and iPadOS 26 Beta 4. The List itself scrolls 100% smoothly, but the scroll indicator is choppy and jerky. This manifests even when each row element is given a fixed height. Once you scroll the List all the way down (in my example, I have about 30 rows), the indicator will then be smooth as you subsequently scroll around. It's almost as if the indicator is jumping around in reaction to new "in-flight" rows being added just outside the ScrollView's clipRect. As if the new rows are staged and ready to scroll into view and as they are added to the view hierarchy, the indicator size/position is recalculated based on their presence.

@lehrtim No. The issue is unresolved. I had hoped that macOS 26 would prove better—especially since the WWDC sessions called out massive improvements in Table performance for large data sets, but that appears to be vaporware. I see far worse performance on 15.5 and 26 than I did on macOS 15.4. Unfortunately, the best advice I can offer is: stay away from SwiftUI Table. Use AppKit and NSTableView directly.

@Decimal Out of curiosity, have you tried removing the word "kill" from the prompt? Maybe something like: "What treatments can I apply to clothing to keep deer ticks away?" The guardrails are definitely poorly-calibrated. I get safety violations just asking for a taco recipe. In this case, there's at least some defensible reason for why a guardrail might trip up on the word "kill". I still think Apple is going to render FoundationModels completely unusable if they don't fix their guardrails, but you might be able to game their system until then with some wording tweaks.

They're insanely restrictive. I've filed multiple reports with examples that aren't even in the same universe as unsafe content. If Apple doesn't fix them, the entire FoundationModels framework is essentially useless for a production app. You just can't ship something that fails 50% of the time with spurious "safety" violations.

Same here. Started just this afternoon, around 1300 PDT. It's WAY worse than just predictive code completion in Xcode 26 though. Apple Intelligence has completely collapsed across ALL of my devices: Mac, iPhone, iPad. On iPadOS 26 and iOS 18.6. Across all apps/tools that use Apple Intelligence. Image Playground doesn't work, writing tools don't work, even Siri has fallen back to the old orb UI instead of the glowing ring. It spread like a virus: I got the message that Xcode couldn't load its prediction model. Then, the iPad app I was working on suddenly started failing to load Foundation.Models. Now, Every device is stuck at "Downloading models" in Settings > Apple Intelligence & Siri. The Mac reports 100% complete there. Other devices just say "downloading." Attempts To Fix There are threads talking about switching languages from U.S. English and restarting. None of that works. There are threads describing how to manually delete the generative model downloads by booting into recovery mode, disabling SIP, and using Terminal. Did that on my Mac. The files re-downloaded, but Apple Intelligence is still borked. Conclusion Someone in Cupertino pushed something or changed something server-side that has completely borked Apple Intelligence on 19 June 2025 for anyone running the betas. My wife's devices do not appear to be affected, but all of those have the latest release versions of iOS/macOS. There is a large thread with reports here: https://www.reddit.com/r/iOSBeta/comments/1lf99ux/ios_26_db1_apple_intelligence_uninstalled/ And many posts on X about the issue. Something broke today.

I'm not sure that the conclusion, "You can't use willSet/didSet with @Observable" is correct any longer. With Xcode 16, the @Observable macro expands a simple String property as shown in the image below. Note that the "didSet" expression is copied to the newly-generated stored property "_name". Depending on exactly what you're doing in the property observers, they should just work.

Same here: apps built with the GM version of Xcode 16 crash on Intel Macs because the QuicklookUI framework is not loaded. It's really inexcusable that this made it to the production release of Xcode 16. It was reported (AND ACKNOWLEDGED!) in the beta period and nobody at Apple Engineering cared enough to do anything about it. We PAY for this. Apple loves to brag about how the 30% fee it collects goes to support APIs and the platforms. Really? Does it? Does anyone here feel supported? FIX THE BUG, Apple.