Swift 採用中止 – Ladybird ブラウザの Swift 6.0 サポート課題が終了

 (github.com/LadybirdBrowser)
1 ポイント 投稿者 GN⁺ 2026-02-20 | 1件のコメント | WhatsAppで共有
  • Ladybird ブラウザプロジェクトは、Swift 6.0 サポートを実験段階から正式化する過程で発生した問題一覧を整理していたが、その後 Swift の採用をこれ以上進めないことを決定した
  • 主な障害要因は Swift と C++ の相互運用性（Interop） に関する ABI の不一致、ヘッダーの循環依存、特定の型を返せないことなどで、多くの項目は Swift 6.0.0 以降に修正された
  • CMake ビルドシステムでも、Swift + Ninja 環境でのデプロイメントターゲット不一致、install_name 処理の不具合、非互換なコンパイルオプションなどの問題が報告された
  • Ladybird 自体のコードでも、AK および LibGfx モジュールの modulemap 構成、Swift フロントエンドのクラッシュ、型の名前空間衝突 など多数のビルド不安定要因が確認された
  • こうした技術的制約の蓄積により Swift 統合は中止され、これは C++ 中心の開発を維持する決定 につながった

Swift 関連の問題

  • Swift 6.0 サポートを実験段階から脱するために解決すべき 言語および ABI レベルのバグ が多数存在
    • LLVM バージョンの不一致により、Swift オープンソースビルド時にアサーション失敗が発生
    • Optional<CxxValueType> を返す際に コンパイラとブリッジングヘッダー間の ABI 不一致 問題
    • Ubuntu 22.04 環境で <execution> ヘッダーを含めると libstdc++ モジュールの循環依存 が発生
    • swift::Optional<swift::String> を返せないことや <chrono> ヘッダーの読み込み失敗など、C++23 互換性の問題 も含む
  • 一部の問題は Swift 6.0.0 以降のリリースで修正されたが、いくつかは main ブランチでのみ解決 されており、安定版には未反映
  • 複数の項目で「ワークアラウンド（回避ビルド方法）」が提示されたが、完全な解決策ではない

CMake 関連の問題

  • Swift と Ninja ビルドの組み合わせで CMAKE_OSX_DEPLOYMENT_TARGET が適用されず、多数の警告が発生
    • 手動で CMAKE_Swift_COMPILER_TARGET を設定する必要あり
  • CMP0157 ポリシーを有効化すると install_name ディレクトリ設定が無視 され、手動修正が必要
    • 関連修正は CMake 3.29、3.30 にバックポート予定
  • Swift コンパイラが理解できないリンクオプション が外部依存関係から渡される問題が存在

Ladybird プロジェクト内部の問題

  • AK および LibGfx モジュールの clang module map 構成時にシステムヘッダーと衝突 が発生
    • <math.h> を含めるとモジュール認識エラーでビルド失敗
  • Swift フロントエンドが AK コンテナテスト中にデバッグビルドでクラッシュ
    • リリースモードビルドでのみ回避可能
  • String 型の名前空間衝突により Swift フロントエンドが異常終了
    • AK.String または Swift.String と明示指定が必要
  • Swift Testing モジュール使用時に コンパイラフロントエンドがクラッシュ し、AK::StringView の CxxSequenceType 未認識 問題も存在

追加の改善項目

  • Swift で C++ 関数が Optional<CxxType> を返すと アプリケーションがクラッシュ
    • 暫定対策としてサイズ 0 または 1 の配列を返す方法を使用
  • SourceKit-LSP および vscode-swift は ルートレベルの compile_commands.json を要求
    • シンボリックリンクの作成で解決可能
  • Linux 環境では <swift/bridging> パスを 手動追加しなければならない不便さ がある

未解決の疑問

  • Swift で C++ の view 型や byte slice をコピーなしで渡す方法 が不明
  • Swift が AK::Optional、AK::HashMap など独自型を std:: 型と同等に認識 できない
  • Swift ガベージコレクタと Ladybird のメモリ管理をどう統合するか も未確定

この issue は Swift 6.0 統合に向けた技術的障害を体系的に記録した文書だったが、その後 Ladybird チームが Swift 採用を中止したことで、「Swift 6.0 Blockers」issue は終了 した。

関連記事

