Is your feature request related to a problem? Please describe.
A separate set of Windows samples cannot be handled as straightforward source ports. The current inventory contains 20 entries with unresolved desktop API gaps, background activation requirements, native dependencies, restricted capabilities, hardware requirements, Store dependencies, or missing source.
Generic statuses such as "needs design" do not provide enough information to plan the work or explain whether a modern WinUI 3 equivalent is feasible. Mixing these investigations into the straightforward porting backlog also makes that backlog difficult to close.
This work evaluates WinUI 3 modernization options; it does not add UWP runtime support to winapp.
Describe the solution you'd like
Track and resolve each pending or blocked migration through a focused technical investigation.
For each entry:
- Confirm the original scenario, required APIs, capabilities, hardware, and activation model.
- Check the current Windows App SDK migration guidance and available HWND/desktop interop APIs.
- Prototype a desktop alternative when there is a credible path.
- Decide whether to port, redesign, consolidate, defer, or exclude the sample.
- Record the evidence, limitations, validation requirements, and any external dependency.
- Create focused implementation or platform follow-up issues where appropriate.
Completion criteria
- No sample remains generically marked "needs design" or "API gap" without evidence.
- Every entry has an explicit disposition and rationale.
- Feasible replacements have a scoped implementation plan.
- Unsupported scenarios document the missing platform capability or unacceptable rewrite cost.
Additional context
Known blocker classes include CoreWindow-bound APIs, background tasks and activation, native C++ components, restricted capabilities, physical-device validation, Store association, and incomplete upstream source. This issue should remain separate from the viable-port tracking issue so both workstreams have measurable completion criteria.
Is your feature request related to a problem? Please describe.
A separate set of Windows samples cannot be handled as straightforward source ports. The current inventory contains 20 entries with unresolved desktop API gaps, background activation requirements, native dependencies, restricted capabilities, hardware requirements, Store dependencies, or missing source.
Generic statuses such as "needs design" do not provide enough information to plan the work or explain whether a modern WinUI 3 equivalent is feasible. Mixing these investigations into the straightforward porting backlog also makes that backlog difficult to close.
This work evaluates WinUI 3 modernization options; it does not add UWP runtime support to
winapp.Describe the solution you'd like
Track and resolve each pending or blocked migration through a focused technical investigation.
For each entry:
Completion criteria
Additional context
Known blocker classes include CoreWindow-bound APIs, background tasks and activation, native C++ components, restricted capabilities, physical-device validation, Store association, and incomplete upstream source. This issue should remain separate from the viable-port tracking issue so both workstreams have measurable completion criteria.