Multi-Platform Libraries

Pyreon's native compiler lowers supported TypeScript and JSX into SwiftUI and Jetpack Compose. A package owns the rules that translate its API. The compiler supplies shared state, function, JSX, theme-token and native style operations.

This keeps the source-facing API in the package that publishes it. Adding a library does not require adding that library's names, payloads or target templates to the compiler. Native support remains a declared subset: a plugin can lower one API while other exports need a <Web> branch or a native adapter. The capability matrix and supported TypeScript describe those limits.

Using package plugins

The native CLI discovers a package's plugin from package.json when the application declares that package and its source imports it. The public tooling entry is @pyreon/<package>/native-plugin; normal web runtime imports do not load it. The native compiler is an optional peer of each owner.

pyreon-native plugins --app=./my-app
pyreon-native explain ./my-app/src/App.tsx --app=./my-app
pyreon-native build --target=all --source=./my-app/src --out=./generated

plugins lists installed owners and their capabilities. Discovery follows runtime dependencies and peers, including installed optional peers, while development dependencies are read only from the application. Plain Mode imports from @pyreon/core/plain activate the reactivity owner before the Plain Mode pass injects its signal/computed imports. explain shows the lowerings used by a file. The --plugin option adds a local extension, and --no-plugins disables package discovery for diagnosis.

Programmatic compilation loads the owners explicitly:

import { createCompiler } from '@pyreon/native-compiler'
import reactivity from '@pyreon/reactivity/native-plugin'
import primitives from '@pyreon/primitives/native-plugin'
import attrs from '@pyreon/attrs/native-plugin'

const compiler = createCompiler({ plugins: [reactivity, primitives, attrs] })
const source = `
  import { signal } from '@pyreon/reactivity'
  import { Stack, Text } from '@pyreon/primitives'
  import attrs from '@pyreon/attrs'
  const Card = attrs({ name: 'Card', component: Stack }).attrs({ padding: 4 })
  export function Counter() {
    const count = signal(0)
    return <Card><Text>{count()}</Text></Card>
  }
`
const swift = compiler.transform(source, { target: 'swift' })
const kotlin = compiler.transform(source, { target: 'kotlin' })

Load every owning package used by the source. For example, a form using schema validation also needs the schema package's plugin; a kinetic factory using an imported preset needs both kinetic and kinetic-presets. An absent plugin can leave an unresolved source call or JSX tag, so inspect diagnostics and compile the generated output.

What the packages own

• State and data packages own their declarations, receiver rewrites, native runtime calls and validation stubs. This includes store, state-tree, form and field arrays, hooks, queries, schemas, tables and synchronization.

• The router owns hook bindings. The compiler retains the shared navigation host and canonical link operations.

• Reactivity owns import recognition for signal and computed, mapped to generic compiler state operations, plus advice for unsupported exports. The core operation spellings remain available in unimported standalone snippets.

• Attrs, styler and rocketstyle own their factory parsers, definition payloads and JSX rewrites. Generic theme tokens and the native style connector remain compiler operations. Static factory definitions and supported dimension expressions cross; arbitrary CSS callbacks and browser CSSOM behavior do not.

• UI core owns PyreonUI providers. Each provider controls its own scope while the compiler saves and restores scope state.

• Kinetic owns its factory and transition rewrite. Kinetic-presets owns which exported motion names have a native equivalent. Unsupported presets produce a named diagnostic instead of selecting a different animation.

• Code and rich-text own the WebView bridge to their editors: <CodeWebView> and <RichTextWebView> lower to a native <WebView src>, and each package builds the page from the app's installed CodeMirror or TipTap (webHosts, run by pyreon-native assets). The editors themselves are DOM engines and stay web; every other export of those packages warns by name.

• Charts owns its chart hosts, draw-list integration, typing and target code. The web rendering implementation is not embedded in the native app.

Authoring a native plugin

Publish a tooling entry separately from the runtime barrel:

{
  "exports": {
    "./native-plugin": {
      "bun": "./src/native-plugin.ts",
      "import": "./lib/native-plugin.js",
      "types": "./lib/native-plugin.d.ts"
    }
  },
  "peerDependencies": { "@pyreon/native-compiler": "^0.53.0" },
  "peerDependenciesMeta": { "@pyreon/native-compiler": { "optional": true } },
  "pyreon": {
    "native": {
      "plugin": "./lib/native-plugin.js",
      "modules": ["@acme/camera"]
    }
  }
}

Use the compiler version that provides the API your plugin needs. Import compiler types and helpers through @pyreon/native-compiler/plugin-api. The native packages guide describes the broader toolchain; the compiler package README documents the extension protocol.

Choose the seam that matches the source:

Factory recognizers can inspect ModuleParseContext.binding(name) to distinguish an import alias from a local or foreign binding. They read static theme tokens through theme. Item element hooks return ordinary JSX/style IR; the shared backend handles its native rendering. Plugin memory is scoped to one file or component, and an unsupported source shape should report an actionable diagnostic.

Verification

Every package declaring shared, service-backend, or a partial nativeFrontend must publish its own plugin. The multiplatform metadata gate checks the entry, activation modules and optional compiler peer. The compiler boundary test independently discovers all package entries, checks their public-facade imports, and verifies the shared fixture catalog contains every owner.

The golden corpus holds generated code and warnings stable across ownership moves. Toy-plugin tests prove extension seams work for unrelated libraries. Installed-entry tests exercise built tooling through CLI discovery. Swift and Kotlin compile gates check generated source, while real SDK and device jobs cover the applications they execute. A green metadata gate or unchanged golden output alone does not establish that a native feature works on a device.

Declared package tiers

The table below comes from each package manifest. shared describes an authoring surface that lowers across targets; service-backend uses a platform runtime behind that API; web-only can still list a specific partial native frontend in its rationale. Consult each package's manifest and the capability matrix before relying on a particular API.

Generated from each package manifest's multiplatform declaration bybun scripts/check-multiplatform-tier.ts --write-table — edit the manifests, not this table. The gate fails when they drift.

shared — the authoring surface lowers on every target (12)

service-backend — one API, per-target runtime backends (11)

web-only — architecturally coupled to the web platform (35)