1件のコメント

 
GN⁺ 2026-02-20
Hacker Newsの意見

  • Swift削除コミットには少し追加説明がある
    「長い間進展がなかったため、Swift導入を断念し、コードベースから削除した」というメッセージが含まれている
    関連コミットはこちらで見られる

    • さらに詳しい文脈はissue #933にまとめられている

  • 私は2021年に初めてSwiftを使ってみたが、10年以上C#/.NETをやってきた身として驚いた
    C#も複雑だと思っていたが、Swiftはそれよりはるかに複雑な言語だった
    特にバックエンドAPIやデータアクセス層を作るときは、参考資料がほとんどなかった
    Swiftは知見の大半がAppleプラットフォーム向けに蓄積されていて、それ以外の領域ではほぼ開拓者にならなければならない感覚だった

    • ここ数年、PythonやGoのようなシンプルな言語が「複雑さは悪だ」という主張を強めてきたが、言語の表現力が高いほうがむしろ保守性に役立つとも思う
      Larry Wallが言ったように、ツールの複雑さは問題の複雑さに合わせるべきだ（Rakuへの言及）
    • 私は2018年ごろにObjective-CからSwiftへ移ったが、最初は改善されたように感じた
      しかし「structは値渡し、classは参照渡し」という規則と、「唯一の信頼できる情報源を保つ」という原則が衝突して、開発が退屈で遅くなる経験をした
      Swiftの矛盾したベストプラクティスのせいで進展がなく、結局多くの助言は当てにならないと気づいた
    • M1 MacBookでVaporテンプレートをコンパイルするたびに、ノートPCが過熱する問題もあった
    • 私も似たようなものだった。Rustのようにすぐ習得できると思っていたが、まったくそうではなかった
      シンタックスシュガーが多すぎるし、同じことをする方法が何十通りもあって、そのたびに言語リファレンスを引かなければならなかった
    • それで結局C#/.NETに戻ったのか気になる

  • 言語が何であれ、Ladybirdが将来的にユーザーフレンドリーなJavaScript実装に注力してくれるといい
    JSがユーザー活動の追跡やペースト禁止、過剰なデバイス情報収集に悪用されているのは問題だ
    Torのように、ユーザー間で標準化されたスプーフィング値を報告するようにすれば、プライバシー保護に役立つ気がする

    • ただ、こうした方式は多くのWebサイトでボット検知と誤認され、アクセスを遮断される可能性がある
      トグル式オプションとして提供するのはよいが、デフォルトにすると採用は難しそうだ
    • Web標準を無視して独自に動くブラウザは、個人的には絶対に使いたくない

  • Swift削除は興味深い。理由が明確に説明されていないので気になる
    Linuxで動くだけでも、いずれ試してみたい

    • 私には、ビルド衝突が繰り返されたせいで断念したように見える
      Swiftが複数のC++バージョンのライブラリを同時にimportできなかったり、演算子のバージョン衝突が起きたりする問題だった
      Swiftはよい言語だが、すでに大きいプロジェクトに後から追加するには複雑すぎたのだろう

  • なぜLadybirdがSwiftを試したのか気になる。RustのほうがC++相互運用性に優れているのではと思う
    SwiftのGCもブラウザ性能には不利そうだ

    • Andreas KlingはTwitterで、「Swift vs Rustでは、Swiftのほうがオブジェクト指向サポートとC++連携で優れている」と述べていた
      リンク1, リンク2
    • Rustがゲーム開発で扱いにくい理由と似ている。borrow checkerが循環参照構造とうまく噛み合わない
      回避策はあるが、生産性が落ちる
    • Swiftは実際、C++ interopドキュメントにある通り、相互運用性はかなり高い
      ただLadybirdには十分ではなかったようだ
    • Andreas Klingは、Rustはオブジェクト指向機能が不足していてGUI開発に不利だと言っていた
      以前はSerenityOSでJaktという言語を作ったこともあったが、結局C++に戻ったようだ
    • RustはDOM階層構造やOOPの問題で却下されたことがあったと記憶している
      関連する過去の議論はこの投稿にある

  • SwiftはAppleにあまりに依存した言語なので驚きはない
    C++の安全な部分だけをうまく使えば十分で、実際ほとんどのブラウザはC++で書かれている

    • だが、すべてのブラウザがC++に閉じ込められているだけだ
      ChromiumとFirefoxは段階的により安全な言語へ置き換え中で、新しいブラウザをC++でまた書くのは過去の失敗を繰り返すようなものだ
      C++利用は1998年のKHTML時代の遺産だ
    • 「現代的でメモリ安全なC++サブセット」とは具体的に何を指すのか分からない
      string_viewのような最新STL機能も含むのか？ それでも完全なメモリ安全にはほど遠い
    • RustはMozillaで開発されたと認識しているが、Mozilla自体がRustで書かれているのか気になる
    • いずれにせよSwiftは、高性能が必要な領域ではC++に勝ちにくい
      一部のベンチマークを除けば、実際のプログラムではほぼ常に遅い

  • Swift削除は残念だ。では独自言語のJaktが再び候補に上がるのだろうかと気になる

    • LadybirdはすでにSerenityOSから分離されており、Jaktは彼らの言語ではない
      新しい言語を導入する可能性は低いと思う
    • 個人的には、プロジェクトがあまりに頻繁に方向転換するのが心配だ
      外部支援で運営されるプロジェクトがこういう形だと、長期的に持続しにくい
    • なぜRustを使わないのかもどかしい。もしかしてC++への執着なのかと思ってしまう

  • Swiftは結局Appleのおもちゃ言語に過ぎないと思う
    Appleはそれ以上に成長させないだろう

  • LadybirdのMac UIはAppKitの上に薄く載せたレイヤーだ
    SwiftではなくObjective-C++で書かれている
    ソースコード参照

    • そのコードを最初に書いたのは私だ
      Swift導入よりずっと前、SerenityOS時代に作ったものなので、Objective-C++を使ったのは単に慣れた言語だったからだ

  • 以前、Swiftへ移行すると言ったときに批判したことがある
    Swiftは設計が雑で、コンパイル速度も遅く、システム言語として成長する可能性は低いと見ていた
    専門家もいなかったので、今回の決定はよかったと思う

    • Swiftはオープンソースのように見えても、実際にはAppleがすべての決定権を握っている
      ConcurrencyやSwift Testingのような機能も、Appleの必要に応じて押し進められた例だ
      クロスプラットフォーム作業の大半は、小規模チームが別途進めている
    • Swiftの問題は認めるが、「専門家がいなかった」というのは誇張だ
      Chris Lattnerを別にしても、SwiftリードたちはC++コミュニティで認められた人物だった
    • Swiftの核心は言語自体よりも標準ABIだ
      Rust陣営がCに加えてSwift ABIもFFIでサポートしてくれるとよいのだが
    • それなら、どの言語を勧めるのか気になる
    • Goも似たようなものなのか？ 最近の最も合意された選択肢が何なのか知りたい