Xcode 27: Fix “no exact matches in call to initializer” with SwiftUI @State

After upgrading a SwiftUI project to Xcode 27, an initializer that delegates to another initializer may fail with “no exact matches in call to initializer” when the view contains @State. This is not necessarily a simple label or argument-type mistake. In Xcode 27, State is implemented as a Swift macro, and a view that previously received a synthesized memberwise initializer may no longer receive one. Apple’s recommended migration is to declare the required memberwise initializer explicitly.

The diagnostic

error: no exact matches in call to initializer

self.init(bar: bar, baz: baz)
          ^ no exact matches in call to initializer

Reproducing the error

import SwiftUI

struct Foo: View {
    @State private var bar = 0
    private let baz: Int

    var body: some View {
        Text("\(bar) / \(baz)")
    }
}

extension Foo {
    init(_ bar: Int, baz: Int) {
        self.init(bar: bar, baz: baz)
        // error: no exact matches in call to initializer
    }
}

In earlier Swift behavior, a type with private stored properties and no explicit initializer could receive a private synthesized memberwise initializer that was callable from an extension of the same type. Code that relies on that synthesis can stop compiling with Xcode 27.

Root cause

In Xcode 27’s SwiftUI SDK, @State is a Swift macro rather than the previous property-wrapper implementation. Macro expansion produces storage used for state management, and the compiler skips synthesis of the view’s memberwise initializer.

Consequently, there is no source initializer matching self.init(bar:baz:). Changing only the argument labels does not fix the problem because the intended initializer itself was never synthesized.

Affected conditions and versions

• The source is built with Xcode 27.
• A SwiftUI view declares a private @State property.
• No explicit memberwise initializer exists.
• Another initializer, often in an extension, calls the initializer that older compiler behavior synthesized.

Apple documents this in TN3211 as an Xcode 27 SwiftUI source compatibility issue. It is not presented as a temporary compiler bug with a promised fixed version; the durable solution is an explicit initializer.

Recommended solution

1. Declare the memberwise initializer explicitly

If the initial state comes from an initializer parameter, remove the inline default and initialize ordinary stored properties before assigning the state property.

import SwiftUI

struct Foo: View {
    @State private var bar: Int
    private let baz: Int

    private init(bar: Int, baz: Int) {
        self.baz = baz
        self.bar = bar
    }

    var body: some View {
        Text("\(bar) / \(baz)")
    }
}

extension Foo {
    init(_ bar: Int, baz: Int) {
        self.init(bar: bar, baz: baz)
    }
}

2. Delegate from the public initializer

To preserve an existing call-site API, keep separate labels for the public initializer and the explicitly declared internal memberwise initializer. The example delegates from init(_:baz:) to init(bar:baz:).

3. Exclude state from the initializer when its initial value is fixed

If bar should always start at zero, keep that inline state value and explicitly initialize only the dependency that must be supplied.

struct Foo: View {
    @State private var bar = 0
    private let baz: Int

    init(baz: Int) {
        self.baz = baz
    }

    var body: some View {
        Text("\(bar) / \(baz)")
    }
}

Alternative approaches

• Initialize the stored properties directly in the extension initializer instead of delegating.
• If callers do not need to choose the initial state, keep the inline @State value and remove that parameter.
• If the parent owns the value, consider accepting a @Binding instead of duplicating it as child-owned state.
• Move complex state into an appropriate observable model when that better represents ownership and lifetime.

How to verify the fix

1. Confirm that the failing line was calling an implicit memberwise initializer.
2. Add the required initializer explicitly in the type or an extension of that type.
3. Initialize non-state stored properties first, then assign the @State property.
4. Run Product > Clean Build Folder and rebuild.
5. Exercise every initializer path in previews, the Simulator, and on a device to verify the initial state.
6. Compile both Debug and Release configurations.

Cautions

• Editing argument labels alone cannot restore a missing synthesized initializer.
• Initialize properties such as baz before assigning self.bar.
• Keep an internal initializer private when it should not become part of the view’s public API.
• Downgrading Xcode is only a temporary workaround; explicitly declaring the initializer is the Xcode 27 migration.

Summary

In Xcode 27, “no exact matches in call to initializer” can occur because the @State macro prevents synthesis of a SwiftUI view’s former memberwise initializer. Declare the required initializer explicitly, initialize ordinary stored properties first, and then assign the state value. If the state has a fixed default, omit it from the initializer entirely.

Official references

• Apple TN3211: Resolving SwiftUI source incompatibilities for State and ContentBuilder
• Apple SwiftUI State
• The Swift Programming Language: Initialization