SupabaseClient.execute()` fails to compile inside `@MainActor`

[adrienyvon699]

🐞 Bug Report — SupabaseClient.execute() fails to compile inside @MainActor context even when the model is Sendable

Package	supabase-swift
Version	2.5.1
Swift	6.2
Platform / SDK	iOS 26 (device & simulator)
Build system	Swift Package Manager

---

1 · Issue summary

Invoking:

let purpose: SitePurpose = try await supabase
  .from(\"site_purpose\")
  .select()
  .execute()   // ← compile-time error
  .value

inside a @MainActor context fails to compile:

Main actor-isolated conformance of 'SitePurpose' to 'Decodable'
cannot satisfy conformance requirement for a 'Sendable' type parameter

This occurs even when SitePurpose explicitly conforms to Sendable.

---

2 · Minimal reproducible example

import Supabase
import Foundation

struct SitePurpose: Decodable, Sendable {   // ✅ Sendable
    let id: String
    let label: String
}

@MainActor                                   // ← actor isolation
final class PurposeVM: ObservableObject {
    func fetch() async {
        
        let purpose: SitePurpose = try! await supabase
            .from(\"site_purpose\")
            .select()
            .execute() // ❌ compiler error here
            .value
        print(purpose)
    }
}

---

3 · Analysis

• SupabaseClient is implemented as an actor.
• Calling an actor method from another actor (@MainActor) requires the generic
  return type to be Sendable and non-isolated.
• Even with SitePurpose : Sendable, the compiler rejects the call, suggesting
  an implicit extra constraint in the library.

---

4 · Workarounds

Workaround	Drawback
Wrap call in Task.detached { … }	Verbose; hides intent, did not work
Move fetch logic to a non-actor service	Forces architectural change, did not work
Fetch raw JSON then decode manually	Loses execute<T> convenience

---

5 · Expected behaviour

execute() should compile inside @MainActor when the model conforms to both
Decodable and Sendable.
If the additional constraint is necessary, it should be explicit in the API so
the compiler produces a clear error.

---

6 · Environment details

swift --version
# Swift version 6.2

# Package version
supabase-swift 2.5.1 via SPM

---

Thanks 🙏

Happy to test any patch or beta branch—just ping me.

[grdsdev]

Hey, I first thought this was something missing in the lib, but I think that is a Xcode Beta bug, which Xcode version are you using?

I remember testing this on Xcode 26 Beta 1, and it worked fine, but now I'm also getting that error in Beta 2.

[adrienyvon699]

Hey, I first thought this was something missing in the lib, but I think that is a Xcode Beta bug, which Xcode version are you using?

I remember testing this on Xcode 26 Beta 1, and it worked fine, but now I'm also getting that error in Beta 2.

Hello and thanks for getting back to me, I'm actually on Beta 1 build 17A5241e.
But since you have the issue on Beta 2 we can probably assume that Xcode 26 is breaking things regarding that.

[henribredt]

Experiencing the same! Xcode 26 Beta 2

[barthansiva]

I encountered the same issue with Xcode 26 Beta 4. What is the recommended workaround?

[grdsdev]

Hello,

After further investigation, I have confirmed that this error occurs when the Default Actor Isolation setting is configured to MainActor in the Xcode project settings. This setting is the default value for new projects created using Xcode 26.

A workaround for this issue is to set the Default Actor Isolation to nonisolated. However, I have not yet been able to determine why Supabase breaks with this configuration.

I am still investigating the concurrency changes introduced in Xcode 26. If anyone has any insights into this matter, please do not hesitate to contact me.

Thank you.

[grdsdev]

In my recent tests, I discovered that to maintain the Default Actor Isolation as MainActor, it is necessary to explicitly define the decodable type as nonisolated, as shown below:

nonisolated struct SitePurpose: Decodable {
  let id: String
  let label: String
}

For further information, please refer to the issue swiftlang/swift#82249, which indicates that this appears to be a Swift bug.