Bazel: validate rules_xcodeproj support against large real-world iOS projects

[obj-p]

Goal

Make sure PreviewsMCP's Bazel support (Sources/PreviewsCore/BazelBuildSystem.swift) works against large, real-world rules_xcodeproj projects, not just our examples/bazel fixture. These are public, clonable repos we can use as integration targets and regression cases.

Today BazelBuildSystem detects a Bazel root via MODULE.bazel/WORKSPACE, finds the owning swift_library via rdeps, queries module_name, builds, and locates the .swiftmodule via cquery --output=files. None of that is exercised against a monorepo-scale project. The repos below stress package layout, module naming, focused/unfocused targets, and resource-bundle handling in ways our fixture does not.

Candidate projects (public, xcodeproj(...) confirmed)

Repo	Stars	Apple surface	rules_xcodeproj evidence
TelegramMessenger/Telegram-iOS	~8.6k	Full iOS app (UIKit/AsyncDisplayKit)	MODULE.bazel bazel_dep(name = "rules_xcodeproj"); Telegram/BUILD xcodeproj(name = "Telegram_xcodeproj")
Snapchat/Valdi	~16.4k	Cross-platform native UI framework	valdi/bzl_project/BUILD.bazel multiple xcodeproj(...); MODULE.bazel
maplibre/maplibre-native	~2k	iOS + macOS map SDK	platform/ios/BUILD.bazel & platform/macos/BUILD.bazel load @rules_xcodeproj//xcodeproj:defs.bzl, xcodeproj(...)
envoyproxy/envoy	~28k	mobile/ iOS client lib	mobile/BUILD loads @com_github_buildbuddy_io_rules_xcodeproj//..., xcodeproj(...) (older WORKSPACE name)
AgentsMesh/AgentsMesh	~2.2k	Native iOS app (SwiftUI + TCA)	build_defs/ios/ios_product.bzl xcodeproj(...). NOTE: uses custom macros over rules_xcodeproj; verify before relying on it.

Notes:

• envoy-mobile is superseded — it moved into the envoyproxy/envoy monorepo under mobile/. Target envoy instead.
• Most big adopters (Lyft, Reddit, Pinterest, Tinder, Spotify, Cash App, Slack, Robinhood) keep their iOS apps in private repos, so they are not clonable.
• For minimal repros: the rules_xcodeproj repo's own examples/integration/* apps, and mattrobmattrob/bazel-ios-swiftui-template.

Known preview fragility in rules_xcodeproj (relevant to our JIT path)

