Is it safe to mutate @State variables from inside an async block in SwiftUI?

Question

I have the following struct (View) that uses async/await internally.

struct CachedAsyncImage<I: View, P: View>: View { @State var image: UIImage? let content: (Image) -> I let placeholder: () -> P let url: URL? public init( url: URL?, @ViewBuilder content: @escaping (Image) -> I, @ViewBuilder placeholder: @escaping () -> P ) { self.url = url self.content = content self.placeholder = placeholder } var body: some View { async { guard let url = self.url else { return } let session = URLSession.shared let taskResponse = try? await session.data(from: url, delegate: nil) guard let imageData = taskResponse?.0, let uiImage = UIImage(data: imageData) else { return } image = uiImage } guard let image = self.image else { return AnyView(placeholder()) } return AnyView(content(Image(uiImage: image))) } }

The only way I made the internal views (I and P types) to swap accordingly was to assign the image property, which had to be marked with the @State property wrapper, from inside the async block. Is this a safe practice from a threading/thread-safety perspective or do I have to implement it in some other way?

I don't think initiating URLSession every time the body of the View is rendered is a good idea. Maybe use onAppear on the new .task instead? — jnpdx
– jnpdx, Commented Jun 17, 2021 at 21:17
Yes, that's clear. I'd normally move this away completely since network operations don't really belong into the View. This was meant to be a minimal example. — Petr Palata
– Petr Palata, Commented Jun 17, 2021 at 21:19
Tasks will be cancelled when the view disappears. As @jnpdx mentioned, task is the new onAppear. — Helperbug
– Helperbug, Commented Jun 18, 2021 at 5:45
It’s best to let the URLSession do your caching via URLCache — malhal
– malhal, Commented Jan 1, 2022 at 12:52

malhal · Accepted Answer · 2023-04-09 11:36:03Z

4

Yes (but it should be done in a .task or .task(id:) modifier not directly in body itself).

You can safely mutate state properties from any thread.

https://developer.apple.com/documentation/swiftui/state

One of the reasons why you should try to use value types like structs instead of objects in Swift.

edited Apr 9, 2023 at 11:36

answered Oct 20, 2022 at 7:30

malhal

31.5k7 gold badges125 silver badges154 bronze badges

Sign up to request clarification or add additional context in comments.

4 Comments

Pogos Anesyan Over a year ago

Could you please explain in this case why should I use structs instead of objects in Swift ?

malhal Over a year ago

Apple cover that here developer.apple.com/documentation/swift/…

malhal Over a year ago

You also need to know about mutating func to use structs

Pogos Anesyan Over a year ago

I mean how in this case struct gives us the ability to change the state in the different thread (different from main)

Cristik · Accepted Answer · 2024-05-01 04:45:53Z

This answer is no longer relevant, please check the Malhal's post for an up-to-date answer.

It is not safe to update UI data, from another thread than the main one. And Swift's concurrency model makes no guarantees about the thread on which async code runs.

So the answer to your question is a big NO.

You will need to dispatch the property update on the main thread. And the main actor is the recommended way to do this.

Just add a new function for this

@MainActor func updateImage(to newImage: UIImage) { image = newImage }

, and call it from the async task:

await updateImage(to: uiImage)

According to Apple docs you can change a state var safely from any thread, see answer below.

Collectives™ on Stack Overflow

Is it safe to mutate @State variables from inside an async block in SwiftUI?

2 Answers 2

4 Comments

1 Comment

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

4 Comments

1 Comment

Linked

Related