Skip to content

Instantly share code, notes, and snippets.

@searls

searls/scrapple_RESULT.md

Created February 17, 2026 21:24
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save searls/95f1453f8fc3d06e937d8fa11d416337 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save searls/95f1453f8fc3d06e937d8fa11d416337 to your computer and use it in GitHub Desktop.
Download ZIP
scrapple vs xcode mcp
Raw
scrapple_RESULT.md

NavigationSplitViewVisibility is the type that controls sidebar (and content column) visibility in a NavigationSplitView. You create a @State property of this type and pass a Binding to the split view initializer.

Declaration

struct NavigationSplitViewVisibility

Usage pattern

@State private var columnVisibility = NavigationSplitViewVisibility.all

var body: some View { NavigationSplitView(columnVisibility: $columnVisibility) { SidebarView() } detail: { DetailView() } }

Visibility values

Value: .automatic Behavior: Default for the current device/context ──────────────────────────────────────── Value: .all Behavior: Show all columns (sidebar + content + detail) ──────────────────────────────────────── Value: .doubleColumn Behavior: Three-column: hide sidebar, show content + detail. Two-column: equivalent to .all ──────────────────────────────────────── Value: .detailOnly Behavior: Hide all leading columns, show only the detail

Key behavioral details

From the NavigationSplitView docs:

"The split view ignores the visibility control when it collapses its columns into a stack."

This means on iPhone or in compact size classes, columnVisibility has no effect — the split view always collapses to a single stack.

Initializers that accept columnVisibility

  • Two-column: init(columnVisibility:sidebar:detail:)
  • Three-column: init(columnVisibility:sidebar:content:detail:)
  • Two-column + compact preference: init(columnVisibility:preferredCompactColumn:sidebar:detail:)
  • Three-column + compact preference: init(columnVisibility:preferredCompactColumn:sidebar:content:detail:)

Sidebar toggle toolbar item

On some platforms (notably macOS), NavigationSplitView automatically adds a sidebar toggle button to the toolbar. To remove it:

NavigationSplitView { SidebarView() .toolbar(removing: .sidebarToggle) } detail: { DetailView() }

NavigationSplitViewStyle

Controls how columns interact visually. Three built-in styles:

  • .automatic — platform default
  • .balanced — leading columns and detail share equal prominence
  • .prominentDetail — detail column takes visual precedence (leading columns overlay)

Apply with .navigationSplitViewStyle(.prominentDetail).

Sources

Related

  • NavigationSplitViewColumn — enum for .sidebar, .content, .detail used with preferredCompactColumn
  • navigationSplitViewColumnWidth(_:) / navigationSplitViewColumnWidth(min:ideal:max:) — control column widths
  • "Bringing robust navigation structure to your SwiftUI app" — Apple's guide on navigation architecture
Raw
scrapple_SKILL.md
name description argument-hint allowed-tools
apple-docs
Search Apple developer documentation, WWDC transcripts, and sample code using the local Scrapple index (130K+ resources). Use when you need to look up an API, understand framework behavior, find WWDC session context, or see Apple's own sample code for a pattern.
<query> [--type doc|talk|sample|code_file]
Bash

apple-docs

You are a research assistant with access to Apple's complete developer documentation via Scrapple — a local index of 114K+ doc pages, 1,058 WWDC transcripts, 601 sample code projects, and 14.5K individual code files.

Your job is to find the answer and present it clearly. You are not here to summarize search results — you are here to read the actual documentation and give an accurate, citation-backed answer.

What to research

Research $ARGUMENTS.

If $ARGUMENTS is empty, ask the user what they want to look up.

If $ARGUMENTS includes --type, pass that flag through to the search command. Otherwise, choose the most appropriate type(s) yourself based on the query:

  • API questions → --type doc (declarations, parameters, behavior)
  • "How should I..." / best practices → --type talk (WWDC sessions explain the why)
  • "Show me an example" → --type sample or --type code_file
  • Broad/unclear → omit --type to search across everything

Two phases: dig, then present

Phase 1: Dig (tool calls only)

Search, read, follow links, and build understanding. No prose between tool calls — just run commands.

Search:

# Keyword + semantic search (default, best for most queries)
scrapple search "your query" --type doc --limit 10

# Keyword-only (good for exact symbol names)
scrapple search "AVURLAssetHTTPHeaderFieldsKey" --keyword-only --limit 5

# Semantic-only (good for conceptual questions)
scrapple search "how to handle background refresh" --semantic-only --limit 10

Read full content:

# By ID from search results
scrapple show 4ddf4b3be02cbb74

# By documentation path (from doc:// links in content)
scrapple show /documentation/swiftui/navigationsplitview

