fix: make watch targets runnable to fix schemes in Xcode 12

[thedavidharris]

Short description 📝

Watch schemes and watch extension schemes were not buildable as generated in Xcode 12

Solution 📦

This marks these targets as "runnable" which properly generates the BuildableProductRunnable instead of MacroExpansion portion of the target

I'm admittedly unsure if there are any other side effects of this. WatchExtenstion targets can't be "run" standalone still, but this seems necessary and mirrors the Xcode defaults from what I can tell.

[kwridan]

Thanks for adding this @thedavidharris!

[kwridan]

I believe it's only the watch app that is runnable, the extension is run within it - attempting to run the extension on its own will yield an error.

We have a fixture you can test this on fixtures/ios_app_with_watchapp2

[thedavidharris]

This is correct, but if you don't have the watch2Extension as runnable, you can't even build it targeting the watch simulator, so I think you have to mark it as runnable which is what XCode seems to do if you just create a watch app directly there, although I might need some help verifying that someone else is also seeing this. This is the one that confused me.

[thedavidharris]

Yeah did check on it, if you just create a new extension and add the extension scheme, this is what you get. It's not actually runnable in the sense you could attach it, but it needs this to build. Otherwise with the MacroExpansion it shows "My Mac" as the target and totally freezes Xcode.

That said, it does get a little weird with the schemes list, and does adjust the -Project schemes (cc @fortmarek) as this will now start to clearly show -iOS and -watchOS schemes. I think this is more correct in totality.

In general it looks like there are some overall differences between the way Tuist is generating schemes and the way they are being generated if you just add the project to Xcode for watch targets, but watch targets are weird and painful so will take me a bit to go through them.

[fortmarek]

Thanks for the heads-up @thedavidharris! I'll make sure to add a watchOS app to the fixture the project schemes are tested on, so we can be sure everything works correctly (and fix it if it doesn't currently)

[thedavidharris]

@fortmarek if you check out this PR and just look at the fixtures/ios_app_with_watchapp2 from before or after you should see the difference.

watchOS doesn't have XCTest, so overall not too big of a deal, but it does generate it "correctly" now since the scheme is parsable by XCode again

[kwridan]

Ah missed that bit, thanks for clarifying @thedavidharris

I found a solution to this, instead of marking the extensions as runnable we can update the AutogeneratedSchemeProjectMapper to provide the watch app as the runnable for the watch extension. There is already similar logic to deal with this for other extensions.

• runnableExecutable can be updated to include a new case for .watch2Extension which would search for a host watch app to return

     private func hostWatchAppTargetReferences(for target: Target,
                                         project: Project) -> [TargetReference]
    {
        project.targets
            .filter { $0.product == .watch2App && $0.dependencies.contains(.target(name: target.name)) }
            .sorted(by: { $0.name < $1.name })
            .map { TargetReference(projectPath: project.path, name: $0.name) }
    }

There is an existing method to search for hostApps but that seems to be geared towards searching for test hosts which watch apps don't qualify for.

[thedavidharris]

Ah awesome: that seems to line up with Xcode defaults too, where it doesn't really create the xcscheme. You can add it in their GUI but then it doesn't work, gives you that error.

[thedavidharris]

@kwridan done, thanks for the heads up!

[kwridan]

Thanks @thedavidharris