Enriching your text in text views

At a glance

Project structure

TextKitAndTextViewSampleApp/
├── SwiftUI/
│   ├── TextKitAndTextViewSampleApp.swift
│   ├── ContentView.swift
│   ├── Representables.swift
│   └── Platform.swift
├── LineNumberingView.swift
├── SectionCollapsingView.swift
├── InlineAttachmentsView.swift
├── TextAttachmentView.swift
├── ExclusionPathView.swift
├── TextListView.swift
└── Assets/

Structure observations

• SwiftUI/ is a navigation/adaptation layer, not the TextKit implementation layer.
• Every demonstration file contains its container plus narrowly related private helper views, storage extensions, or attachment providers.
• Platform.swift centralizes AppKit/UIKit typealiases and the small layout differences shared by container views.

Overall architecture

flowchart LR
    App["SwiftUI App"] --> Content["ContentView NavigationSplitView"]
    Content --> Selection["SidebarItem"]
    Selection --> Wrapper["Feature SwiftUI View"]
    Wrapper --> Representable["UIViewRepresentable or NSViewRepresentable"]
    Representable --> Container["Platform container view"]
    Platform["Platform.swift typealiases"] --> Container
    Container --> TextView["UITextView or NSTextView"]
    TextView --> TextKit["NSTextLayoutManager / NSTextContentStorage"]
    Container --> Gutter["Gutter or attachment UI"]
    Assets["RTF, JSON, text, movie assets"] --> TextKit

Reference code

TextKitAndTextViewSampleApp/SwiftUI/Representables.swift:18 — compile-time adapters construct the same feature container for AppKit or UIKit.

#if os(macOS)
private struct LineNumberingRepresentable: NSViewRepresentable {
    func makeNSView(context: Context) -> LineNumberingContainerView { LineNumberingContainerView() }
    func updateNSView(_ nsView: LineNumberingContainerView, context: Context) {}
}
#else
private struct LineNumberingRepresentable: UIViewRepresentable {
    func makeUIView(context: Context) -> LineNumberingContainerView { LineNumberingContainerView() }
    func updateUIView(_ uiView: LineNumberingContainerView, context: Context) {}
}
#endif

Interpretation

The representables are construction adapters only: they carry no domain state and have empty update methods. TextKit objects remain owned by reference-type platform views, which is the layer receiving layout and delegate callbacks.

Ownership and state

classDiagram
    ContentView *-- SidebarItem : owns selection state
    LineNumberingRepresentable --> LineNumberingContainerView : creates
    LineNumberingContainerView *-- LineNumberedTextView : creates
    LineNumberingContainerView *-- GutterView : creates
    LineNumberedTextView o-- LineNumberingContainerView : weak back-reference
    SectionCollapsingContainerView *-- CollapsibleTextView : creates
    SectionCollapsingContainerView *-- DisclosureGutterView : creates
    CollapsibleTextView o-- DisclosureGutterView : weak
    InlineAttachmentsContainerView *-- AnimatedAttachmentViewProvider : registers type
    AnimatedAttachmentViewProvider --> AnimatedAttachmentView : creates

Ownership evidence

TextKitAndTextViewSampleApp/SectionCollapsingView.swift:11 — the container owns both views and uses a weak closure capture to avoid a container–gutter cycle.

class SectionCollapsingContainerView: PlatformContainerView {
    // ...
}

Class and protocol design

No app-defined protocol exists. Protocol-oriented design is expressed through framework contracts such as UIViewRepresentable/NSViewRepresentable, NSTextContentStorageDelegate, and UIContentView-style TextKit provider APIs.

Access control

Reference code

TextKitAndTextViewSampleApp/LineNumberingView.swift:10 — fileprivate exposes only the two collaborators required by same-file layout helpers.

class LineNumberingContainerView: PlatformContainerView {
    // ...
}

Logic ownership and placement

Design patterns

Naming conventions

• Public-facing feature names pair ...View with ...ContainerView and private ...Representable bridges.
• PlatformView, PlatformTextView, and related aliases make cross-platform intent explicit.
• Helpers describe visible roles: GutterView, DisclosureGutterView, and AnimatedAttachmentViewProvider.
• Mutating methods use concrete outcomes such as toggleSection, rebuild, and setListMarkerStyle.

Architecture takeaways

• Keep SwiftUI representables thin when the native view has a rich callback-driven lifecycle.
• Use file-scoped feature slices to permit collaboration without widening helpers to the whole module.
• Centralize only real platform differences; leave feature logic shared and native.
• Model layout-derived UI, such as gutters, as a collaborator owned beside the text view.

Source map

• Official Apple documentation