Error: 'async' call cannot occur in a property initializer

Question

I'm trying to place a StateObject actor whose initializer is async in an App, but I can't find a way to do that.

Let's say I have this actor:

actor Foo: ObservableObject {
    init() async {
        // ...
    }
}

This results in the titular error:

import SwiftUI

struct MyApp: App {
    @StateObject
    var foo = await Foo() //  'async' call cannot occur in a property initializer

    var body: some Scene {
        // ...
    }
}

This results in a similar error:

import SwiftUI

struct MyApp: App {
    @StateObject
    var foo: Foo

    init() async {
        _foo = .init(wrappedValue: await Foo()) //  'async' call in a function that does not support concurrency
    }

    var body: some Scene {
        // ...
    }
}

And even these won't work:

import SwiftUI

struct MyApp: App {
    @StateObject
    var foo: Foo

    init() async {
        Task {
            self._foo = .init(wrappedValue: await Foo()) //  Mutation of captured parameter 'self' in concurrently-executing code
        }
    }

    var body: some Scene {
        // ...
    }
}

import SwiftUI

struct MyApp: App {
    @StateObject
    var foo: Foo

    init() async {
        Task { [self] in
            self._foo = .init(wrappedValue: await Foo()) //  Cannot assign to property: 'self' is an immutable capture
        }
    }

    var body: some Scene {
        // ...
    }
}

It seems no matter what I do, I cannot have a Foo be a member of MyApp. What am I missing here? Surely this is possible.

I run into the same problems with SwiftUI Views too, so any advice that works for both Views and Apps would be spectacular!

Answer 1

I would like to give you an idea how one can solve this problem:

When you want to initialise a certain State value which takes a prolonged time and thus you may execute it asynchronously, you can use the following pattern:

You start off with your "State", which is initially not initialised, say undefined. One way to model this is shown below:

struct AppState<Value> {
    enum State {
        case undefined
        case initialising
        case idle(Value)
        case mutating(Value)
    }
    var state: State = .undefined
}

Obviously, your initial state of AppState equals undefined.

Now, let's assume, there is something which initialises it (it will be your View Model later). When it's about being initialised, its state transitions from undefined to initialising.

When it completes, its state transitions from initialising to idle.

Note, that there's nothing "asynchronous" here - all state transitions happen "instantaneously".

You may also notice, that there is some additional value, only occurring in state idle and mutating. This is called "extended state value".

I also added a "mutating" state indicating, that you can do mutations on the AppState and reflect this in your variable appState accordingly.

You may already sense that this kind of modelling leads us to some sort of "Finite State Machine" (FSM), which takes this state and performs mutations when receiving "inputs". One of them is "initialisation".

Your ViewModel may now implement the necessary missing parts of this kind of Finite State Machine:

A set of State (like above), a set of Inputs (an Enum), a set of Outputs (an Enum), a transition function (pure) and an output function (pure), and a function which transform AppState to some ViewState which gets rendered in the View. User actions will be wired up via callbacks which eventually gets routed into the system as Input values. Output values trigger "side effects", which exactly is your asynchronous "App State initialisation" function. Side effects return Events, which again get routed into the Input of the system.