Xcode 26 Beta 5
Xcode 26 beta 5 requires a Mac running macOS Sequoia 15.5 or later.
The download is back to being a .xip file, and there’s a slightly smaller Apple Silicon–only version. Again, the release notes don’t actually show what’s new in this build.
The
spanproperty ofUTF8Viewdoes not support the small string representation in beta 1, and traps for smallStringinstances. A future version of the Swift standard library will lift this restriction. (137710901)
This scary warning is still there at the top, and it was looking to me like “future version” meant “after OS 26.0,” but actually it was apparently fixed “a few betas ago.”
Sean Heber (Marcin Krzyzanowski, Der Teilweise):
What the heck? These icons are a blurry mess in my dock and the simulator icon just looks like a black blob.
Holy cow.. they actually fixed this in Xcode b5?! I ran into this when I was playing around with SDL and GLFW and some other OpenGL/Metal things (checks notes...) over two years ago! Even then it had already existed for some time prior because I found a forum thread about it.
Even though I don’t use Swift Concurrency, I had to update my Core Data code due to the changes documented for macOS Tahoe 26 Developer Beta 5.
First, it wants NSManagedObjectContext subclasses to be marked @unchecked Sendable, i.e. restate what they inherit.
Second, and more seriously, I got a ton of errors like this:
'nonisolated' is not supported on lazy properties; this is an error in the Swift 6 language mode
None of these errors showed line numbers, and they supposedly originated from files that don’t even have lazy properties. The files that do have lazy properties had no errors shown—or maybe there were so many copies of these same errors that the actual relevant files didn’t make it through the truncation of the long error list.
My first guess was that the problem is that NSManagedObjectContext is now NS_SWIFT_NONISOLATED, and one of my classes has some lazy NSManagedObjectContext properties. After all, the error seems to be saying that lazy properties can’t be nonisolated. Isn’t that what the on means? But making those properties non-lazy didn’t help.
If I read the error “backwards,” that lazy properties aren’t supported on nonisolated types, it makes more sense. I changed the lazy properties on my NSManagedObjectContext subclasses to IUOs, and that helped, but I don’t really understand what’s going on here. I get that lazy could make it hard to guarantee which thread is doing the initialization, but isn’t it already using the annotations to opt out of that checking? I only access the context’s properties from within a perform block, and it’s only intended to be an unofficial actor, anyway. The error seems completely irrelevant, except that if I don’t satisfy it my code won’t compile. (I don’t want to turn off SWIFT_TREAT_WARNINGS_AS_ERRORS or try to selectively suppress this warning, as it will probably eventually be useful for other code.)
Changing to IUOs worked for one target, albeit at the cost of slower runtime performance and higher memory use for properties that often are not actually used. Then I ran into the same errors with another target. Again, Xcode couldn’t tell me which file they originated from. It turns out that NSManagedObject is now NS_SWIFT_NONISOLATED, too, so it can’t have lazy properties, either. Apple says that the changes are intended to “resolve compatibility issues,” and that they “might introduce new warnings while building source code that violates the longstanding CoreData concurrency guidelines,” but I was not violating the guidelines!
This whole situation is infuriating. I don’t mind adding some annotations for Swift Concurrency, but the compiler should tell me where the errors originate from, the error should say what the actual problem is, and the language shouldn’t suddenly make my longstanding code structure illegal when I’m not even using Swift Concurrency. And this is not the WWDC build of Xcode; it’s introducing big changes in probably one of the last betas before everything ships next month.
When I finally got my app compiling again, I found that the weak linking bug is still present in beta 5.
Previously:
- macOS Tahoe 26 Developer Beta 5
- Xcode 26 Beta 4
- Swift Vision: Improving the Approachability of Data-Race Safety
- Unwanted Swift Concurrency Checking
Update (2025-08-07): I ran into a Swift compiler crash calling the AudioObjectGetPropertyData() API.