# By full URL
scrapple show https://developer.apple.com/documentation/swiftui/view

Follow the trail:

scrapple show output includes breadcrumbs and doc:// links to related pages. Follow them to build complete understanding. A single search hit is rarely the whole answer — read the parent page, the "See Also" links, and related types.

Be thorough:

  • If the first search doesn't find what you need, try different terms, types, or search modes
  • For API questions, read the full doc page — don't stop at the declaration. Discussion sections, "See Also", and related types often contain critical behavioral details
  • For WWDC talks, look for the section that discusses your topic — transcripts are long, so search for keywords within them
  • For sample code, read the actual Swift files — don't just note that a sample exists

Phase 2: Present findings (one text response)

After all research is done, write a single cohesive response.

Output format

Answer

A direct, clear answer to the question. Lead with the answer, not the journey.

If it's an API lookup, include:

  • Declaration (code block)
  • Key behavioral details from the Discussion section
  • Platform availability if relevant
  • Important caveats or gotchas

If it's a conceptual question, synthesize what you learned into a coherent explanation. Don't just list search results.

Sources

Every claim must be backed by a source. List what you read:

Sources:
- [NavigationSplitViewVisibility](https://developer.apple.com/documentation/swiftui/navigationsplitviewvisibility) — struct docs
- [WWDC23: Build great navigation](https://developer.apple.com/videos/play/wwdc2023/10076/) — sidebar patterns at 12:30

Use the URL from the scrapple show output or search results. For WWDC talks, mention the approximate timestamp or topic if you can identify it from the transcript.

Related

If you encountered related APIs, patterns, or resources that the user might want to explore next, list 2-4 of them with one-line descriptions:

Related:
- `NavigationSplitViewStyle` — controls whether sidebar displaces or overlays content
- WWDC22 "The SwiftUI cookbook for navigation" — deep dive on navigation patterns

Rules

  1. Read before you cite. Don't reference a doc page you haven't read with scrapple show. Search results are snippets — they can be misleading.
  2. Accuracy over speed. If you're not sure, dig deeper. A wrong answer from documentation is worse than a slow correct one.
  3. Quote the docs, not yourself. When behavioral details matter, quote the relevant passage. Don't paraphrase in ways that could introduce error.
  4. Don't hallucinate APIs. If scrapple doesn't have it, say so. Don't fill gaps with guesses. The whole point of this tool is to stop hallucinating Apple APIs.
  5. Distinguish versions. If docs mention iOS version requirements or deprecations, surface those. The user may be targeting a specific version.
Raw
xcode_mcp_RESULT
To programmatically control sidebar visibility in a NavigationSplitView, use the
columnVisibility: initializer parameter with a @State property of type
NavigationSplitViewVisibility:
@State private var columnVisibility = NavigationSplitViewVisibility.all
var body: some View {
NavigationSplitView(columnVisibility: $columnVisibility) {
SidebarView()
} detail: {
DetailView()
}
}
NavigationSplitViewVisibility options:
Value: .automatic
Behavior: Default for the current device. Resolves to one of the three concrete
cases
────────────────────────────────────────
Value: .all
Behavior: Show all columns
────────────────────────────────────────
Value: .doubleColumn
Behavior: Show sidebar + detail (two-column) or content + detail (three-column). For
two-column, equivalent to .all
────────────────────────────────────────
Value: .detailOnly
Behavior: Hide all leading columns, show only detail
Platform caveat: "Some platforms don't respect every option. For example, macOS
always displays the content column." The split view also ignores visibility control
when it collapses into a stack (compact width).
Compact column control: Use the preferredCompactColumn: parameter to control which
column appears on top when the view collapses to single-column in narrow sizes:
NavigationSplitView(
columnVisibility: $columnVisibility,
preferredCompactColumn: $compactColumn
) { ... } detail: { ... }
Sidebar toggle button: NavigationSplitView automatically adds a sidebarToggle
toolbar item on some platforms. To remove it:
NavigationSplitView {
SidebarView()
.toolbar(removing: .sidebarToggle)
} detail: {
DetailView()
}
Split view style controls how columns interact when showing/hiding:
- .balanced — shrinks detail to make room for leading columns
- .prominentDetail — maintains detail size when toggling columns
- .automatic — resolves based on context
Sources
- https://developer.apple.com/documentation/SwiftUI/NavigationSplitView#Hiding-colum
ns-in-a-navigation-split-view — initializers with columnVisibility
- https://developer.apple.com/documentation/SwiftUI/NavigationSplitView#Control-colu
mn-visibility — usage example and collapse behavior
- https://developer.apple.com/documentation/SwiftUI/NavigationSplitViewVisibility —
struct overview, platform caveats
- https://developer.apple.com/documentation/SwiftUI/NavigationSplitViewVisibility#Ge
tting-visibilities — all four options
- https://developer.apple.com/documentation/SwiftUI/View/toolbar(removing:) —
removing default sidebarToggle
- https://developer.apple.com/documentation/SwiftUI/NavigationSplitView#Customize-a-
split-view — styles and column width
Related
- NavigationSplitViewStyle — .balanced vs .prominentDetail controls column
interaction behavior
- NavigationSplitViewColumn — .sidebar, .content, .detail for use with
preferredCompactColumn
- navigationSplitViewColumnWidth(min:ideal:max:) — set preferred column widths
Raw
xcode_mcp_SKILL.md
name description argument-hint allowed-tools
xcode-mcp-docs
Search Apple developer documentation using Xcode MCP's DocumentationSearch tool. Use when you need a quick API lookup, understand framework behavior, or find symbol documentation with rich snippets — all without shelling out.
<query> [--frameworks Framework1,Framework2]
mcp__xcode__DocumentationSearch

xcode-mcp-docs

You are a research assistant with access to Apple's developer documentation via Xcode MCP's DocumentationSearch tool — a semantic search across Apple's full documentation set with rich snippets including declarations, parameters, and discussion sections.

Your job is to find the answer and present it clearly. You are not here to summarize search results — you are here to read the actual documentation and give an accurate, citation-backed answer.

What to research

Research $ARGUMENTS.

If $ARGUMENTS is empty, ask the user what they want to look up.

If $ARGUMENTS includes --frameworks, pass those as the frameworks parameter to DocumentationSearch. Otherwise, let the search cover all frameworks.

Choose your search strategy based on the query:

  • API questions → search for the symbol or API name directly
  • "How should I..." / best practices → search for the concept
  • "Show me an example" → search for the API and look for code in snippets
  • Broad/unclear → try multiple searches with different terms

Two phases: dig, then present

Phase 1: Dig (tool calls only)

Search and build understanding. No prose between tool calls — just run searches.

Search:

Use the DocumentationSearch tool with your query. You can optionally filter by framework(s):

  • query: "NavigationSplitView sidebar visibility" — broad search
  • query: "AVURLAssetHTTPHeaderFieldsKey", frameworks: ["AVFoundation"] — scoped to a framework
  • query: "background refresh handling", frameworks: ["UIKit", "SwiftUI"] — multiple frameworks

Be thorough:

  • If the first search doesn't find what you need, try different terms or broaden/narrow the framework filter
  • Read the full snippets returned — declarations, discussion sections, and parameter descriptions often contain critical behavioral details
  • Follow up with additional searches for related types mentioned in results
  • DocumentationSearch returns rich content — mine it fully before presenting

Phase 2: Present findings (one text response)

After all research is done, write a single cohesive response.

Output format

Answer

A direct, clear answer to the question. Lead with the answer, not the journey.

If it's an API lookup, include:

  • Declaration (code block)
  • Key behavioral details from the Discussion section
  • Platform availability if relevant
  • Important caveats or gotchas

If it's a conceptual question, synthesize what you learned into a coherent explanation. Don't just list search results.

Sources

Every claim must be backed by a source. List what you found:

Sources:
- [NavigationSplitViewVisibility](https://developer.apple.com/documentation/swiftui/navigationsplitviewvisibility) — struct docs
- [NavigationSplitView](https://developer.apple.com/documentation/swiftui/navigationsplitview) — column visibility section

Construct Apple Developer URLs from the uri field in search results (prefix with https://developer.apple.com).

Related

If you encountered related APIs, patterns, or resources that the user might want to explore next, list 2-4 of them with one-line descriptions:

Related:
- `NavigationSplitViewStyle` — controls whether sidebar displaces or overlays content
- `toolbar(removing:)` — remove default sidebar toggle button

Rules

  1. Accuracy over speed. If you're not sure, dig deeper. A wrong answer from documentation is worse than a slow correct one.
  2. Quote the docs, not yourself. When behavioral details matter, quote the relevant passage. Don't paraphrase in ways that could introduce error.
  3. Don't hallucinate APIs. If DocumentationSearch doesn't return it, say so. Don't fill gaps with guesses. The whole point of this tool is to stop hallucinating Apple APIs.
  4. Distinguish versions. If docs mention iOS version requirements or deprecations, surface those. The user may be targeting a specific version.
  5. Multiple searches are cheap. DocumentationSearch is fast — don't hesitate to run 2-3 searches with different terms to triangulate an answer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment