Skip to content

[TRACKER] TUIkit Swift 6.0 parity and zero-warning SDK roadmap #40

Description

@phranck

Objective

Bring TUIkit to a release-quality Swift 6.0 SDK that is behaviorally sound, builds/tests/lints/documents with zero errors and zero warnings on macOS and Linux, and exposes every SwiftUI concept that is meaningful for a terminal UI with exact signatures unless a reviewed terminal or Swift-6.0 compiler limitation requires a documented adaptation.

Roadmap status

The issue allocation is a reviewed implementation baseline, not yet proof of exhaustive SwiftUI coverage. #7 must enumerate the complete current official SwiftUI surface, decide TUI relevance for every API, and map each included API to exactly one owning issue. Any newly discovered included family is added to this tracker before implementation begins.

Project fields

Shared definition of done

Every issue below must preserve these gates:

  • swift-tools-version: 6.0; no unguarded newer-compiler feature.
  • swift build, swift test, SwiftLint strict, and DocC succeed on macOS and Linux with zero errors and zero warnings.
  • Public SwiftUI-named APIs match labels, order, types, generic constraints, result types, builders, conformances, isolation, and applicable semantics, or have an explicit manifest exception.
  • Every public control remains a View with a real body; Renderable stays limited to leaf/private core views.
  • Runtime state/services are per app and Environment-driven, with no mutable production singleton.
  • Behavioral output is asserted before performance; docs/examples compile and runtime examples are smoke-tested.

Ordered critical path

Phase 0: executable baseline

These start together. The manifest guides all public API decisions; characterization fixtures protect the runtime migration.

Phase 1: runtime and rendering correctness

Phase 2: public SwiftUI-compatible foundation

Phase 3: terminal-meaningful SwiftUI coverage

Phase 4: release hardening

Independent parallel lane

These can start without modifying the main runtime critical path:

Existing issue integration

Conflict rules

Commit discipline

  • Split every issue into small, thematic, independently revertible commits wherever the work remains coherent.
  • An issue may and normally will contain multiple commits.
  • Every commit must build and keep applicable tests/gates green. Do not publish an intentionally failing regression-test commit; use local/known-issue characterization or land the test with the smallest fix.
  • Separate characterization/fixtures, mechanical moves or renames, semantic changes, and documentation/migration updates when each intermediate commit stays green.

Explicit exclusions

Raster/GPU/Metal/shader/material APIs, non-cell-based affine/projective and 3D transforms, Apple representables, touch/spatial-only gestures, haptics/Pencil, visionOS immersive/volume APIs, and window-server-only concepts remain excluded unless the compatibility manifest documents a deterministic terminal meaning. Deterministic cell translations such as offset/position belong to layout #20; transitions belong to #34. TUI-specific APIs remain allowed only as clearly named additive behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpriority: criticalBlocks runtime correctness or the release-quality gate

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions