Research: prior art review and expansion opportunities

[obj-p]

Overview

PreviewsMCP's core — compiling SwiftUI outside Xcode, loading dylibs at runtime, literal diffing for state-preserving hot-reload — is unique in the ecosystem. Several existing tools solve narrower problems that PreviewsMCP could subsume or improve upon.

This issue tracks research into each tool's approach and how PreviewsMCP could incorporate or replace their functionality.

---

1. InjectionNext / InjectionIII — Hot reload into running apps

What they do: Watch source files, recompile, swap function implementations via dyld_dynamic_interpose. Works with any Swift code.

Their limitations:

• Function interposing is fragile, breaks with compiler optimizations
• Requires @objc dynamic in some cases
• Struggles with Swift 6 strict concurrency
• No literal-only fast path (always recompiles)

How we could replace:

• SwiftUI views are value types — swap the View type via dlopen instead of interposing functions
• Our literal-only path (LiteralDiffer) preserves @State without recompilation — InjectionNext can't do this
• Need: lightweight client library for embedding in user's app, compile against app's module for @EnvironmentObject / Core Data access

Research tasks:

• Study InjectionNext's interposing mechanism and where it breaks
• Prototype a HotReload { } wrapper view that loads from PreviewsMCP dylibs
• Test with a real app that uses navigation, environment objects, Core Data
• Compare reload latency (our literal path vs their full recompile)

---

2. XcodeBuildMCP (Sentry) — Build/test/deploy MCP server

What they do: 59 MCP tools covering xcodebuild, simulator control, screenshots, test running, code signing, App Store Connect. Most comprehensive iOS MCP server.

Their limitations:

• Requires Xcode for everything
• Simulator screenshots are generic (not preview-aware)
• No #Preview parsing, compilation, or rendering
• No hot-reload
• No accessibility tree inspection tied to preview context

How we could complement/compete:

• We're the superior preview engine — they could delegate to us for preview workflows
• We could expand to cover more of their build/test surface (xcodebuild integration already partially exists via our Xcode build system support)
• Our accessibility tree + touch injection is more targeted than their generic simulator interaction

Research tasks:

• Catalog XcodeBuildMCP's 59 tools — which overlap with ours, which are orthogonal
• Identify their simulator interaction tools vs ours (screenshot quality, touch, elements)
• Evaluate whether we should expand into build/test territory or stay focused on previews

---

3. ios-simulator-mcp — Simulator interaction

What they do: MCP server for iOS simulator screenshots, UI element inspection, touch simulation, app install/launch.

Their limitations:

• No compilation or preview rendering
• Simulator interaction only (no macOS)
• No hot-reload
• No build system awareness

How we already replace:

• PreviewsMCP is a strict superset — we do everything they do plus compilation, preview rendering, hot-reload, and build system integration
• Our touch injection uses the Hammer approach (in-app IOHIDEvent), likely more reliable than their approach

Research tasks:

• Compare their simulator interaction API surface to ours
• Identify any features they have that we don't (e.g., app install/launch outside preview context)
• Consider whether to market PreviewsMCP as a replacement

---

4. SnapshotPreviews (Emerge Tools) — Preview snapshot testing

What they do: Automatically discover and snapshot all #Preview blocks in a project via XCTest. Includes Preview Gallery app for browsing previews on device.

Their limitations:

• Requires Xcode's build pipeline and XCTest target
• Can't run in CI without Xcode
• Tightly coupled to Xcode's preview infrastructure
• No hot-reload or interactive preview

How we could replace:

• previewsmcp snapshot --all that walks source files, discovers #Preview blocks, and snapshots each one
• Runs without Xcode — works in headless CI (Linux runners with cross-compilation?)
• Could output a static HTML gallery (like their Preview Gallery but without a device)
• Our build system integration (SPM, Bazel, Xcode) means we can compile cross-file dependencies

Research tasks:

• Study how SnapshotPreviews discovers previews (macro expansion? source scanning?)
• Compare their preview discovery to our PreviewParser
• Prototype --all flag that walks a project and snapshots every #Preview
• Design output format (directory of PNGs? HTML report? JSON manifest?)
• Evaluate Emerge Tools' Preview Gallery UX for inspiration

---

5. Prefire — Snapshot test generation from #Preview

What they do: Auto-generate snapshot tests and Playbook views from #Preview macros. Uses SourceKit for preview discovery.

Their limitations:

• Generates XCTest code that still needs Xcode to run
• Code generation step adds complexity
• No standalone rendering

How we could replace:

• Same approach as SnapshotPreviews above — direct rendering without XCTest
• Our PreviewParser already does preview discovery without SourceKit
• Could generate snapshot diffs for PR reviews (before/after screenshots)

Research tasks:

• Study Prefire's SourceKit-based preview discovery vs our regex-based PreviewParser
• Evaluate if SourceKit approach catches cases we miss
• Design a PR review workflow: snapshot all previews on base branch vs PR branch, generate visual diff

---

6. Blitz — Device management + App Store Connect MCP

What they do: Native macOS app with MCP servers for simulator/iPhone management, builds, App Store Connect submission. 30+ tools.

Their limitations:

• No preview rendering or compilation
• Requires their native Mac app
• Simulator control is generic, not preview-aware

How we relate:

• Mostly orthogonal — they focus on deployment pipeline, we focus on development inner loop
• Their simulator control overlaps but is less specialized
• No need to compete on App Store Connect / device management

Research tasks:

• Review their simulator management tools for any features we should add
• Evaluate if their device management (physical iPhone) is worth adding

---

7. Xcode 26.3 native MCP — Apple's first-party AI integration

What they do: Built-in Claude Agent SDK and OpenAI Codex in Xcode. MCP support for external tool servers. Can capture Xcode Previews for visual verification.

Their limitations:

• Requires Xcode to be running
• Preview rendering tied to Xcode's canvas
• Can't run headless or in CI
• Closed source, no customization

How we differentiate:

• PreviewsMCP works without Xcode — editors like VS Code, Cursor, Zed, terminals, CI
• Headless operation for automated testing and AI agents
• Open source and extensible
• Faster iteration cycle (no Xcode canvas overhead)

Research tasks:

• Test Xcode 26.3's MCP preview capture — quality, latency, capabilities
• Document the gaps (what can we do that Xcode's native MCP can't)
• Position PreviewsMCP as the "Xcode-free" alternative in docs/marketing

---

Priority

Suggested order of investigation based on impact:

1. InjectionNext replacement — highest impact, broadest audience, technically novel
2. SnapshotPreviews/Prefire replacement — clear CI use case, batch --all mode
3. ios-simulator-mcp — we already replace this, just need to communicate it
4. XcodeBuildMCP — evaluate complement vs compete
5. Xcode 26.3 — positioning and differentiation
6. Blitz — mostly orthogonal, low priority