Native components for Apple platforms
Sabella
The SwiftUI sibling of Bleecker, sharing its tokens and component contracts across macOS, iOS, and tvOS.
I designed and built this project independently, using my own resources.
Explore the project
Public repository
Technical documentation
SwiftUI library for Apple platforms. Package and native catalog instructions are in the repository.
Technologies
01 / Context
The problem behind the project
Native Apple applications should share the same product identity as the web without imitating browser controls.
Apple applications need to look related to the web products while behaving like native macOS, iPhone, iPad, and television software. Keyboard focus, pointer input, Dynamic Type, safe areas, and remote navigation cannot be reduced to a CSS translation.
I use Sabella as the native presentation foundation for newsroom and television clients. The package owns reusable interaction and presentation; the consuming application retains product state, identity, and service calls.
02 / Implementation
Design and implementation
I build the SwiftUI implementation, token mappings, component catalog, and parity checks.
I built SwiftUI components, semantic contract enums, token mappings, packaged font registration, application shells, and native component catalogs. Platform-specific implementations share the design language without pretending that a television screen is a desktop component grid.
The tvOS surface adds editorial shelves, channel guides, remote focus, playback overlays, and native live playback. It exposes semantic playback activity so a consumer can distinguish advancing media from buffering, failure, or a request to play.
The package keeps catalogs and development examples outside the library product. Release checks include a clean consumer so a successful package build is not the only evidence that downstream applications can import it.
03 / Architecture
Architecture and workflow
Map shared design contracts
Tokens and semantic variants become Swift values while SwiftUI owns native rendering.
Adapt interaction to the device
macOS uses pointer/keyboard patterns, touch devices use safe-area-aware navigation, and tvOS uses remote focus and playback patterns.
Exercise native catalogs
Dedicated platform catalogs provide the reference surface for appearance, state, Dynamic Type, and interaction.
Verify the consumed package
A separate application imports the library product without depending on its catalog or sibling source tree.
04 / Approach
Engineering decisions
Native behavior, shared identity
SwiftUI controls retain platform interaction and accessibility behavior while consuming the same visual contracts as Bleecker.
Explicit parity
Matching contract names and component inventories make the relationship to the web library reviewable instead of relying on appearance alone.
05 / Evidence
Evidence and outcomes
The catalog coverage gate discovers public component/style APIs and compares them with registered fixtures. A deliberately missing fake component proves that omitted coverage can fail the gate.
The bounded primary-button conformance proof records deterministic mappings and platform exceptions. Native accessibility and input stay with Sabella rather than being inferred from a neutral schema.
Source and technical notes
06 / Current scope
Where it stands
Apple platforms are the scope of this library. Component implementation and platform acceptance are tracked separately in the public repository.
Shared API names do not establish complete visual or behavioral parity across platforms. Each platform has its own acceptance surface.
Live-player state can report advancing media, but a product still owns channel identity, service authorization, viewing attribution, and device operations.