The named repos have no public "previews broken" issues (and several aren't SwiftUI apps), but rules_xcodeproj itself has open, actively-tracked preview bugs — several directly adjacent to our JIT executor work:

• #3189 — previews fail in the ruleset's own example (Xcode 16 / Bazel 8.2.1): CouldNotParseLinkCommandLine → FailedParsingMachObjectFile. Logs show run mode "JIT Executor."
• #3201 — Preview App can't find static libs at link time; SwiftUI Preview blocks standard swiftc stub injection, "necessitating an entirely new xctoolchain."
• #2977 — SPM resource-bundle deps crash in preview (Bundle.module assertion / rspm_resource_bundle_accessor). Relevant to the collectSourceFiles resource-bundle gap already noted in BazelBuildSystem.swift.
• #2915 — Xcode Previews fail for macos_*_framework top-level targets.

Mechanism worth encoding in our support matrix: rules_xcodeproj uses focused targets. To preview a view in library L, L must be focused and merged into a focused top-level target. Unfocused libraries are built by Bazel as opaque prebuilt artifacts, and a target reduced to a CompileStub.m shell cannot host previews. The legacy build_mode = "xcode" (BwX) path was removed in late 2023; everything is Build-with-Bazel now, so previews must work through that path.

Suggested scope

1. Clone Telegram-iOS, Valdi, and maplibre-native; run our Bazel detection + build pipeline against a representative #Preview in each. Record where findOwningTarget / queryModuleName / findCompilerFlags break on monorepo-scale graphs.
2. Add at least one of these (or a trimmed fixture derived from one) as an integration target so we catch regressions.
3. Document a support matrix: which package layouts, target-merging setups, and resource-bundle configurations we handle, and which are known-unsupported (cross-referencing the rules_xcodeproj issues above).
4. Decide whether focused-vs-unfocused target detection belongs in BazelBuildSystem (e.g. surface a clear error when the source's owning library is unfocused / stub-only, instead of a generic build failure).

[obj-p]

Follow-up: how do these 5 repos actually handle SwiftUI Previews?

Inspected each repo's source directly (BUILD files, docs, grep for #Preview / PreviewProvider / import SwiftUI). Key finding: none of the five run SwiftUI Previews through the rules_xcodeproj-generated project. Not one has a #Preview or PreviewProvider in code that Bazel builds. Every xcodeproj(...) rule found uses only top_level_targets — no focused_targets, build_mode = "xcode", swiftuipreviews config, or custom toolchain. They do not solve the rules_xcodeproj preview problems; they sidestep previews entirely.

Repo	Previews?	How they cope
Telegram-iOS	Minimal (watchOS only)	The 26 #Previews all live in Telegram/WatchApp/tgwatch.xcodeproj, a standalone hand-maintained .xcodeproj opened directly in Xcode. Main app is rules_xcodeproj with top_level_targets only, zero previews. SwiftUI is rare (mostly UIKit + AsyncDisplayKit).
Snapchat/Valdi	No	UI authored in TypeScript/TSX. Zero import SwiftUI across all 349 Swift files. Iteration via a TS CLI (valdi preview / valdi hotreload). rules_xcodeproj 3.2.0 declared in MODULE.bazel but never wired to a committed xcodeproj() target.
maplibre-native	No (main repo)	Full SwiftUI demo app at platform/ios/app-swift/ but zero #Preview. The previewable SwiftUI DSL lives in a separate SPM repo (maplibre/swiftui-dsl) with no Bazel, where 18 #Previews "just work" in Xcode. Cleanest workaround.
envoy (mobile/)	No	Networking SDK, UIKit/ObjC demos. Zero previews. The lone SwiftUI sample is a checked-in .xcodeproj + SPM under mobile/examples/swift/swiftpm/ consuming a prebuilt Envoy.xcframework, deliberately outside the Bazel project.
AgentsMesh	No	Real SwiftUI + TCA app fully built by Bazel (~75 files), but zero #Preview. Devs iterate via bazel run //clients/ios:AgentsMesh_xcodeproj + XCUITests, not previews.

The coping pattern, three buckets:

1. Don't need previews (Valdi, Envoy, AgentsMesh).
2. Extract previewable UI into a separate non-Bazel project (Telegram watchOS .xcodeproj; MapLibre's SPM swiftui-dsl repo).
3. SwiftUI under Bazel but no #Preview blocks authored at all (maplibre-native app-swift, AgentsMesh).

Why this matters for PreviewsMCP: real-world Bazel iOS projects treat previews as effectively unavailable and route around them. PreviewsMCP builds the module with Bazel directly (bazel build + cquery for the .swiftmodule) and renders the preview itself, so it needs neither the generated .xcodeproj, the swiftuipreviews config, nor a target to be focused. That is the gap we fill.

Correction on #3201 (referenced in the issue body): it is not a bare feature request. It is a WIP implementation writeup by Karim Alweheshy that gets the Xcode Preview App (XOJIT) path working by generating a custom xctoolchain (custom_toolchain.bzl, symlink + tool-override scripts), rewriting library detection/linking (linker_input_files.bzl), adding new build-phase objects, and hardcoding libclang_rt.iossim.a. Many checkboxes done; open items are project-size dedup and dependency-detection edge cases. Takeaway: even the upstream fix is a heavy custom-toolchain + linking rewrite, reinforcing the value of our build-and-render-ourselves approach.

Confidence: "previews don't work in the Bazel project" for Telegram and maplibre-native is inferred from rule attributes plus the total absence of preview code, not from a live preview build.