I've enabled Swift's strict concurrency checking (SWIFT_STRICT_CONCURRENCY = complete) on one of my projects and am now getting these warnings:
SwiftUI.PreviewProvider:4:34: warning: main actor-isolated static property '_previews' cannot be used to satisfy nonisolated protocol requirement
@MainActor public static var _previews: Any { get }
^
SwiftUI._PreviewProvider:3:16: note: '_previews' declared here
static var _previews: Any { get }
^
SwiftUI.PreviewProvider:5:34: warning: main actor-isolated static property '_platform' cannot be used to satisfy nonisolated protocol requirement
@MainActor public static var _platform: PreviewPlatform? { get }
^
SwiftUI._PreviewProvider:4:16: note: '_platform' declared here
static var _platform: PreviewPlatform? { get }
^
Is this an omission on SwiftUI's part, or can it be somehow fixed in my code? (I have a zero warnings policy in all my projects so would like to know what to do with this.)
I see these too, seems like an issue within SwiftUI itself. The use of _platform is either an explicit internal property or a property wrapper around an internal platform variable, as even Sendable wrappers don't properly convey that conformance to the generated properties.
I think this is a known bug, but this will work around the issue if the warnings bug you. The @preconcurrency trick doesn't work since this is autogenerated code (I think) that isn't imported.
struct StrictConcurrencyWorkaroundView_Previews: PreviewProvider {
nonisolated static var _previews: Any { previews }
nonisolated static var previews: some View {
Text("Hello World!")
}
}
#if DEBUG
extension PreviewProvider {
nonisolated static var _platform: PreviewPlatform? { nil }
}
#endif
You will have trouble if you need to use something like @State in the preview since property wrappers don't work with nonisolated, but generally you can avoid that in previews.
I tried some other methods, but the auto-generated code and magic Xcode behavior make it weird. I believe they are auto-generating type erasure for an internal detail. Hopefully Apple will at least put a workaround in Xcode to ignore warnings for these symbols if they don't plan to fix it soon.
Just remember to delete this workaround when Apple fixes it.