Swift 6 concurrency

[dfsm]

Heya,

In Xcode26 there were ~150 warnings about Swift 6, Sendables, etc. The quick fix appeared to be tagging imports with @preconcurrency, but since I have access to this LLM, I had it resolve the warnings without resorting to deferral tactics.

Hopefully this saves a bunch of manual effort! I tested basic functionality after these changes and all seems well. Below is what Claude reckons. Claude can lie/be lazy tho, so don't trust everything it says...

---

Swift 6 Strict Concurrency Compliance

This PR updates the Awful.app codebase to fully comply with Swift 6's strict concurrency checking,
eliminating all concurrency-related warnings without using @preconcurrency workarounds.

Overview

Swift 6 introduces stricter concurrency checking to ensure thread safety and prevent data races. This PR
addresses all concurrency warnings by properly handling data that crosses concurrency boundaries,
particularly focusing on Core Data objects and non-Sendable types from the AwfulScraping module.

Key Changes

Sendable Conformance

• Made StarCategory and ThreadPage enums conform to Sendable protocol
• Created Sendable-safe info types (ThreadInfo, PostInfo, UserInfo, etc.) for passing data across
  concurrency boundaries

Core Data Object Handling

• Fixed all instances where NSManagedObject subclasses were being captured in @sendable closures
• Implemented consistent pattern of extracting objectID before closures and reconstructing objects inside
• Ensured proper context isolation for all Core Data operations

AwfulScraping Module Integration

• Addressed non-Sendable types from the AwfulScraping module by reparsing results inside closures
• Validates parsing outside closures for error handling, then reparses inside to avoid capturing
  non-Sendable types

ForumsClient Refactoring

• Created ForumsClient+Sendable.swift with Sendable-safe method alternatives
• Methods now accept primitive types (String IDs) instead of Core Data objects where appropriate
• Maintains backward compatibility while providing concurrency-safe alternatives

Approach

The solution follows these principles:

1. No @preconcurrency shortcuts - All warnings are properly resolved at their source
2. Minimal API disruption - Existing methods delegate to new Sendable-safe implementations
3. Consistent patterns - Uses the same approach throughout for similar problems
4. Type safety - Leverages Swift's type system to prevent concurrency issues at compile time

Testing

All changes have been validated to:

• Build successfully with Swift 6 strict concurrency checking enabled
• Maintain existing functionality without regression
• Properly render post content and handle all UI interactions

This PR ensures the codebase is ready for Swift 6 while maintaining thread safety and preventing potential
data races.

[nolanw]

I'm tempted to wait until Xcode 26 because it makes some swift concurrency bits easier to use. I don't think we'll have long to wait for the rc. does that sound ok?

[dfsm]

I'm tempted to wait until Xcode 26 because it makes some swift concurrency bits easier to use. I don't think we'll have long to wait for the rc. does that sound ok?

Yeah of course. If you just want to do the @preconcurrency thing, that's all good too. Just offering this as (I think) it's the "proper" way to resolve the warnings.

Hell, the rc could introduce even more warnings. I think I addressed some in an early beta and then even more showed up in a later beta

[nolanw]

Fair point. I was thinking of the “accessible concurrency” stuff. Default some targets to MainActor and go directly to whatever nonisolated means now.