[xcodeproj] IDE issues with test projects / xcodeproj

[jerrymarino]

I'm working to add a new way to speed up rules_ios builds that use frameworks, AKA virtual frameworks ( #277 ). On the Xcode side hitting a few hiccups with test projects today. I've attempted to get a baseline of what is already working in rules_ios but, most of the example projects are broken from the IDE's perspective. This includes debugging, jump to definition, and other features.

To reproduce:

git clone git@github.com:bazel-ios/rules_ios.git
cd rules_ios
bazel run tests/ios/xcodeproj:Test-Imports-App-Project
open tests/ios/xcodeproj/Test-Imports-App-Project.xcodeproj

I've noticed that rules_ios requires a build to copy some files into derived data. I tried doing a build of the app in the test project TestImports-App inside of Xcode as well.

Debugger

1. Set a breakpoint inside of the main file
2. Run the program
3. observe that breakpoints don't resolve - see attached screenshot

Source editor

1. Open the file empty.swift
2. Navigate to the interface of a symbol from "SomeFramework"
3. observe it navigating to a generated location

[gyfelton]

I think this is a known issue: we did not do some treatment that we do in downstream project that enabled debugging in sample projects. (specifying search paths in build settings etc.)
One thing to try is to manually set things under build setting under xcode such as framework search paths and you might get debugger running again.

[jerrymarino]

Yep it looks like there's a few issues in the samples causing both indexing and debugging to not work.

That said, I think there's a few issues to or next steps to break out:

1. getting the examples working so devs can iterate on features in a small use caes
2. levering the examples to use as integration test cases
3. increasing the coverage on IDE indexing in general
4. ensuring that the incantation of the downstream project isn't busted

For me, I filed this issue less around 2, 3, 4, and more on 1. As a maintainer, It was hard to come up with a baseline for what is and what isn't working then make changes to it. XCHammer has a nice methodology and extensive test suite for this by evaluating compiler invocations in a build. Pt 4 is more difficult but definitely achievable depending on how the test is structured