@mattiem I know you love concurrency questions, so, is there a good way to access UIColors from a background thread? I think that has to be on the main thread, right?

I have some code that picks a random UIColor and gets its hex value that was crashing. I'm guessing that it's because it's sometimes called from a background thread, but it's hard to reproduce.

@agarrharr hmm UIColor is Sendable so should be fine. Any more details? Is this a subclass by any chance?
@mattiem Ok, so it may be unrelated to Concurrency. It's an extension of Color. It's in a local Swift 5 spm package, but my app is on Swift 6 language mode. The crashes all say things like SIGABRT, EXC_BREAKPOINT, or EXC_BAD_ACCESS
@mattiem and line 32 is the first line of the function
@agarrharr do you have MainActor default enabled?
@mattiem No, I have "Approachable Concurrency = No", "Default Actor Isolation = nonisolated" and "Strict Concurrency Checking = Complete"
@agarrharr ok then I think we need more context. Can you expand the frames, and also show more of that code?
@mattiem Thanks for even looking into this. Here is the crash stack trace and all of the functions it mentions.

@agarrharr ok so this is not what I originally thought at all.

That last file with the warning looks potentially suspect. Do you know what’s going on there?

@mattiem not really... but that function isn't a part of the stack trace. DevicesClient is a dependency made with swift-dependencies and it's in a local spm package that is on Swift 5 because I haven't been able to make my Bluetooth code compile with Swift 6 and it's in the same package (different library in the same package)
@agarrharr to me, that crash looks like regular old heap corruption of some kind. Will definitely not always be in traces, and might cause a variety of different kinds of crashes, including none at all. And that’s very easy to do with data races.
@mattiem Makes sense. Well, thanks for digging into it with me!