Android向けSwift SDKを発表

 (swift.org)
10 ポイント 投稿者 GN⁺ 2025-10-25 | 1件のコメント | WhatsAppで共有
  • Swift言語はクラウド、Windows、ブラウザ、マイクロコントローラまで拡張され成熟してきたが、今回Android向けSwift SDKが公開された
  • このSDKはSwift Androidワークグループによる数か月の取り組みの成果であり、開発者がSwiftでAndroidネイティブアプリを開発できるようにする
  • SDKはWindowsインストーラーに同梱されるほか、Linux・macOS向けに別途ダウンロードも可能で、サンプルコードやガイドもあわせて提供される
  • swift-javaプロジェクトを通じてSwiftとJava間の双方向相互運用性をサポートし、自動バインディング生成によって性能と安全性を確保する
  • 今回の公開はSwiftのクロスプラットフォームエコシステム拡大を加速させ、モバイル開発の新たな可能性を開く転換点として評価されている

Swift SDK for Android 概要

  • Swift言語はこの10年間でクラウドサービスからWindows、ブラウザ、マイクロコントローラまで拡張してきており、その流れの中でAndroidプラットフォームへの進出が正式に打ち出された
    • Swiftの相互運用性(interoperability) により、複数プラットフォーム間でのコード共有が容易になる
  • Androidワークグループ(Android workgroup) は誰でも参加できるオープングループで、SwiftをAndroidへ拡張することを目標としている
  • 今回の発表はSwift SDK for Androidのナイトリー(preview)ビルド公開を意味しており、コミュニティの長年にわたる協業の成果でもある

SDKの主な機能と配布方法

  • 開発者は今やSwiftを使ってAndroidネイティブアプリケーションを直接開発できる
    • これによりクロスプラットフォーム開発の新たな可能性が開かれる
    広告
  • SDKはWindowsインストーラーにバンドルされて提供され、LinuxおよびmacOS向けには個別にダウンロードできる
  • Swift.orgは**「Getting Started」ガイド**を通じて、AndroidデバイスでSwiftコードをセットアップする方法を案内している
    • GitHubのSwift for Android Examplesリポジトリでは、エンドツーエンドのアプリワークフローを実演している

パッケージ互換性とコミュニティ拡大

  • Swift SDKにより既存のSwiftパッケージをAndroidへ移植できる
    • Swift Package Indexの25%以上のパッケージがすでにAndroidビルドをサポートしている
    • Community ShowcaseページではAndroid互換性の有無が表示される
  • こうした拡張はSwiftエコシステムのマルチプラットフォーム対応強化につながる

swift-javaプロジェクトと相互運用性

  • swift-javaプロジェクトは、SwiftとJava間の相互運用性(interoperability) を提供するライブラリおよびコードジェネレータである
    • SwiftとJavaの双方向統合を自動で処理し、安全かつ高性能なバインディングを生成する
    広告
  • 開発者はこれによりビジネスロジックをAndroidへ移植でき、関連内容はSwift Server Side Meetupの発表動画で確認できる

コミュニティ参加と今後のロードマップ

  • 今回のプレビューリリースはツール改善とエコシステム拡張のための新たな機会を開いた
    • SwiftフォーラムのAndroidカテゴリで、経験、アイデア、ツール、アプリを共有することが推奨されている
    • 本発表はフォーラムの公式スレッドでも議論されている
  • Androidワークグループは現在ビジョンドキュメント(vision document) を作成中で、Swift on Androidの優先領域と今後の方向性を示す予定だ
    • プロジェクトボードで主要な進捗状況を追跡し、公式CIシステムでSDKの品質を管理している
  • Swiftチームはコミュニティの参加を促し、Androidエコシステム内でのSwiftの存在感強化を目指している

関連記事

