Skip to content

v0.1.0-canary.8

Pre-release
Pre-release

Choose a tag to compare

View all tags
@mayansharma mayansharma released this 15 Apr 10:20
· 11 commits to main since this release
v0.1.0-canary.8
77b2fbb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Summary

This release introduces Catalyst’s internal plugin architecture, a new cross-platform system for delivering native capabilities in a modular, manifest-driven way. It adds the PluginBridge web API, native plugin runtimes for Android and iOS, build-time plugin composition, config-based enablement through WEBVIEW_CONFIG.plugins, and an app-facing catalyst plugins CLI. The first migrated capability, device_info, now works through this plugin model on both platforms.

Problem

Native capabilities in Catalyst were previously coupled directly into the legacy bridge layer. That made the bridge grow continuously, spread platform-specific requirements across framework internals, and made optional native features harder to isolate, evolve, and ship cleanly. It also meant there was no unified, modular contract for enabling features, composing only what an app needs, and keeping Android and iOS aligned during migration.

Solution

Catalyst now uses an internal plugin system built around PluginBridge and manifest-driven native composition. Plugins remain framework-owned inside catalyst-core, but apps can enable or disable them through WEBVIEW_CONFIG.plugins without touching native code.

During buildApp:android and buildApp:ios, Catalyst discovers enabled plugins, validates their manifests, copies only the required native sources and resources, and generates platform registries for dispatch. At runtime, PluginBridge provides a single explicit web API to initialize the bridge, emit commands, and register callbacks, while Android and iOS native runtimes validate requests and route them to the correct plugin implementation.

Benefits

  • Native features are now modular instead of being tightly embedded in the legacy bridge
  • Android and iOS share one clearer product model for new native capabilities
  • Plugin-specific permissions, dependencies, plist entries, entitlements, URL schemes, and resources stay localized to the plugin manifest and plugin code
  • Builds become more deterministic because only enabled plugins are composed into the generated app
  • Apps get a simpler enablement model through WEBVIEW_CONFIG.plugins and the catalyst plugins CLI
  • Catalyst can migrate legacy bridge features incrementally without breaking existing WebBridge behavior
  • The new architecture gives the framework a cleaner path to add future native capabilities with less framework-wide coupling
Assets 2
Loading