Feature: Add a macOS UI frontend

[jordancalhoun]

Summary

Add a native macOS graphical frontend for swiftpkg that makes common package-project workflows accessible without requiring users to construct command-line invocations manually.

Goals

• Keep swiftpkg CLI-first and scriptable; the UI should call the same core functionality rather than create a separate package-building implementation.
• Provide a clear workflow for selecting or creating a package project, editing supported build metadata, building the package, and reviewing results.
• Surface build progress, warnings, errors, output paths, and verification details in a readable form.
• Support macOS 13 and later, matching the CLI support policy.

Initial scope

• Open an existing project directory and create a new project from the existing template workflow.
• Display and edit the supported build-info fields, preserving the selected plist/JSON/YAML format where possible.
• Show project payload, scripts, and BOM metadata at a high level, with shortcuts to reveal files in Finder.
• Build through the shared swiftpkg package-building layer, including options for signing, notarization, and their explicit skip flags.
• Show streaming build logs and a final success/failure state, with the generated package location and a reveal action.
• Provide a safe confirmation before signing/notarization actions that use configured credentials.

Technical direction

• Add a SwiftUI macOS app target while extracting reusable CLI orchestration/business logic into a shared library target as needed.
• Keep command parsing and terminal-specific presentation in the executable target; expose structured build requests, progress events, results, and errors to both frontends.
• Avoid shelling out to the installed CLI when the app can invoke the shared implementation directly.
• Use sandbox/security-scoped bookmarks only if sandbox distribution is later required; initially document the expected filesystem access model.

Non-goals for the first release

• Replacing the CLI or removing any existing command-line workflow.
• Building a general-purpose installer-package editor beyond the project format supported by swiftpkg.
• A cross-platform UI.
• Embedding, exporting, or managing Apple signing credentials.

Acceptance criteria

• A user can create or open a project, edit common metadata, run a build, and locate the resulting .pkg entirely from the app.
• Builds produced by the UI use the same validation and packaging behavior as equivalent CLI builds.
• Errors retain actionable details and do not hide the underlying command/build output.
• Existing CLI tests and workflows continue to pass; new shared-core and UI-specific behavior has appropriate automated tests.
• The README explains how to build and run the UI and clearly distinguishes it from the CLI install path.