skills/txt-apple-docs/SKILL.md
Look up authoritative Apple-authored documentation for any text-system or Swift API via Sosumi (sosumi.ai URL swap and MCP server) and Xcode 26.3+ xcrun mcpbridge. Use when an Apple Text skill needs grounding against the actual Apple docs, an exact API signature is required, a Swift compiler diagnostic needs the official explanation, or a recently-shipped framework update has to be verified against the source. This is the entry point for documentation grounding — invoke it before reciting any specific API signature from memory.
npx skillsauth add sitapix/apple-text txt-apple-docsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Authored against iOS 26.x / Swift 6.x / Xcode 26.x.
This skill is the documentation pipe for the Apple Text skill set. Apple's developer.apple.com pages are JS-rendered and return a "needs JavaScript" stub to non-browser fetches, so the practical access paths are Sosumi (a clean Markdown mirror at sosumi.ai plus an MCP server at https://sosumi.ai/mcp) and Apple's own xcrun mcpbridge (Xcode 26.3+, on-machine Xcode-bundled docs and indexed WWDC transcripts). Before claiming any specific API signature, behavior, deprecation status, or available-since version, fetch the current Apple docs through one of these tools — Apple ships fast and training cutoffs lag, so a memorized signature is the most common source of confidently-wrong code in this domain.
sosumi.ai mirrors Apple's developer documentation under the same path structure as developer.apple.com. The URL swap is one-to-one — every Apple docs URL has a Sosumi equivalent.
developer.apple.com/documentation/uikit/uitextview
↓
sosumi.ai/documentation/uikit/uitextview
The Sosumi page returns clean Markdown that any agent can read directly. This is the format used in every cross-reference link inside Apple Text skill content; the markdown stays portable to any client that can read URLs.
The Sosumi MCP server lives at https://sosumi.ai/mcp (Streamable HTTP + SSE) and exposes two tools:
search_documentation — keyword search across Apple's documentation index, returns ranked candidate URLs.fetch_documentation — pull the Markdown body of a specific page given its URL or symbol path.When connected via MCP, prefer search_documentation for "what's the right API for X" questions and fetch_documentation for "give me the current signature of Y" questions. Both are stateless and cheap — call them freely rather than guessing from memory.
Verifying a URL before publishing it in skill content:
curl -s -o /dev/null -w "%{http_code}\n" "https://sosumi.ai/documentation/uikit/uitextview"
# 200 = good. 404 = path doesn't resolve, find a working alternative or omit the link.
Apple sometimes reorganizes documentation paths between Xcode releases. A 404 doesn't mean the API is gone; it means the path moved. Search via sosumi.ai or via the MCP search_documentation tool to find the new location.
Xcode 26.3 (Feb 2026) shipped xcrun mcpbridge, an MCP server that exposes Xcode's bundled documentation and indexed WWDC transcripts to external agents. It's an Apple-controlled fallback for cases where Sosumi 404s, the network is unavailable, or you need WWDC-session content that Sosumi doesn't index.
The bridge launches as a subprocess and speaks MCP over stdio:
xcrun mcpbridge
Among its 20-tool catalog, the relevant ones for documentation are:
DocumentationSearch — keyword search against the docs bundled with the local Xcode install.WWDCTranscriptSearch — keyword search against indexed WWDC session transcripts.These return on-machine content that matches the Xcode version installed. If the local Xcode is 26.3, DocumentationSearch returns the docs Apple shipped with 26.3 — which may differ from sosumi.ai's mirror if the mirror is a release behind. For verification work, the bridge is the closer-to-source channel; for portable skill content, Sosumi URLs are the right link target.
Skill content should always link to sosumi.ai URLs (so the markdown is portable to clients without xcrun mcpbridge available). Use the bridge as a runtime verification tool, not as a link target in committed content.
Three practical cases:
curl that the URL returns 200 before committing.fetch_documentation on the symbol page) if connected, or xcrun mcpbridge's DocumentationSearch if the agent runs locally with Xcode 26.3+ available.xcrun mcpbridge's WWDCTranscriptSearch is the right path — Sosumi indexes the documentation but not the session transcripts.Neither path is a substitute for opening the actual project source. Documentation tells you what the API does; the project source tells you what's already calling it. Skills that diagnose code (txt-textkit-debug, txt-fallback-triggers) ground their patterns in source code first, then verify API claims against docs second.
This skill carries a small set of pre-fetched Apple-text-relevant doc summaries as repo sidecars, useful as an offline fallback and as quick context when no MCP server is connected:
AttributedString surface changes.TextEditor editing behavior.These sidecars are time-stamped against the Xcode version that produced them. Treat them as snapshots: useful for context when MCP is unavailable, but recheck against Sosumi or xcrun mcpbridge before quoting a signature into production code.
Two environment variables control the runtime Apple-doc reading behavior used by other Apple Text skills:
| Variable | Default | Purpose |
|---|---|---|
| APPLE_TEXT_XCODE_PATH | /Applications/Xcode.app | Custom Xcode path (e.g., /Applications/Xcode-beta.app) |
| APPLE_TEXT_APPLE_DOCS | false | When true, enables runtime loading of Apple-authored Markdown docs from the local Xcode install |
When APPLE_TEXT_APPLE_DOCS=true and a local Xcode contains the for-LLM Markdown bundle, prefer it for verification. The repo sidecars in references/ are the offline fallback when the runtime channel is unavailable.
/skill txt-attributed-string — AttributedString decisions and conversions/skill txt-swiftui-texteditor — SwiftUI rich-text editing on iOS 26+/skill txt-writing-tools — Writing Tools integration (time-sensitive surface)/skill txt-detectors-tagger — Foundation/NaturalLanguage utilitiesxcrun mcpbridge overviewtools
Integrate Writing Tools into UITextView, NSTextView, custom UITextInput views, or fully custom editors via UIWritingToolsCoordinator. Configure writingToolsBehavior and allowedWritingToolsResultOptions, declare protected ranges via writingToolsIgnoredRangesInEnclosingRange, gate edits with isWritingToolsActive, and pause syncing in willBegin/didEnd. Trigger on 'Apple Intelligence rewrite', 'AI summarize selection', 'compose with AI', 'why won't Writing Tools appear', or 'rewrite is breaking my code blocks' even without UIWritingToolsCoordinator named. Use when Writing Tools is missing from the menu, only the panel mode appears, rewrites corrupt code blocks, the inline animation isn't running, or a custom text engine needs to adopt UIWritingToolsCoordinator. Do NOT use for diagnosing general TextKit 1 fallback symptoms — see txt-fallback-triggers.
tools
Wrap UITextView (UIViewRepresentable) and NSTextView (NSViewRepresentable) inside SwiftUI without breaking editing. Covers binding sync, infinite-update-loop guards, cursor preservation across programmatic mutations, focus / first-responder bridging, auto-sizing strategies, environment value propagation, toolbar integration, and the iOS vs macOS scroll-view differences. Use when building or debugging a SwiftUI text-view wrapper, when cursor jumps after typing, when binding updates don't propagate, when @FocusState seems ignored, or when a wrapped editor won't size to its content. Do NOT use for picking which view class (txt-view-picker) or for which AttributedString attributes survive the SwiftUI boundary (txt-swiftui-interop).
tools
Configure TextKit 2 viewport-driven layout, NSTextLayoutFragment / NSTextLineFragment geometry, and rendering attributes vs storage attributes. Covers NSTextViewportLayoutController callbacks, layoutFragmentFrame vs renderingSurfaceBounds, line-fragment local coordinates, the extra trailing line fragment, exclusion paths that split a visual line, lineFragmentPadding vs container insets, font substitution via fixAttributes, and visible/overscroll/estimated regions. Use when working with custom layout fragments, debugging clipped diacritics or descenders, computing document coordinates from a line fragment, integrating with a custom scroll view, or when scroll-bar behavior under estimated heights is the visible problem. Do NOT use for symptom-driven debugging (txt-textkit-debug), the invalidation model (txt-layout-invalidation), or the TextKit 2 API surface in general (txt-textkit2).
development
Choose between SwiftUI Text/TextField/TextEditor, UIKit UITextView, and AppKit NSTextView. Capability comparison, tradeoffs, and decision criteria for read-only display vs single-line input vs multi-line editing vs rich attributed editing vs TextKit access. Use when the user asks "which text view should I use," "should I use TextField or TextEditor," "do I need UITextView for this," or describes a feature without naming a view class. Do NOT use for wrapping UITextView in SwiftUI — see txt-wrap-textview. Do NOT use for SwiftUI/TextKit attribute compatibility rules — see txt-swiftui-interop. Do NOT use for the iOS 26 SwiftUI TextEditor rich-text APIs themselves — see txt-swiftui-texteditor.