As of Xcode 11.4.1, there seems to be bug where using the canvas' "Debug Preview" function on a PreviewProvider inside of a framework target causes a "Could not attach to pid" error (please confirm that its not just my Xcode).
I wonder if people have a good flow for debugging TCA submodules. Not having to build the full app is one of the selling points of modularization (I believe @mbrandonw talked about this somewhere but now I cant find it). But I find developing without a debug console very inconvenient.
While I've had issues with frameworks and previews in earlier Xcode versions, I'm able to use them for framework views these days. As an example, I just opened ComposableArchitecture.xcworkspace, switched the build scheme to LoginSwiftUI, and was able to debug the preview in LoginSwiftView.swift.
A few things we've noticed, though:
Previews in general appear to build way more than is necessary for a given view. I think I read somewhere that there may be ways to tweak this with custom build schemes, but I forget where...
On-device previews do not yet support frameworks and return the following error:
@stephencelis Lucky you , I cant do the same. Cant even do it in a vanilla project, so its not CA related. I only asked here since CA and modularity kind of go together.
To be clear I can "Live Preview" but cant "Debug Preview", always get:
Could not attach to pid : “6490”
Domain: IDEDebugSessionErrorDomain
Code: 3
Failure Reason: Error 1
User Info: {
DVTRadarComponentKey = 855031;
RawLLDBErrorMessage = "Error 1";
}
--
System Information
macOS Version 10.15.4 (Build 19E287)
Xcode 11.4.1 (16137)
I tried all the usual cleans and resets. I will close this and stop using frameworks in my project (sigh).
Ah right. I think this is just the current state of Xcode previews and is definitely worth filing feedback for (if you haven't already).
I think that having a live preview is good enough to keep using frameworks. And whenever you need to debug you can do so from a preview provider in the main app target. Not ideal, but perhaps a good-enough workaround, and similar to workarounds we've employed for playground-driven development in the past.