Swift 6: complete concurrency checking #825

laevandus · 2025-05-07T12:08:11Z

🔗 Issue Links

Resolves: IOS-736

🎯 Goal

Set Swift version to 6 and implement complete concurrency checking

📝 Summary

Set Swift version to 6 in StreamChatSwiftUI and demo app (includes SWIFT_STRICT_CONCURRENCY = complete)
Add Sendable conformance to many types
Many protocols and types related to UI get @preconcurrency @MainActor requirement (e.g. view models)
Use StreamConcurrency.onMain for jumping on the main actor from controller delegates and completion handlers
Upgrade Nuke to version 12.8 (otherwise we can't compile with complete concurrency checking)
- LazyImage has breaking changes in Nuke (more testing for image scaling and gifs is needed)
Patch SwiftyGif for supporting complete concurrency checking (not beautiful)

🛠 Implementation

🎨 Showcase

🧪 Manual Testing Notes

Full manual regression testing round is needed.

☑️ Contributor Checklist

I have signed the Stream CLA (required)
This change should be manually QAed
Changelog is updated with client-facing changes
Changelog is updated with new localization keys
New code is covered by unit tests
Documentation has been updated in the docs-content repo

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj

… and completions

github-actions · 2025-05-07T12:20:30Z

	1 Warning
⚠️	Big PR

	1 Message
📖	There seems to be app changes but CHANGELOG wasn't modified. Please include an entry if the PR includes user-facing changes. You can find it at CHANGELOG.md.

Generated by 🚫 Danger

laevandus · 2025-05-07T12:51:37Z

Scripts/removePublicDeclarations.sh

-		replaceDeclaration ' Image?' ' NukeImage?' $f
-		replaceDeclaration ' Image(' ' NukeImage(' $f
-		replaceDeclaration 'struct Image:' 'struct NukeImage:' $f
-		replaceDeclaration 'extension Image {' 'extension NukeImage {' $f
-		replaceDeclaration 'Content == Image' 'Content == NukeImage' $f


Nuke was upgraded to 12.8 (supports Swift 6), some of the types are not there anymore

laevandus · 2025-05-07T13:02:49Z

Sources/StreamChatSwiftUI/Appearance.swift

-    static var `default`: Appearance = .init()
+    nonisolated(unsafe) static var `default`: Appearance = .init()


Appearance is a class in SwiftUI and its properties are accessible through InjectedValues.
@injected makes it impossible top make the Appearance itself @MainActor because @Injected(\.images) private var images can't ensure main actor isolation when a type/view X is created.
The other option would be to use a lock within Appearance to make sure everything is concurrency safe, but that feels like too much because the type itself is called from main anyway (if not mistakenly calling from background threads).

also fine to keep it like this, it anyway contains only UI stuff - shouldn't be called from a bg thread

laevandus · 2025-05-08T07:12:13Z

.github/workflows/smoke-checks.yml

@@ -66,7 +66,8 @@ jobs:
  build-xcode15:
    name: Build SDKs (Xcode 15)
    runs-on: macos-15
-    if: ${{ github.event.inputs.record_snapshots != 'true' }}
+    #if: ${{ github.event.inputs.record_snapshots != 'true' }}
+    if: false


Xcode 15 builds are going away, disabling it for now and a cleanup happens separately

laevandus · 2025-05-08T07:13:29Z

Sources/StreamChatSwiftUI/Appearance.swift

+    nonisolated(unsafe)
+    public static var localizationProvider: @Sendable(_ key: String, _ table: String) -> String = { key, table in
        Bundle.streamChatUI.localizedString(forKey: key, value: nil, table: table)
    }


Alternative could be making it @MainActor instead of opting out with nonisolated. But then all out generated L10n structs would need to be MainActor as well which will cause some troubles, since main actor isolation is not available everywhere where L10n is used. Probably fine to keep it unsafe for now.

this is fine

laevandus · 2025-05-09T10:18:37Z

DemoAppSwiftUI/ChannelHeader/ChooseChannelQueryView.swift

-    static let queryIdentifiers = ChannelListQueryIdentifier.allCases.sorted(using: KeyPathComparator(\.title))
+    static var queryIdentifiers: [ChannelListQueryIdentifier] {
+        ChannelListQueryIdentifier.allCases.sorted(by: { $0.title < $1.title })
+    }


It was giving Sendable related error which did not feel right. Just switched to another sorting method.

laevandus · 2025-05-09T10:19:46Z

DemoAppSwiftUI/LoginViewModel.swift

@@ -42,7 +42,7 @@ class LoginViewModel: ObservableObject {
                return
            }

-            DispatchQueue.main.async { [weak self] in
+            Task { @MainActor [weak self] in


DispatchQueue gives Sendable error for self

yes, we should use Task going forward

laevandus · 2025-05-09T10:22:30Z

Sources/StreamChatSwiftUI/ChatChannel/ChannelInfo/AddUsersViewModel.swift

@@ -6,7 +6,7 @@ import StreamChat
 import SwiftUI

 /// View model for the `AddUsersView`.
-class AddUsersViewModel: ObservableObject {
+@MainActor class AddUsersViewModel: ObservableObject {


Since view model factory is MainActor and view models are used from view, then it made more than sense to make all the view models main actor.

laevandus · 2025-05-09T10:23:52Z

Sources/StreamChatSwiftUI/ChatChannel/ChannelInfo/AddUsersViewModel.swift

-                guard let self = self else { return }
-                self.users = self.searchController.userArray
-                self.loadingNextUsers = false
+                MainActor.ensureIsolated { [weak self] in


Controllers do not ensure on the compilation level which actor is used. We can use any queue for controller completion handlers although the default is main. Therefore, we need to make sure that main is used. Applies to all the completion handlers and controller delegates.

laevandus · 2025-05-09T10:24:57Z

Sources/StreamChatSwiftUI/ChatChannel/ChannelInfo/ChatChannelInfoViewModel.swift

@@ -172,7 +172,7 @@ public class ChatChannelInfoViewModel: ObservableObject, ChatChannelControllerDe
        loadAdditionalUsers()
    }

-    public func leaveConversationTapped(completion: @escaping () -> Void) {
+    public func leaveConversationTapped(completion: @escaping @MainActor() -> Void) {


For avoiding actor isolation in the view. Better force main on the view model level.

laevandus · 2025-05-09T10:27:50Z

...ces/StreamChatSwiftUI/ChatChannel/Composer/Suggestions/Mentions/MentionsCommandHandler.swift

@@ -152,15 +152,16 @@ public struct MentionsCommandHandler: CommandHandler {

    private func searchAllUsers(for typingMention: String) -> Future<SuggestionInfo, Error> {
        Future { promise in
+            nonisolated(unsafe) let unsafePromise = promise


Promise is not sendable even when making SuggestionInfo sendable, added a unsafe check here for bypassing it.

we should probably refactor this to use async

Can happen in v5, currently the Future type gets exposed with public function:

public func showSuggestions( for command: ComposerCommand ) -> Future<SuggestionInfo, Error> { showMentionSuggestions( for: command.typingSuggestion.text, mentionRange: command.typingSuggestion.locationRange ) }

maybe we can use async/await under the hood, and just wrap the result in a Future?

anyway, low prio

laevandus · 2025-05-09T11:08:36Z

StreamChatSwiftUITests/Infrastructure/TestTools/ChatClient_Mock.swift

@@ -22,7 +22,15 @@ public extension ChatClient {
            config: config,
            workerBuilders: [],
            environment: .init(
-                apiClientBuilder: APIClient_Spy.init,
+                apiClientBuilder: {
+                    APIClient_Spy(


Sendable warning if not written out with all the arguments

laevandus · 2025-05-09T11:10:53Z

StreamChatSwiftUITests/Tests/StreamChatTestCase.swift

@@ -21,7 +21,7 @@ open class StreamChatTestCase: XCTestCase {

    public var streamChat: StreamChat?

-    override open func setUp() {
+    @MainActor override open func setUp() {


Many tests want to change main actor isolated types, therefore it is easier to require main actor in a single place

laevandus · 2025-05-09T11:11:21Z

StreamChatSwiftUITestsAppTests/Pages/MessageListPage.swift

@@ -371,7 +371,7 @@ class MessageListPage {

    enum ComposerMentions {
        static var cells: XCUIElementQuery {
-            app.scrollViews["CommandsContainerView"].otherElements.matching(NSPredicate(format: "identifier LIKE 'MessageAvatarView'"))
+            app.scrollViews["CommandsContainerView"].images.matching(NSPredicate(format: "identifier LIKE 'MessageAvatarView'"))


Nuke's LazyImage changes causes it

martinmitrevski

Few things we should discuss:

the usage of assumeIsolated
we still use preconcurrency in some VMs
some delegate methods are nonisolated

martinmitrevski · 2025-05-16T10:57:26Z

DemoAppSwiftUI/AppleMessageComposerView.swift

@@ -214,7 +214,7 @@ struct BlurredBackground: View {
 }

 struct HeightPreferenceKey: PreferenceKey {
-    static var defaultValue: CGFloat? = nil
+    static let defaultValue: CGFloat? = nil


isn't this causing issues somewhere?

PreferenceKey's protocol requires the default value to be get, therefore this is fine to be defined with let over mutable var (which causes concurrency errors).
Docs

martinmitrevski · 2025-05-16T10:59:56Z

DemoAppSwiftUI/ChannelHeader/NewChatViewModel.swift

            }
        }
    }

    // MARK: - ChatUserSearchControllerDelegate

-    func controller(
+    nonisolated func controller(


can we avoid this being nonisolated in the LLC?

nonisolated is required because I made the view model @MainActor which I feel like makes sense to have. Controllers have a design where I can set any queue to be the one used for delegate callbacks. In 99% of cases it is the default main queue (highly unlikely that many set their own queues). But because we support any queue for delegate callbacks, we can't make the delegate protocol @MainActor. We can't use @preconcurrency for the delegate conformance because then we would get runtime crash if anyone change the the default queue in the controller to be a background queue.
Ideally we would use our async-await state layer instead of delegates in the future, but that is out of scope.

Summary is that nonisolated can be avoided if view models are not @MainActor (I currenty changed them to be). That said, in the UIKit implementation view controllers are implementing delegates, so nonisolated is required there because UIViewController is @MainActor (similar situation). Similar issue with completion handlers where the calling thread can be any thread.

martinmitrevski · 2025-05-16T11:03:49Z

DemoAppSwiftUI/LoginViewModel.swift

@@ -42,7 +42,7 @@ class LoginViewModel: ObservableObject {
                return
            }

-            DispatchQueue.main.async { [weak self] in
+            Task { @MainActor [weak self] in


yes, we should use Task going forward

martinmitrevski · 2025-05-16T11:07:36Z

DemoAppSwiftUI/NotificationsHandler.swift

                if granted {
-                    DispatchQueue.main.async {
+                    Task { @MainActor in


good to test this part, I remember having crashes on video in the summer (probably it was Xcode bug, but still)

I got the same crash and the recommendation was to make it explicitly @sendable.

yes, but customers will also have this - probably we should mention it in an migration guide.

martinmitrevski · 2025-05-16T11:08:49Z

Sources/StreamChatSwiftUI/Appearance.swift

+    nonisolated(unsafe)
+    public static var localizationProvider: @Sendable(_ key: String, _ table: String) -> String = { key, table in
        Bundle.streamChatUI.localizedString(forKey: key, value: nil, table: table)
    }


this is fine

martinmitrevski · 2025-05-16T11:20:14Z

Sources/StreamChatSwiftUI/ChatChannel/ChannelInfo/ChatChannelInfoViewModel.swift

-                }
-                if newMembers.count > self.participants.count {
-                    self.participants = newMembers
+            MainActor.ensureIsolated { [weak self] in


this crashes if it's not on the main actor, right? Do we really need that?

It is a custom addition (maybe we should rename it to be more clear about it) which makes sure the closure runs on the main thread. Note that one can set any queue to be the one used for completion handers (default is main). This custom addition just checks if we are currently on the main, if yes, just call the closure, otherwise jump on the main thread (since UI updates and MainActor view models require main).

The difference between:
Task { @MainActor in and MainActor.ensureIsolated is that the latter is quicker.

DispatchQueue.global().async { print("Simulate API calls and DB updates") DispatchQueue.main.async { print(Thread.isMainThread) Task { @MainActor in print("Task main actor") } MainActor.ensureIsolated { print("Ensure isolated") } } }

If this snippet runs, ensure isolated is called first.

I did some micro benchmarking just for fun and the difference is insignificant: we are talking about 1-10 microseconds. Therefore, I guess it makes sense to simplify this and get rid of the custom ensureIsolated.

I renamed the custom addition to StreamConcurrency.onMain. I tried to get rid of it, but loads of unit-tests will break because using a Task introduces slight delay.

martinmitrevski · 2025-05-16T11:27:37Z

...ces/StreamChatSwiftUI/ChatChannel/Composer/Suggestions/Mentions/MentionsCommandHandler.swift

@@ -152,15 +152,16 @@ public struct MentionsCommandHandler: CommandHandler {

    private func searchAllUsers(for typingMention: String) -> Future<SuggestionInfo, Error> {
        Future { promise in
+            nonisolated(unsafe) let unsafePromise = promise


we should probably refactor this to use async

martinmitrevski · 2025-05-16T11:29:21Z

Sources/StreamChatSwiftUI/ChatChannel/MessageList/GiphyAttachmentView.swift

@@ -103,7 +103,12 @@ struct LazyGiphyView: View {
    var body: some View {
        LazyImage(imageURL: source) { state in
            if let imageContainer = state.imageContainer {
-                NukeImage(imageContainer)
+                if imageContainer.type == .gif {


why do we change this?

Nuke dropped their image type and gif rendering support in Nuke 12.0 (migration guide). This is their recommendation how to handle gif rendering.

martinmitrevski · 2025-05-16T11:31:01Z

Sources/StreamChatSwiftUI/ChatChannel/MessageList/GiphyAttachmentView.swift

@@ -119,3 +124,18 @@ struct LazyGiphyView: View {
        .aspectRatio(contentMode: .fit)
    }
 }
+
+private struct AnimatedGifView: UIViewRepresentable {


did you take this from Nuke or is it a new implementation?

This I took from SwiftyGif's documentation as a recommended way for rendering gifs in SwiftUI. Not happy that I needed to touch gif rendering, but it is what it is.

martinmitrevski · 2025-05-16T11:41:44Z

Sources/StreamChatSwiftUI/DefaultViewFactory.swift

+        onDismiss: @escaping @MainActor() -> Void,
+        onError: @escaping @MainActor(Error) -> Void


ouch, that's tricky, can we avoid it?

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj

laevandus · 2025-05-30T06:48:55Z

Sources/StreamChatSwiftUI/ChatChannel/Reactions/MessageActions/DefaultMessageActions.swift

+        nonisolated(unsafe) let unsafeOnError = onError
+        nonisolated(unsafe) let unsafeOnFinish = onFinish


Opting out for avoiding breaking changes in the public API (can be fixed properly in v5)

# Conflicts: # .github/workflows/smoke-checks.yml # StreamChatSwiftUI.xcodeproj/project.pbxproj

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj # StreamChatSwiftUITests/Tests/ChatChannel/ChatChannelViewModel_Tests.swift

sonarqubecloud · 2025-07-07T10:34:47Z

Quality Gate failed

Failed conditions
42.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

martinmitrevski

Third-party dependencies have the most changes here - we should thoroughly test it. Performance impact is also something we should check.

martinmitrevski · 2025-07-07T12:45:22Z

DemoAppSwiftUI/NotificationsHandler.swift

                if granted {
-                    DispatchQueue.main.async {
+                    Task { @MainActor in


yes, but customers will also have this - probably we should mention it in an migration guide.

martinmitrevski · 2025-07-07T12:47:28Z

Sources/StreamChatSwiftUI/ChatChannel/ChannelInfo/ChatChannelInfoViewModel.swift

@@ -7,7 +7,7 @@ import StreamChat
 import SwiftUI

 // View model for the `ChatChannelInfoView`.
-public class ChatChannelInfoViewModel: ObservableObject, ChatChannelControllerDelegate {
+@preconcurrency @MainActor public class ChatChannelInfoViewModel: ObservableObject, ChatChannelControllerDelegate {


ok, makes sense - we should also test this case directly - to see if there would be any issues.

martinmitrevski · 2025-07-07T12:50:52Z

Sources/StreamChatSwiftUI/ChatChannel/ChatChannelViewModel.swift

-                        self?.scrolledId = toJumpId
-                        self?.loadingMessagesAround = false
+                    DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) { [weak self, toJumpId] in
+                        StreamConcurrency.onMain { [weak self] in


isn't it on main here already?

martinmitrevski · 2025-07-07T13:14:39Z

...ces/StreamChatSwiftUI/ChatChannel/Composer/Suggestions/Mentions/MentionsCommandHandler.swift

@@ -152,15 +152,16 @@ public struct MentionsCommandHandler: CommandHandler {

    private func searchAllUsers(for typingMention: String) -> Future<SuggestionInfo, Error> {
        Future { promise in
+            nonisolated(unsafe) let unsafePromise = promise


maybe we can use async/await under the hood, and just wrap the result in a Future?

martinmitrevski · 2025-07-07T13:15:03Z

...ces/StreamChatSwiftUI/ChatChannel/Composer/Suggestions/Mentions/MentionsCommandHandler.swift

@@ -152,15 +152,16 @@ public struct MentionsCommandHandler: CommandHandler {

    private func searchAllUsers(for typingMention: String) -> Future<SuggestionInfo, Error> {
        Future { promise in
+            nonisolated(unsafe) let unsafePromise = promise


anyway, low prio

martinmitrevski · 2025-07-07T13:57:21Z

Sources/StreamChatSwiftUI/Utils/StreamConcurrency.swift

+    ///
+    /// - Important: It is safe to call from any thread. It does not deadlock if we are already on the main thread.
+    /// - Important: Prefer Task { @MainActor if possible.
+    static func onMain<T>(_ action: @MainActor @Sendable() throws -> T) rethrows -> T where T: Sendable {


why don't we make the one from LLC public and use only that one?

martinmitrevski · 2025-07-07T14:01:46Z

Sources/StreamChatSwiftUI/DefaultViewFactory.swift

@@ -44,8 +44,8 @@ extension ViewFactory {
    public func makeMoreChannelActionsView(
        for channel: ChatChannel,
        swipedChannelId: Binding<String?>,
-        onDismiss: @escaping () -> Void,
-        onError: @escaping (Error) -> Void
+        onDismiss: @escaping @MainActor() -> Void,


this would be a breaking change, right?

laevandus added 10 commits March 28, 2025 11:40

Use SWIFT_STRICT_CONCURRENCY complete with Swift 5

ddf78cc

Merge branch 'develop' into swift-6

b73c9c5

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj

Make view models MainActor and fix isolation for controller delegates…

2f64d75

… and completions

Set Swift version to 6

87292cf

Constraint and UIDevice errors

ab7356d

Try MainActor Appearance and non-isolated injected values

391b156

Upgrade Nuke to 12.8

26dd6aa

Fixed all the errors

ef3bbc0

Fix last warnings

bb0ed90

Fix Swift 6 warnings in tests

87fcb5a

laevandus requested a review from a team as a code owner May 7, 2025 12:08

laevandus marked this pull request as draft May 7, 2025 12:08

Disable building with Xcode 15

994196f

Fix tests

4c94da4

laevandus commented May 7, 2025

View reviewed changes

laevandus commented May 8, 2025

View reviewed changes

laevandus added 5 commits May 8, 2025 10:29

Fix tests

6b78288

Merge branch 'develop' into swift-6

8eae0dd

Fix build warnings in the demo app

6e1e8c9

Fix avatar sizes with LazyImage

f10725c

Fix UI test where LazyImage now is treated as images, not otherElements

c0b9111

laevandus commented May 9, 2025

View reviewed changes

laevandus added 3 commits May 9, 2025 14:25

Tidy here and there

79ef1c1

Use Swift 6 in the demo app

e28503d

Merge branch 'develop' into swift-6

f8d9504

laevandus added 🤞 Ready for QA ⏫ Dependencies Update Pull requests that update a dependency file 🪧 Demo App An Issue or PR related to the Demo App ✅ Feature An issue or PR related to a feature labels May 9, 2025

laevandus added 2 commits May 9, 2025 15:12

Fix runtime asserts

fa2872a

Fix Gif support which LazyImage dropped

4b305c5

martinmitrevski reviewed May 16, 2025

View reviewed changes

laevandus removed the 🤞 Ready for QA label May 22, 2025

laevandus added 2 commits May 22, 2025 13:43

Merge branch 'develop' into swift-6

1ab09e2

Do not change view factory method signatures (opt-out from checking)

1170a52

laevandus force-pushed the swift-6 branch from 03e31dd to 1170a52 Compare May 23, 2025 08:03

laevandus added 2 commits May 23, 2025 11:40

Rename MainActor.ensureIsolated to StreamConcurrency.onMain

7a0cfe3

Fix giphy image lookup since it is image directly (changes in Nuke)

7d0237c

laevandus marked this pull request as ready for review May 23, 2025 10:07

laevandus added 3 commits May 23, 2025 14:57

Remove assumeIsolated because Swift 6 compiler does not require it

9769ff4

Merge branch 'develop' into swift-6

365f9f6

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj

Remove @mainactor from message actions for avoiding breaking changes

9087e48

laevandus commented May 30, 2025

View reviewed changes

laevandus added 3 commits June 5, 2025 09:29

Merge branch 'develop' into swift-6

55d666c

# Conflicts: # .github/workflows/smoke-checks.yml # StreamChatSwiftUI.xcodeproj/project.pbxproj

Merge branch 'develop' into swift-6

db9e461

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj

Merge branch 'develop' into swift-6

ad036e8

# Conflicts: # StreamChatSwiftUI.xcodeproj/project.pbxproj # StreamChatSwiftUITests/Tests/ChatChannel/ChatChannelViewModel_Tests.swift

martinmitrevski reviewed Jul 7, 2025

View reviewed changes

		static var `default`: Appearance = .init()
		nonisolated(unsafe) static var `default`: Appearance = .init()

		onDismiss: @escaping @MainActor() -> Void,
		onError: @escaping @MainActor(Error) -> Void

		nonisolated(unsafe) let unsafeOnError = onError
		nonisolated(unsafe) let unsafeOnFinish = onFinish

Swift 6: complete concurrency checking #825

Are you sure you want to change the base?

Swift 6: complete concurrency checking #825

Uh oh!

Conversation

laevandus commented May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Issue Links

🎯 Goal

📝 Summary

🛠 Implementation

🎨 Showcase

🧪 Manual Testing Notes

☑️ Contributor Checklist

Uh oh!

github-actions bot commented May 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laevandus May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laevandus May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinmitrevski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laevandus commented May 7, 2025 •

edited

Loading

laevandus May 7, 2025 •

edited

Loading

laevandus May 8, 2025 •

edited

Loading

laevandus May 22, 2025 •

edited

Loading