@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.

After you accept the latest developer agreement, there is a 5-10 minute delay before this error resolves. I've contacted Ken Orr directly to request a fix. I've reported this issue for years and the Radars are just getting ignored...like all Radars. Hopefully putting a spotlight on this with the head of Developer Tools will get it addressed.

In general, the only way to ensure that Xcode releases get fixed is to email Craig Federighi (head of software) or Ken Orr (head of developer tools) directly. Filing “feedback” or discussing the problem on these forums will have no effect—unless you catch Eskimo’s attention and he runs the issue up the chain on your behalf. I would encourage you all to email those executives. If they see enough noise, someone will force engineering to take a look. Otherwise, this issue will run for a year because Apple‘s feedback process is absolutely broken.

The issue is still present in the GM Release of Xcode 15. (This is my shocked face.) It manifests for me anytime I run a playground. @zettlunic - do you know what "-OS_ACTIVITY_MODE disable" does, precisely? @riccardo_p - do you have a link or a description of what, exactly, we're adding there? I'm a little hesitant to use these fixes without a better understanding of exactly what the changes are doing. Thanks!

The issue still manifests in Xcode 15 beta 2. It's now June of 2023. You guys must be new here. Apple Engineering never fixes ANYTHING in fewer than seven years and they maintain absolute radio silence the entire time. There are no updates. There will never BE any updates. The issue will continue until someone high enough in the organization is affected by it. See you in 2031.

Spoiler alert: it wasn't fixed soon. Still manifesting with Xcode 14.2 and Ventura 13.1

Details: I have already deleted Xcode's preferences, caches, and the entire ~/Library/Developer folder. No change. The issue happens on a BRAND-NEW project, so it's not a problem with a certain project's Xcode config file. I can reproduce the problem 100% of the time on two separate Macs. I am running Monterrey 12.4