When Your Research Goes Off-Track
One of the biggest frustrations in research is realizing - after investing quite some effort - that you have gone off-track…
Lately, I’ve been exploring BSP (Build Server Protocol) and how to make VSCode work seamlessly with iOS projects. If you read my previous post, you may know that my motivation for looking into BSP was test discovery. Extracting tests in non-SPM projects is not straightforward. Here, non-SPM refers to projects managed by the traditional xcworkspace
/xcodeproj
structures.
I was hoping to bridge that gap with a custom BSP server, alongside SourceKit-LSP.
The First Wrong Turn
My very first question was: what language should I use for this BSP server? Should it be Python, Swift, or Ruby? I “randomly” picked one and later regretted my choice.
Well, the main challenge here wasn’t working with the LSP (language server protocol), but working with Xcode projects. While Ruby and Swift communities provide solid 3rd-party libraries for handling Xcode projects - such as CocoaPods/Xcodeproj and tuist/XcodeProj, Python’s equivalent is immature and incompatible with recent Xcode versions… By now, you can probably guess which one I chose at first 😅.
Losing Focus
After making some progress, I went the extra mile with my original goal and started tackling a broader challenge: making VSCode work with Xcode-managed projects.
This was my big mistake that I confused the research objectives. I had blurred the lines between two problems: (1) test discovery and (2) Xcode-projects support in VSCode.
Because I hadn’t clearly wrapped up the first problem before diving into the second, I unconsciously applied the same approach to both. This does not quite make sense as they are two different problems.
…
When integrating my custom BSP server, it didn’t work out in VSCode. Was it because of the BSP server, or the vscode-swift extension, or both? While debugging the extension, I realized that it is heavily SPM-centric. Then, I came across this open issue and discovered another extension, SweetPad, which does supports Xcode projects.
I should have known this earlier.
It would have saved me a lot of effort.
That’s when I hit me. I had gone off-track.
Lessons Learned
This mistake happened because I didn’t properly define the PROBLEM STATEMENT before seeking solutions. A well-defined problem should lead to clearer goals, better direction, and smarter task prioritization.
You better spend more time and effort upfront to ensure you’re on the right track, rather than rushing to solutions and ending up tackling a different problem. Always ask yourself what problem you’re solving in oder not to lose focus.
Like what you’re reading? Buy me a coffee and keep me going!
Subscribe to this substack
to stay updated with the latest content