Split SwiftUI support into separate module

[dhavalshreyas]

While bumping up Xcode version within Square, some ObjC-only targets are bumping into some issues during linking.

Specific error we're seeing:

ld: warning: Could not find or use auto-linked library 'swiftCoreMIDI'
Undefined symbols for architecture x86_64:
  "_swift_getOpaqueTypeConformance", referenced from:
      associated type witness table accessor for Body : SwiftUI.View in WorkflowUI.WorkflowView<A, B> : SwiftUI.View in WorkflowUI in WorkflowUI(WorkflowView.o)
      associated type witness table accessor for Body : SwiftUI.View in WorkflowUI.(RootView in _03A9777E4AF05597CE6B37108BFDC731)<A> : SwiftUI.View in WorkflowUI in WorkflowUI(WorkflowView.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

While we can dig into finding out the root cause and fix it, I thought it's better to move SwiftUI support into a different module.

[dnkoutso]

LGTM.

Probably get one more approval from core maintainers also!

[justinseanmartin]

Rather than checking in an xcodeproj, would using be pod gen work here to reduce the boilerplate?

[dhavalshreyas]

Yes! I've created a new issue to track this: #930

This one is similar to the other sample apps in the repo.

[justinseanmartin]

No blockers from my perspective, just some style feedback.

[timdonnelly]

Is this a positive change for the library itself? Do we actually want this code to live in a separate module?

[dhavalshreyas]

Is this a positive change for the library itself? Do we actually want this code to live in a separate module?

@timdonnelly: Any reason it shouldn't? The way you've written it, it looks like there's no dependency on WorkflowUI at all. So we'll just need to use WorkflowSwiftUI instead of WorkflowUI for SwiftUI projects. I think this is pretty cool.

[timdonnelly]

Is this a positive change for the library itself? Do we actually want this code to live in a separate module?

@timdonnelly: Any reason it shouldn't? The way you've written it, it looks like there's no dependency on WorkflowUI at all. So we'll just need to use WorkflowSwiftUI instead of WorkflowUI for SwiftUI projects. I think this is pretty cool.

I don't have a strong reason that it shouldn't/couldn't at a quick glance (and the software would certainly work in either case) – but module boundaries are part of the projects's API, and I'd like to always make API decisions with the end consumer in mind. Even with UIKit+SwiftUI support, the library is pretty small – I intentionally added SwiftUI support within the same module to keep the structure simple: it's the library with the UI bindings. That could certainly change, and in that case it might make sense to list the UI architecture in each module name (WorkflowSwiftUI + WorkflowUIKit or something).

This seems to be a case where Square's internal build system is failing on a simple language feature (availability checks), and that bug is driving a design decision.

• There is nothing clever going on in the code here. Availability checks are a common language feature, so failures here in the build system of a project that I was maintaining would make me very nervous.
• Changing a module's structure to work around the issue is an implicit decision that some class of availability checking is now disallowed/unsupported within the codebase going forward.
• A build system that blocks developers from using common language features seems like it will impair development on an ongoing basis (so again, I'd be pretty worried).

The actual changes look ok, and I'm totally ok merging. I just want to make sure that we do so with the compromises called out.

[dhavalshreyas]

Had an offline chat with @timdonnelly.

TLDR; Even though the change itself is triggered by a build system issue, moving the SwiftUI support to a different library is still the right thing to do. The WorkflowSwiftUI system and the WorkflowUI system do not work well together. You can choose to use one or the other, but you can't mix them both. Considering this, having these two be two separate libraries makes more sense.

[kyleve]

I believe we can resolve the underlying issue here by updating the swiftUI check to be:

#if DEBUG && canImport(SwiftUI) && !arch(i386)