A project that compiles cleanly in Xcode 26 fails to compile in Xcode 27 with the errors shown in the screenshot. This seems like a simple regression in the compiler that will get fixed, but is there something about this that's actually illegal?
Moving the three assignments above the conditional resolves the errors.
I reported it via Radar, but it seems like a Swift issue rather than an Apple issue.
What are the declarations of the properties you’re initializing? Are they simple stored properties or something different?
This looks like the issue called out with the new @State macro. Is this a SwiftUI view init?
Ah, I see the issue. Removing the default values for the @State declarations also resolves the errors. But the compiler's feedback is a bit misleading here: the issue wasn't really the three assigned properties, it was the new macro implementation for @State.
Seems like a better diagnostic would help people. The current diagnostic focuses attention on the wrong thing.
///
/// Shows a small UI to apply flags to various cells of a CueSheet.
///
struct CueFlaggerView: View
{
@Environment(AppController.self) private var appController: AppController
@Environment(\.dismiss) private var dismiss
private let clickedColumn: CueColumn
private let masterCueIDs: Set<UUID>
private let jobVersion: JobVersion
@State private var selectedSeverity: CueFlagSeverity
@State private var selectedScope: CueFlagScope
@State private var isLoud: Bool
@State private var isApplyButtonEnabled = true // Prevent double-clicks.
///
/// Initializes the view so that the options match the properties of `referenceFlag` (if available).
///
init(referenceFlag: ScopedCueFlag?, column: CueColumn, masterCueIDs: Set<UUID>, jobVersion: JobVersion)
{
if let referenceFlag
{
selectedSeverity = referenceFlag.severity
selectedScope = referenceFlag.scope
isLoud = referenceFlag.isLoud
}
else
{
if let sev = CueFlagSeverity(rawValue: UserDefaults.standard.integer(forKey: UserDefaults.Keys.cueFlagLastSeverity)) {
selectedSeverity = sev
} else {
selectedSeverity = .red
}
if let sc = CueFlagScope(rawValue: UserDefaults.standard.integer(forKey: UserDefaults.Keys.cueFlagLastScope)) {
selectedScope = sc
} else {
selectedScope = .jobVersion
}
isLoud = UserDefaults.standard.bool(forKey: UserDefaults.Keys.cueFlagLastIsLoud)
}
self.clickedColumn = column
self.masterCueIDs = masterCueIDs
self.jobVersion = jobVersion
}
}
The fix for this was explicitly called out in What's new in SwiftUI starting at 23:45
Ok. But if properly interpreting the diagnostic relies on, "You didn't watch that one video from 2026?" it's a diagnostic that could be improved, no?
It doesn't really bother me either way, it just seems like a misleading error.
As for the videos themselves: they're a little tough to watch. They're so overproduced, it's hard to sit through them. I wish Apple would let you guys just...talk. Like a podcast or a nice YouTube video!
100%. I think this will trip up a lot of people, even our future selves so the diagnostic should certainly be more helpful here.
As for your second point, I agree but I think a prior step should be enhanced documentation. Particularly SwiftUI - I find it amazing that we have to rely on 3rd party deep dives to deeply understand core concepts. Take this article by AirBnB for example. On the one hand I love that some insight towards the diffing algorithm was given, on the other hand I don't like that Apple hasn't deemed this education necessary for developers. Perhaps this video collection presentation style of WWDC is a consequence of the highly proprietary nature of the software that we're dealing with. But I digress.
Remember that this is a beta releaes, so if you feel that there are bugs or diagnostics that could be improved, please file issues on GitHub (or a Feedback for Apple frameworks issues)!
Always good practice to ask for a sanity check before telling compiler engineers that their compiler is wrong.
In this case, I think the correct fix is for the new @State macro to show an error if a default value is assigned and an initializer also sets a value. That would be the ideal outcome and it would fall on the SwiftUI team at Apple.
On the compiler side, the only improvement I can see that would apply generically would be a heads-up that the issue is coming from within a block written by a Macro. Something that clues the developer: “Oh, the problem isn’t in the code I’m looking at; it’s in the hidden code that’s being written automatically.” Maybe something like this: In @State Macro expansion: return from initializer without setting foo.
That would help, but since you can “fix” this error by moving the three declarations above the conditional, the real fix is still an enhancement to the new State macro.