Native components for Windows
Orchard
A Windows component library implementing the shared design system in C# and WinUI 3.
I designed and built this project independently, using my own resources.
Explore the project
Public repository
Technical documentation
WinUI 3 component library. Open the solution and component catalog on Windows.
Technologies
01 / Context
The problem behind the project
Windows applications need the same product language as their web and Apple counterparts while preserving native keyboard, accessibility, and high-contrast behavior.
Orchard brings the same design language to native Windows applications using WinUI 3. The difficult work is matching semantics and visual detail while preserving Windows focus, automation, high-contrast, pointer, and packaging behavior.
The component catalog is also a working acceptance environment. A screenshot by itself cannot establish that a control keeps consumer state, receives physical input, or remains correct after loading and reparenting.
02 / Implementation
Design and implementation
I build the component library, generated token resources, and runnable Windows catalog.
I built the C#/WinUI component library, generated token resources, theme mappings, bundled fonts, native catalog, and independent package-consumer checks. Consumer-owned records and content flow into tables, charts, navigation, forms, and layout patterns.
The capture/verification tooling checks rendered pixels alongside input gates and protected glyph references. Performance work in capture persistence retains exact output while reducing avoidable conversion buffers and garbage collection, rather than changing the acceptance threshold.
Native lifecycle cases include chart focus arriving before Loaded, stale focus notifications after reparenting, and template/content identity across reloads. These cases belong to the component contract, not only to a static visual sample.
03 / Architecture
Architecture and workflow
Generate native resources
Shared tokens become Windows resources with light, dark, and high-contrast mappings.
Preserve consumer ownership
Components project the application’s original content, records, selection, and actions.
Exercise native interaction
Catalog checks combine keyboard/pointer behavior, automation, focus, and rendered appearance.
Verify package consumption
Independent applications consume packaged output so source-tree assumptions do not hide distribution defects.
04 / Approach
Engineering decisions
Windows owns its implementation
Controls and themes use C# and WinUI 3 rather than embedding the web implementation.
Acceptance beyond compilation
Component documentation records keyboard interaction, automation, layout, and visual acceptance instead of treating a successful build as proof of parity.
05 / Evidence
Evidence and outcomes
The architecture notes retain paired capture-persistence checks for opaque and transparent images, byte-for-byte PNG/RGBA comparisons, and write-error propagation. Optimizations are measured without relaxing the existing native input or image gates.
The documented x64 replay completed its retained sequence, while native ARM64 execution remained a separate outstanding item. That distinction keeps a successful cross-architecture build from being reported as physical-device acceptance.
Source and technical notes
06 / Current scope
Where it stands
The public library and catalog are in development. Full component parity and Windows acceptance remain in progress.
Component candidates, builds, visual comparison, native interaction, and platform acceptance are tracked separately. Full parity is still in progress.
Native cursor checks require a usable pointer device/session. The library does not change operating-system input settings to make a fixture appear to pass.