Build graph & TFMs

How AvantiPoint.WristUI.Sdk coordinates TFMs, platform SDKs, and the multi-targeted WristUI library.

Invariants

A1: Native platform assemblies (for example watchOS bindings) are supplied by their platform SDK. App authors must not need a PackageReference to those assemblies. WristUI must not ship a competing copy.
A2: SDK-only customers do not take a WristUI dependency.
A5: Separate native deliverables per watch target. Single-project does not erase packaging boundaries (phone companion, App Clip, widget extension may still be separate projects).

Composition sketch

Application: shared C# / XAML + platform customizations
  AvantiPoint.WristUI.Sdk                    (coordinator)
    watchOS inner build
      WatchOS.Sdk / AvantiPoint.WatchOS.Sdk → native SDK references
      WristUI.dll → net10.0-watchos asset
    Wear OS inner build
      AvantiPoint.WearOS.Sdk → native SDK references
      WristUI.dll → net10.0-wearos asset

Model implicit UI package selection on the active TFM (Uno.Sdk-like). That is distinct from native DLL references already owned by each AvantiPoint platform SDK.

Build stages

Stage	Required behavior
Evaluation / restore	Recognize custom watch TFMs; select dependencies before compile; clean-machine + design-time restore
Outer build	Coordinate requested TFMs without initializing both native app pipelines; separate graphs/outputs
Inner build	Import matching platform SDK + native refs + WristUI asset; isolate sources, generated files, resources, signing
Compile / publish	Delegate native link, packaging, signing, deploy to the platform SDK; coordinator adds shared UI generation/orchestration only
Library build	Control-library packaging without exe entry points; internal WristUI builds opt out of implicit self-reference

Guardrails

Import ordering: composition hooks + idempotent imports with existing SDKs; test early props / late targets / discovery — do not assume conditional imports alone prevent duplicates.
Custom TFMs: platform SDKs own net10.0-watchos and net10.0-wearos. Validate NuGet matching and project-system behavior. Stock Android packages are not automatically Wear-compatible.
Version coordination: pin coordinating SDK in global.json; publish a tested component manifest; allow documented overrides with diagnostics. MSBuild allows only one version of a given project SDK per build.
Failure behavior: reject incompatible combinations and wrong assets with actionable diagnostics. Never silently replace a platform implementation with the neutral WristUI asset.

Build gate

An unchanged native-only sample must still compile with its original SDK. A WristUI sample must build each watch target independently and together, with no duplicate native assembly identities.

Single-project conventions

Platform folders + documented file suffixes; WATCHOS / WEAROS conditional symbols; exclude inactive platform files from compile and packaging.
Assets: shared icons/images with native overrides; entitlements, permissions, IDs, signing stay target-specific.
Host matrix published — Apple builds are not assumed on every host; missing Apple toolchain must not block an explicitly selected Wear OS build.