1件のコメント

 
GN⁺ 2025-10-25
Hacker Newsの意見

  • すべてのクロスプラットフォームフレームワークにおける核心的な問いは、UIをどう扱うかという点
    AdobeのFlex Builderのように、各プラットフォームで違和感のあるデザインシステムを使うと、結局はネイティブらしさを自前で実装する必要があった
    FlutterはiOSのCupertinoテーマを完璧に再現しようとし、React Nativeはプラットフォーム標準のウィジェットを活用して、スクロールのような要素が自然に感じられるようにしている
    ブログ記事でこの重要な部分に触れられていないのが残念
    AppleがAndroid向けSwiftを出したとしても、Apple特有のデザイン哲学のせいでAndroidでは違和感が出る可能性がある
    このプロジェクトがApple主導なのか、それともコミュニティ中心のオープンソースの試みなのかが、今後の方向性を決める気がする

    • 私はUI共有よりも、ネイティブUIを書けるフレームワークを好む
      だからKMPが良い。iOSではSwiftUI、AndroidではKotlinでUIを書きつつ、ビジネスロジックだけ共有できる
      UIを共有しようとすると、「一度書いて、あらゆる場所でデバッグする」という悪夢が生まれる
      Swift for Androidもこのように、言語レベルでのロジック共有を可能にしてくれそう
    • Swift SDK for AndroidはUI方式を強制しない
      例でもJetpack Composeをそのまま使いながらSwiftのロジックを呼び出している
      Swiftの参照カウント型メモリモデルと同じ構造を維持していて一貫性が高い
      Appleで開発者ツールを担当する立場として、この技術が新しい革新の足がかりになることを期待している
    • Browser CompanyがSwiftUIをWindowsへ移植した事例のように、AndroidでもSwiftUIがJetpack Composeにマッピングされる可能性がある
      SwiftUIは本来「ネイティブUI」ではなく、システムが解釈してUIViewやNSViewを生成する宣言的言語だから
    • 今回のリリースには、SwiftUIやUIKitがAndroidへ移植された内容は含まれていない
      Flutterのように直接複製しない限り、Apple UIをAndroidでそのまま使うのは不可能
    • Swift SDKはUI技術を指定しない
      その代わり、Skip.toolsのようなプロジェクトがSwiftUIをJetpack Composeへブリッジしてくれる
      Skip Showcaseアプリでその例を見ることができる
      私はSkip製品とSwift Android Workgroupのメンバーで、今回のSDKのリリースマネージャーとして参加した

  • 公式プロジェクトとして発表されたのは本当にうれしい
    RNやFlutterを使ったことはあるが、常にネイティブらしさの不足が問題だった
    KMPもあるが、たいていの開発者はiOSから始めてAndroidへ広げる
    Swift Packageでコードを共有できれば、この流れはずっと自然になる

    • Android開発者のほうがはるかに多く、配布も簡単
      一方でSwift/Objective-C開発者はずっと少ない
      米国外ではiPhoneのシェアが低く、企業はWindowsやブラウザ中心で考える傾向がある
    • 「iOSから始める」というのは米国中心の視点のように思える
      KMPはすでにGoogle Workspaceのような大規模アプリで使われていて、KotlinとJetBrainsの投資によって成熟度も高い
      Flutterはリリースサイクルが速すぎて追いかけるのが大変だった
    • JavaScriptベースのビジネスロジックも無視できない
      JavaScriptCoreやQuickJSでiOS、Android、Webのすべてで動かせて、ホットリロードも可能
      ただしアプリストアのポリシー上、大きな機能変更は難しく、バグ修正程度に向いている
      モバイルの配布サイクルが遅い現実を考えると、こうしたアプローチには大きな可能性があると思う
    • ProtonではRustで80%以上のロジックを共有し、残りはプラットフォームごとに実装している
    • 実のところ、こうした構成はすでに.NETとMvvmCrossで実現できていた
      共有コアライブラリ + 各プラットフォームのネイティブUIプロジェクトという構成でうまく動く

  • Skip.toolsのブログで見たSKIPトランスパイラに関連するプロジェクトなのか気になっていた
    SwiftUIアプリをAndroidへ持っていきたかったが、RNは避けたかった

    • そう、Skipは1年以上前からSwift SDKのプレビュー版を使っていて、Fuseモードで完全なネイティブSwiftUIアプリをAndroidにビルドしている
      Skipには2つのモードがある: SwiftコードをKotlinへ変換するLiteモードと、Swiftを直接Android向けにコンパイルするFuseモード
      2つのモードを組み合わせることで、Kotlinエコシステム（Lottie、Firebaseなど）との統合も可能
      詳しい比較はSkip Docsで確認できる
      公式SDKが出たことで、これからは独自ビルドではなく公式版を使えるのがうれしい
    • Skipは今回の取り組みの主要な貢献者の1つ
    • これでトランスパイラなしでもネイティブSwift実行が可能になり、互換性もずっと高くなった

  • Swift Embeddedのような単なる概念実証レベルで終わらないことを願う
    Swiftは言語として美しいが、コミュニティのリーダーシップには不安な空気がある

    • guard let self = self else { return } — Swift開発者ならおなじみのジョーク

  • RNとFlutterはもう見たくない
    角張ったUIと遅いタッチ反応にはうんざり

    • Flutterでも角の半径は調整できるし、性能も速い
      反応が遅いのはアプリ実装側の問題である可能性が高い
    • 私もRNとFlutterは好きではないが、Swift on Androidがそれらより良くなる保証はない
      Appleがすぐに興味を失うかもしれない

  • “You got Kotlin in my iOS.”
    “You got Swift in my Android.” — しゃれた表現

    • 完璧なたとえだ。本当にReese’sの広告みたいに、KotlinとSwiftが混ざったハイブリッドが出てくるかもしれない
    • Kotlin on iOSは静的コンパイルされ、Swift/ObjCとネイティブに相互運用できる
      Kotlin Native概要 参照

  • 今回の発表は、新しいSwift SDKシステムの成功証明に見える
    以前は他プラットフォーム対応がCMakeの絡みで複雑だったが、今ではSDKルールに従えばどのプラットフォームにも移植可能になった
    Androidのほか、Linux、wasm、embedded、そして近いうちにWindowsまで拡張予定
    JVMとの相互運用はまだ完全ではないが、プラットフォーム非依存性が高まったのは確か

  • 私はKotlin Multiplatformが好きだが、Swift for Androidも興味深い
    メモリに敏感な処理でSwiftネイティブライブラリを共有するのは有用そう
    ただ、ビジネスロジック全体をSwiftへ移すには、まだKMPのほうが成熟している

    • KMPでデスクトップアプリも作ったことがあるのか、全体的な成熟度が気になる

  • ビジネスロジック共有はすでに解決済みの問題だった
    本当の苦しさは、UIを2回書かなければならないことだった
    React Nativeのように使いづらくない共通UIフレームワークが必要

    • React Nativeは最近New Architectureへ移行してかなり良くなった
      Expoと一緒に使えば開発体験も大きく改善する

  • AndroidとiOSの間で長年コード共有をしてきたが、UI共有は悪夢だった
    複雑なロジックだけをC/C++/Rustで共有していたので、結局言語が3つにもなった
    KMPやSwift for AndroidならKotlin/Swiftだけで共有できるので、ずっとすっきりする
    こうしたアプローチは、UIを無理やり共有するフレームワークよりもはるかに現実的で効率的だ