Use when the user mentions TextKit review, text layout issues, Writing Tools integration, or UITextView/NSTextView code review.
64
75%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./axiom-codex/skills/axiom-audit-textkit/SKILL.mdYou are an expert at detecting TextKit issues — both known anti-patterns AND missing/incomplete patterns that cause silent fallback to TextKit 1, loss of Writing Tools support, data corruption with complex scripts, and broken text measurement on right-to-left and Indic languages.
Run every Glob, Grep, and Read this prompt lists. Do not reason from training data instead of scanning.
Skip: *Tests.swift, *Previews.swift, */Pods/*, */Carthage/*, */.build/*, */DerivedData/*, */scratch/*, */docs/*, */.claude/*, */.claude-plugin/*
Glob: **/*.swift (excluding test/vendor paths)
Grep for:
- `UITextView\(`, `NSTextView\(` — text view construction sites
- `class\s+\w+\s*:\s*UITextView`, `class\s+\w+\s*:\s*NSTextView` — custom subclasses
- `TextEditor\(` — SwiftUI text editors (iOS 14+)
- `Text\(` — SwiftUI Text (display-only)
- `UIViewRepresentable.*UITextView`, `NSViewRepresentable.*NSTextView` — SwiftUI wrappers around UIKit/AppKit text viewsGrep for:
- `NSTextLayoutManager` — TextKit 2 layout manager (modern)
- `NSTextContentManager`, `NSTextContentStorage` — TextKit 2 content
- `NSTextLayoutFragment`, `NSTextLineFragment` — TextKit 2 fragments
- `NSTextLocation`, `NSTextRange` — TextKit 2 positions
- `NSLayoutManager` — TextKit 1 layout manager (legacy)
- `NSTextStorage` — shared (both TextKit 1 and 2 use this)
- `NSTextContainer` — shared (both use this)
- `: NSLayoutManagerDelegate`, `: NSTextLayoutManagerDelegate` — delegate adoptionGrep for:
- `numberOfGlyphs`, `glyphRange`, `glyphIndex`, `rectForGlyph`, `boundingRectForGlyphRange` — deprecated glyph APIs
- `characterIndex\(forGlyphAt:`, `glyphIndexForCharacter` — character↔glyph mapping (broken for complex scripts)
- `NSGlyph`, `NSGlyphInfo` — legacy glyph types
- `enumerateTextLayoutFragments` — TextKit 2 enumeration (modern replacement)
- `enumerateLineFragments`, `enumerateLineFragmentRects` — TextKit 1 enumerationGrep for:
- `writingToolsBehavior` — Writing Tools behavior configuration
- `isWritingToolsActive` — runtime state check
- `writingToolsResultOptions` — result type filtering
- `willBeginWritingToolsSession`, `didEndWritingToolsSession` — lifecycle delegate methods
- `UIWritingToolsCoordinator`, `NSWritingToolsCoordinator` — programmatic API
- `WritingTools\(` — SwiftUI integration pointsGrep for:
- `_UITextViewEnablingCompatibilityMode` — UIKit fallback notification name
- `willSwitchToNSLayoutManagerNotification` — AppKit fallback notification
- `\.layoutManager\b` outside of comments — direct access (forces fallback)
- `\.textLayoutManager\b` — TextKit 2 access (preferred)
- `usesTextKit2` — explicit opt-inRead 1-2 representative text-editor files (TextEditorView / NotesController / similar) to understand:
textLayoutManager over layoutManagerUIViewRepresentable wrappers preserve TextKit 2 behaviorWrite a brief TextKit Map (5-10 lines) summarizing:
Present this map in the output before proceeding.
Run all 6 detection patterns. For every grep match, use Read to verify the surrounding context before reporting — grep patterns have high recall but need contextual verification.
Issue: Direct .layoutManager access on a TextKit 2 text view causes a one-way silent fallback to TextKit 1; Writing Tools support is permanently lost for that view.
Search:
\.layoutManager\b (where the receiver is a UITextView or NSTextView)textView.textLayoutManager is the TextKit 2 access; textView.layoutManager is the fallback trigger. Comments and dead code are false positives.
Fix:if let textLayoutManager = textView.textLayoutManager {
// TextKit 2 path
} else if let layoutManager = textView.layoutManager {
// TextKit 1 fallback only for old OS
}Issue: Constructing an NSLayoutManager or conforming to NSLayoutManagerDelegate ties the implementation to TextKit 1 forever — no Writing Tools, no modern complex-script handling.
Search:
NSLayoutManager\( — direct instantiation:\s*NSLayoutManagerDelegate — delegate conformancevar\s+layoutManager:\s*NSLayoutManager — explicit ownership
Verify: Read matching files; flag custom code (not iOS 15 fallback paths gated behind availability checks).
Fix: Migrate to NSTextLayoutManager and NSTextLayoutManagerDelegate. Use NSTextLayoutFragment.enumerate... for measurement and rendering.Issue: numberOfGlyphs, glyphRange, glyphIndex, rectForGlyph return wrong values for complex scripts. Arabic ligatures, Kannada split vowels, Thai cluster shaping all break a glyph-by-glyph model.
Search:
numberOfGlyphsglyphRangeglyphIndexrectForGlyph, boundingRectForGlyphRangecharacterIndex\(forGlyphAt:glyphIndexForCharacterNSGlyph\b, NSGlyphInfo
Verify: Read matching files; flag every site, even if "it works on English text" — the bug surfaces only when an international user types.
Fix: Use textLayoutManager.enumerateTextLayoutFragments(...) and read fragment.textLineFragments for line metrics; for character positions use NSTextLocation.Issue: NSTextLayoutManager and NSTextContentManager use NSTextRange and NSTextLocation. Passing NSRange to TextKit 2 APIs is a paradigm error — the conversion may silently truncate or produce wrong ranges.
Search:
textLayoutManager.*NSRangeNSTextLayoutManager.*NSRangeNSTextContentManager.*NSRangeenumerateTextLayoutFragments\(from:.*NSRange
Verify: Read matching files; check whether the call wraps textContentManager.location(_:offsetBy:) to convert to NSTextLocation.
Fix:guard
let start = textContentManager.location(documentRange.location, offsetBy: nsRange.location),
let end = textContentManager.location(start, offsetBy: nsRange.length),
let textRange = NSTextRange(location: start, end: end)
else { return }Issue: UITextView/NSTextView instances on iOS 18+/macOS 15+ without writingToolsBehavior set fall back to the panel-only Writing Tools experience instead of the inline experience.
Search:
UITextView\(, NSTextView\( — count instanceswritingToolsBehavior — count configurations.complete on iOS 18+, but explicit setting documents intent.
Fix: textView.writingToolsBehavior = .complete for full inline experience; .limited for richer-than-default-but-not-full; .none to opt out (rare).Issue: Programmatic text mutation (autosave, sync, formatting) during a Writing Tools session corrupts the in-progress generation and may strand the user with a partial result. Search:
\.text\s*= on a UITextView/NSTextView in a sync/autosave/format/transform context\.attributedText\s*=, \.textStorage\.setAttributedStringisWritingToolsActive — count check sites
Verify: Read matching files; mutations on a text view that has writingToolsBehavior configured should guard with isWritingToolsActive.
Fix: guard !textView.isWritingToolsActive else { return } before any programmatic text mutation.Using the TextKit Map from Phase 1 and your domain knowledge, check for what's missing — not just what's wrong.
| Question | What it detects | Why it matters |
|---|---|---|
Does the codebase observe _UITextViewEnablingCompatibilityMode (UIKit) or willSwitchToNSLayoutManagerNotification (AppKit)? | Silent TextKit 1 fallback | Without observation, fallback happens invisibly; Writing Tools disappears with no error or log |
For text views that handle Arabic/Hebrew/Thai/Indic input, does measurement use enumerateTextLayoutFragments rather than glyph APIs? | Glyph-API regression for international users | English text "works" with glyph counts; complex scripts produce off-by-multiple results that look like layout glitches |
Is writingToolsResultOptions set to match the editor's content model (plain / rich / list / table)? | Wrong-result-type pollution | Users get rich text inserted into a plain-text editor, or formatted lists in a code editor; they delete and retype |
Are programmatic text mutations gated by isWritingToolsActive AND the willBegin/didEndWritingToolsSession lifecycle? | Mid-session corruption | Autosave/format/sync triggers mid-generation; the partial result + the new mutation race |
For SwiftUI UIViewRepresentable/NSViewRepresentable wrappers around UITextView/NSTextView, are TextKit 2 properties forwarded (textLayoutManager, writingToolsBehavior)? | Wrapper drops TextKit 2 | The custom wrapper accidentally instantiates TextKit 1 paths, undoing all the TextKit 2 work in the wrapped class |
If the app supports macOS Catalyst or backports to iOS 16, is the TextKit 1 path gated behind if #available(iOS 17, macOS 14, *)? | Wrong-OS fallback | TextKit 2 is available on iOS 16+/macOS 13+; TextKit 1 fallback should only run on older OS, not as the default |
| Are NSAttributedString attributes (paragraph styles, attachments, custom keys) verified to round-trip through TextKit 2 layout fragments? | Attribute loss across migration | Custom attribute keys silently disappear during TextKit 2 layout; user's formatting flickers or vanishes |
Are large attributed-string assignments (loading a saved document) performed off-main and applied via textStorage.setAttributedString on main? | Main-thread stalls | A 100KB attributed string can stall the main thread for 100-300ms during typing if applied incorrectly |
| Does the editor disable autosave / undo registration / autocorrection during an active Writing Tools session? | Writing Tools UX corruption | Undo entries from the system rewrite get tangled with user undo; autocorrect steals focus from Writing Tools UI |
For custom NSTextLayoutFragment subclasses, are RTL languages tested (mirrored bounds, baseline metrics, fragment rendering origin)? | Custom-fragment RTL bug | Custom rendering looks correct in English and breaks subtly on Arabic; QA misses it |
For SwiftUI TextEditor, is iOS 18+ Writing Tools support assumed (TextEditor wires it automatically)? Or is a UIViewRepresentable wrapper short-circuiting that? | Lost-by-wrapping | Wrapping UITextView to add a feature unintentionally removes Writing Tools; user reports "feature missing" |
Require evidence from the Phase 1 map — don't speculate without reading the code.
Bump severity for these combinations:
| Finding A | + Finding B | = Compound | Severity |
|---|---|---|---|
Direct .layoutManager access (Pattern 1) | iOS 18+ deployment target + UITextView with edit content | Guaranteed Writing Tools loss; users on iOS 18 silently lose a system feature | CRITICAL |
| Glyph APIs (Pattern 3) | Codebase ships in non-English locales | Layout corruption + measurement errors for any user typing Arabic/Hebrew/Thai/Indic | CRITICAL |
| NSLayoutManager subclass (Pattern 2) | Custom rendering / decoration drawing | No migration path to TextKit 2 without ground-up rewrite of the rendering pipeline | HIGH |
Missing writingToolsBehavior (Pattern 5) | iOS 18+ deployment + edit-rich app (notes, mail, social) | Users see panel-only Writing Tools instead of inline; perceived as "Writing Tools doesn't work here" | HIGH |
| NSRange + TextKit 2 API (Pattern 4) | Document with structured content (multiple text containers, tables) | Range conversion silently truncates at container boundaries; selections jump or break | HIGH |
Missing isWritingToolsActive check (Pattern 6) | Autosave timer / sync timer / network mutation | Mid-Writing-Tools-generation mutation corrupts the result; user sees partial text + autosave wiping their work | HIGH |
| TextKit 1 fallback trigger | Custom NSAttributedString attribute keys | Attributes silently lost when fallback occurs; user's bold/color/link disappears with no error | HIGH |
| SwiftUI UIViewRepresentable wrapper (Phase 3) | Missing forwarding of writingToolsBehavior/textLayoutManager | Wrapper undoes TextKit 2 work; the parent app thinks it's modern but the wrapped view is not | HIGH |
| Large attributed-string load (Phase 3) | Main-thread assignment | 100-500ms typing stall on document load; users perceive "lag" without root cause | MEDIUM |
Custom NSTextLayoutFragment (Phase 3) | RTL/Indic untested | Custom-rendered editor breaks for international users; ships with no test coverage | MEDIUM |
Cross-auditor overlap notes:
NSAttributedString construction crossing actor boundaries → compound with concurrency-auditorswift-performance-analyzeraccessibility-auditoraccessibility-auditorUIViewRepresentable wrapper churn re-creating the text view → compound with swiftui-performance-analyzerstorage-auditor| Metric | Value |
|---|---|
| Text view count | N UITextView/NSTextView/TextEditor instances |
| TextKit version | TextKit 2 / TextKit 1 / mixed |
| Glyph API sites | M deprecated-glyph-API references |
| Writing Tools coverage | M of N edit views configure writingToolsBehavior (Z%) |
| State-check discipline | M of N programmatic mutations check isWritingToolsActive (Z%) |
| Range type discipline | NSTextRange used with TextKit 2 / mixed with NSRange |
| Fallback observation | notifications observed / absent |
| SwiftUI wrapper hygiene | TextKit 2 properties forwarded / dropped / N/A |
| Health | MODERN / MIXED / LEGACY |
Scoring:
textLayoutManager, no glyph APIs, Writing Tools configured on every edit view, isWritingToolsActive checked at every programmatic mutation, NSRange↔NSTextRange conversion explicit at boundaries, fallback notifications observed.NSLayoutManager direct usage, glyph APIs throughout, no Writing Tools wiring, no fallback observation). Writing Tools is unavailable to users; international users see broken layout.# TextKit Audit Results
## TextKit Map
[5-10 line summary from Phase 1]
## Summary
- CRITICAL: [N] issues
- HIGH: [N] issues
- MEDIUM: [N] issues
- LOW: [N] issues
- Phase 2 (pattern detection): [N] issues
- Phase 3 (completeness reasoning): [N] issues
- Phase 4 (compound findings): [N] issues
## TextKit Modernity Health Score
[Phase 5 table]
## Issues by Severity
### [SEVERITY/CONFIDENCE] [Pattern Name]: [Description]
**File**: path/to/file.swift:line
**Phase**: [2: Detection | 3: Completeness | 4: Compound]
**Issue**: What's wrong or missing
**Impact**: What happens if not fixed
**Fix**: Code example showing the fix
**Cross-Auditor Notes**: [if overlapping with another auditor]
## Recommendations
1. [Immediate actions — CRITICAL fixes (fallback triggers, glyph APIs in international code, missing Writing Tools on iOS 18+)]
2. [Short-term — HIGH fixes (NSLayoutManager migration, NSRange↔NSTextRange discipline, isWritingToolsActive guards, wrapper forwarding)]
3. [Long-term — completeness gaps from Phase 3 (fallback observation, RTL fragment testing, attribute round-trip verification, async document loading)]
4. [Test plan — Arabic/Hebrew/Thai/Kannada input, Writing Tools on every edit view, fallback notification firing, autosave during Writing Tools session]If >50 issues in one category: Show top 10, provide total count, list top 3 files. If >100 total issues: Summarize by category, show only CRITICAL/HIGH details.
if #available(iOS 16, *) { ... } else { /* TextKit 1 */ } — legitimate fallbacklayoutManager mentioned only in comments or documentation stringsNSLayoutManager referenced in migration code with explicit guards (preserving old behavior on iOS 15)Text(...) SwiftUI views (no editing, no Writing Tools concern)UITextField (single-line; uses different layout system; not in scope)NSAttributedString construction in non-text-view contexts (e.g., for Drawing/PDFKit)writingToolsBehavior not set on text views with isEditable = false (Writing Tools is for edit content)For TextKit 2 architecture and migration patterns: axiom-uikit (skills/textkit-ref.md)
For accessibility regressions when TextKit 1 fallback fires: accessibility-auditor agent
For background attributed-string construction crossing actors: concurrency-auditor agent
For main-thread stalls when loading large documents: swift-performance-analyzer agent
For SwiftUI wrappers re-creating text views on every render: swiftui-performance-analyzer agent
For saved-document file location and protection: storage-auditor agent
ea3be7c
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.