Explore a monorepo split for the theme and Native UI Shell packages #278

Motivation

Native UI Shell now owns native view projection, DOM state synchronization, asynchronous actions, navigation/overlay coordination, and app-local extension APIs. These responsibilities are distinct from the theme's Web styles and animations.

Explore separating the distributable packages within this repository, keeping a shared home for stars, issues, pull requests, documentation, and the integration demo.

Proposed direction

packages/
  theme/             # Web styles and animations
  native-ui-shell/   # Capacitor plugin, built-in projection, extension API
demo/               # Shared integration demo
docs/

• Preserve the existing @rdlabo/ionic-theme-ios27 theme package name.
• Consider a separate Native UI Shell package; its final name and release policy remain to be decided.
• Keep the extension API inside Native UI Shell rather than introducing another extension package.
• Keep user-defined extensions as app-local Web/TypeScript and SwiftUI files. Users should not need to publish an npm package or create a separate Capacitor plugin for each extension.

Questions to resolve

• What dependency direction and explicit integration contracts should connect the theme and Shell, especially for transitions and overlays?
• Can Shell operate without loading this theme, and which behaviors still require theme integration?
• How should existing /native and /vertical-bars imports and Capacitor native setup migrate? Define compatibility, re-exports or deprecation where appropriate.
• How should workspace builds, package exports, native Swift sources, demo dependencies, CI, and publishing work?
• Should the packages share versions or release independently?

Sequencing and scope

This is follow-up architectural work, not part of #276 or #277. Finish those PRs in the current repository/package layout, including CI fixes and review feedback, before undertaking the migration.

Avoid adding new coupling that would obstruct extraction, but do not add speculative migration abstractions to the current feature PRs. Keep the eventual packaging migration separate from behavioral changes so reviewers can assess compatibility clearly.

Completion criteria

• Package boundaries and dependency direction are documented.
• The agreed migration path for existing consumers is documented and verified.
• Both packages build and package correctly, including Capacitor native integration.
• The shared demo and CI validate their integration and existing Web fallback behavior.
• No new requirement to package or publish app-local extensions is introduced.