⚡

Zylix - Zigだけで6プラットフォームに対応するUIフレームワークを作ってみた

に公開1件

はじめに

「Zigだけで、すべての開発ができないだろうか?」

そんな素朴な疑問から始まったプロジェクト Zylix のご紹介です。

Zylixは、Zig言語をコアに据えたクロスプラットフォームUIフレームワークです。単一のコードベースから、Web(WASM)、iOS、Android、macOS、Linux、Windowsの6プラットフォームに対応するネイティブアプリケーションを構築できます。

この度、バージョン0.1.0をリリースし、PoC(Proof of Concept)の段階を抜けることができました。まだ生まれたばかりのプロジェクトですが、ここでZylixの思想と設計についてご紹介させていただきます。

名前の由来

Zylixという名前は、往年のDelphiユーザーの方ならピンとくるかもしれません。

そう、ボーランドのKylixです。

KylixはDelphiのLinux版として2001年に登場し、「Delphiで書いたコードをLinuxでも動かす」という夢を実現しようとしたプロダクトでした。残念ながらKylixは短命に終わりましたが、その「一つの言語で複数プラットフォームを攻略する」という思想は今でも色褪せません。

Zylixは、その精神をZig言語で現代に蘇らせようという試みです。Zig + Kylix = Zylix。

なぜZigなのか?

クロスプラットフォーム開発には、すでに多くの選択肢があります。

フレームワーク トレードオフ
Flutter Skiaによるカスタムレンダリング → ネイティブ感の喪失
React Native JSブリッジ → パフォーマンスのオーバーヘッド
Electron Chromiumバンドル → 150MB以上のバイナリサイズ
Tauri WebView → 限定的なネイティブ統合

これらのフレームワークはそれぞれ素晴らしいものですが、どこかでトレードオフを強いられます。

Zigには、これらを解決できる可能性があると考えました。

  • ゼロコスト抽象化: ランタイムオーバーヘッドなし
  • 予測可能なパフォーマンス: GCなし、確定的なメモリ管理
  • クロスコンパイル: 単一ツールチェーンで全プラットフォームをターゲット
  • C ABIとの完全互換: Swift、Kotlin、C#など既存言語との連携が容易
  • コンパイル時安全性: null安全、境界チェック

Zylixのアプローチ

Zylixの核心的な思想は次の一文に集約されます。

「UIを共通化せず、意味と判断だけを共通化する」

FlutterやReact Nativeが「UIそのものを統一する」のに対し、Zylixは各プラットフォームのネイティブUIフレームワーク(SwiftUI、Jetpack Compose、GTK4、WinUI 3など)をそのまま活用します。

共通化するのは以下の部分だけです。

Zigで共有 プラットフォーム固有
アプリケーション状態 UIコンポーネント
ビジネスロジック アニメーション
データバリデーション プラットフォームAPI
イベント処理 ネイティブジェスチャー

アーキテクチャ

Zylixは「中央脳(Central Brain)」アーキテクチャを採用しています。

  ┌─────────────────────────────────────────────────────────┐
  │                    Your Application                      │
  ├─────────────────────────────────────────────────────────┤
  │  SwiftUI  │ Compose │  GTK4  │ WinUI 3 │  HTML/JS       │
  ├───────────┴─────────┴────────┴─────────┴────────────────┤
  │                      C ABI Layer                         │
  ├─────────────────────────────────────────────────────────┤
  │                    Zylix Core (Zig)                      │
  │  Virtual DOM │ State │ Events │ Diff │ Scheduler        │
  └─────────────────────────────────────────────────────────┘
  1. Zylix Core(Zig): 状態管理、ビジネスロジック、Virtual DOM、イベントシステム
  2. C ABIレイヤー: 言語間バインディングのための安定したインターフェース
  3. プラットフォームシェル: 各OSのネイティブUIフレームワーク

この設計により、以下のメリットが得られます。

ユーザーにとって

  • ネイティブなルック&フィール
  • OSのアクセシビリティ機能がそのまま使える
  • 小さいアプリサイズ
  • 優れたバッテリー持続時間

開発者にとって

  • ロジックの単一ソース
  • コンパイル時の型安全性
  • 単一ツールチェーンからのクロスコンパイル
  • 予測可能なメモリ管理

対応プラットフォーム

現在、以下の6プラットフォームに対応しています。

プラットフォーム UIフレームワーク 状態
Web/WASM HTML/JavaScript ✅ 対応済み
iOS SwiftUI ✅ 対応済み
Android Jetpack Compose ✅ 対応済み
macOS SwiftUI ✅ 対応済み
Linux GTK4 ✅ 対応済み
Windows WinUI 3 ✅ 対応済み

各プラットフォームで、シンプルなTodoアプリのデモが動作しています。

実装例

簡単なカウンターの例をご覧ください。

Zigコア(共有ロジック)

pub const State = struct {
    counter: i64 = 0,
};

pub fn increment(state: *State) void {
    state.counter += 1;
}

SwiftUI(iOS/macOS)
Text("\(zylixState.counter)")
Button("増加") {
    zylix_dispatch(.increment)
}

Jetpack Compose(Android)
Text("${zylixState.counter}")
Button(onClick = { zylixDispatch(INCREMENT) }) {
    Text("増加")
}

同じロジックを共有しながら、UIは完全にネイティブ。これがZylixの目指す姿です。

プロジェクト構成

  zylix/
  ├── core/           # Zig コアライブラリ
  ├── platforms/      # プラットフォーム別実装
  │   ├── android/    # Kotlin/Jetpack Compose
  │   ├── ios/        # Swift/SwiftUI
  │   ├── linux/      # GTK4
  │   ├── macos/      # SwiftUI
  │   ├── web/        # WASM
  │   └── windows/    # WinUI 3
  ├── site/           # ドキュメントサイト
  └── examples/       # サンプルプロジェクト

現在のステータスと今後

Zylix 0.1.0は、PoCを抜けたばかりの段階です。

  • ✅ Virtual DOMの基本実装
  • ✅ 状態管理とイベントシステム
  • ✅ 6プラットフォームでの動作確認
  • ✅ Todoアプリのデモ

まだまだ足りない機能は山ほどあります。

  • ⏳ コンポーネントライブラリの拡充
  • ⏳ ルーティングシステム
  • ⏳ 非同期処理のサポート
  • ⏳ Hot Reload(開発時)
  • ⏳ より実用的なサンプルアプリ

生まれたばかりのプロジェクトですが、少しずつ成長させていければと思っています。

コントリビュート歓迎

Zylixはオープンソースプロジェクトです(Apache License 2.0)。

  • 🐛 バグ報告
  • 💡 機能提案
  • 📝 ドキュメント改善
  • 🔧 プルリクエスト

どんな形でも大歓迎です!

GitHub: https://github.com/kotsutsumi/zylix
ドキュメント: https://zylix.dev

Zig言語に興味がある方、クロスプラットフォーム開発に新しいアプローチを試してみたい方、ぜひ一度覗いてみてください。Issueやプルリクエストをお待ちしております。

おわりに

「Zigだけで全部やる」という、少し無謀とも思える挑戦を始めてみました。

Zigという言語の持つポテンシャルを、UIフレームワークという形で引き出せないか。各プラットフォームのネイティブ体験を損なうことなく、ロジックだけを共通化できないか。

まだ道半ばですが、この試みに共感いただける方がいらっしゃれば、一緒に育てていければ嬉しいです。

最後までお読みいただき、ありがとうございました。

Discussion