【注目】Swift 6.3がAndroidに来た。Flutter・KMPとどう違うのか
Swift 6.3が公式Android SDKを搭載してリリース。@c属性によるC連携、Embedded Swiftの進化など主要変更点を解説。Flutter・KMPとの違いも比較する
ニュース
kkm
Backend Engineer / AWS / Django
Swift 6.3で何が変わったのか
2026年3月24日、Appleが開発するプログラミング言語Swiftの最新バージョンSwift 6.3がリリースされました。
今回のリリースで最も注目されているのは、Swiftとして初の公式Android SDKです。iPhoneアプリを作るための言語というイメージが強いSwiftですが、6.3ではAndroid、C言語との連携、組み込み機器（IoT）向けの機能が一斉に強化されました。
Swiftの言語チームでエンジニアリングマネージャーを務めるHolly Borla氏は、公式ブログで「Swiftはソフトウェアスタックの全レイヤーで手に取る言語になる」と述べています。Apple専用言語からの脱皮を明確に打ち出した、戦略的に重要なリリースです。
主な変更点を整理します。
| カテゴリ | 主な変更 | 影響を受ける開発者 |
|---|---|---|
| Android対応 | 公式Android SDK | モバイル開発者 |
| C言語連携 | @c属性で Swift関数をCに公開 | システム/ライブラリ開発者 |
| 組み込み | Embedded Swiftの 大幅改善 | IoT/ファームウェア開発者 |
| パフォーマンス | @specialize, @inline(always)等 | ライブラリ作者 |
| ビルド | Swift Build統合 プレビュー | 全Swift開発者 |
順番に見ていきます。
AndroidアプリをSwiftで書けるようになった
Swift 6.3の最大の目玉は、初の公式Android SDKです。これまでもサードパーティの手段でSwiftコードをAndroidで動かすことは不可能ではありませんでしたが、Appleが公式にツールチェーンとして提供するのは今回が初めてです。
具体的にできるようになったことは3つあります。
まず、ネイティブAndroidアプリをSwiftで書けるようになりました。次に、既存のKotlinやJavaで書かれたAndroidプロジェクトにSwiftのコードを組み込めるようになりました。そして、SwiftからJavaのAPIを呼び出すためのSwift Java / Swift Java JNI Coreという相互運用レイヤーが提供されています。
ただし、現時点ではUI フレームワーク（SwiftUIに相当するもの）はAndroid側には用意されていません。ビジネスロジックやデータ処理の共有が主な用途になります。
マルチプラットフォーム開発という意味では、GoogleのFlutter、JetBrainsのKotlin Multiplatform（KMP）、MetaのReact Nativeがすでにこの領域で先行しています。Swiftの立ち位置はこれらとは少し異なります。FlutterやReact Nativeは「1つのコードでiOS/Android両方のUIを描く」アプローチです。UIの統一は開発効率を上げる反面、ネイティブと比べた描画のもたつきがエンジニアの間で不満の種になっています。SwiftのAndroid SDKはそこには踏み込まず、UIは各プラットフォームのネイティブに任せて、ビジネスロジックだけを共有するKMP寄りの設計を選んでいます。
C言語と直接つながる「@c属性」
もう一つの大きな変更が、@c属性の導入です。
これはSwiftの関数やenum（列挙型）をC言語から直接呼び出せるようにする仕組みです。@c属性を付けたSwiftの関数は、コンパイル時に自動生成されるCヘッダーに含まれます。C側からは普通のC関数として見えるため、既存のCコードベースとの統合がこれまでより格段に楽になります。
なぜこれが重要なのか。世の中のシステムソフトウェア、OS、データベース、組み込みファームウェアの多くはC言語で書かれています。Swiftがこの層と直接つながれるようになったことで、「C言語の一部をSwiftで書き直す」というシナリオが現実的になりました。
さらに、@implementation属性と組み合わせることで、既存のC言語ヘッダーの宣言をSwiftで実装するという使い方もできます。既存のCライブラリを壊さずに、内部実装だけSwiftに置き換えるという段階的な移行が可能です。
カスタムのCシンボル名も指定できるため、C側の命名規則に合わせた関数名で公開できます。既存のCプロジェクトにSwiftを混ぜる際に、C側のコードを一切変更しなくて済むケースもあるでしょう。
Embedded Swiftが「使える」段階に近づいた
Embedded Swiftは、マイコンやIoTデバイスなどリソースの限られた環境でSwiftを動かすためのサブセットです。Swift 6.3では、この領域で実用上の壁になっていた複数の問題が解消されました。
浮動小数点数の表示が可能になりました。FloatやDoubleの値を文字列として出力する機能（description / debugDescription）がC標準ライブラリに依存せず動作するようになっています。組み込み環境ではC標準ライブラリが使えないことが多いため、これまではセンサーの値を画面に表示するだけでも回り道が必要でした。
デバッグ環境も大幅に改善されています。LLDBデバッガでmemory read -tコマンドを使い、メモリ上のアドレスを特定の型として解釈できるようになりました。コアダンプ（クラッシュ時のメモリスナップショット）からDictionaryやArrayといった標準ライブラリの型を検査することも可能です。ARMv7m向けの例外フレーム展開も改善され、スタックトレースの精度が上がっています。
Swift MMIO 0.1.xでは、SVD2Swiftコードジェネレータが導入されました。SVD（System View Description）ファイルからSwiftのレジスタ操作コードを自動生成します。マイコンのハードウェアレジスタを型安全に操作できるようになり、ビットフィールドの設定ミスをコンパイル時に検出できます。
さらに、前述の@c属性はEmbedded Swiftでも利用可能です。組み込みの世界はCが支配的ですから、SwiftとCを自由に行き来できることの意味は大きいでしょう。
ライブラリ作者向けのパフォーマンス制御が揃った
Swift 6.3では、ライブラリやフレームワークを開発する人向けに、パフォーマンスを細かく制御するための属性が3つ追加されました。
@specializeは、ジェネリック（総称型）なAPIについて、特定の型に対する事前特殊化を指示します。たとえばArray<Int>のように頻繁に使われる型の組み合わせについて、コンパイル時に専用の高速なコードを生成しておくことができます。実行時のジェネリクス解決コストがなくなるため、ホットパスの性能改善に直結します。
@inline(always)は、関数のインライン化（呼び出し元に関数本体を展開すること）を保証します。これまでもコンパイラはインライン化を自動判断していましたが、ライブラリ作者が「この関数は必ずインライン化してほしい」と明示できるようになりました。関数呼び出しのオーバーヘッドをゼロにしたい場合に使います。
@export(implementation)は、ABI安定ライブラリ（バイナリ互換性を保証するライブラリ）で関数の実装を外部に公開する属性です。Apple自身のフレームワーク開発では以前から内部的に使われていたものが、一般のライブラリ作者にも開放された形です。
これらは日常的なアプリ開発で直接使う機会は少ないかもしれません。しかし、Swiftのエコシステムを支えるライブラリの性能が底上げされることで、間接的に全開発者が恩恵を受けます。
ビルドとテストの地味だが重要な改善
Swift Buildのプレビューが含まれています。これはSwift Package Managerに統合された新しいビルドエンジンで、macOS、Linux、Windowsなど全プラットフォームで統一されたビルド体験を提供することを目指しています。従来はプラットフォームごとにビルドの挙動が微妙に異なることがあり、CI/CD環境で問題になるケースがありましたが、その解消に向けた一歩です。
Swift Testingも3つの改善が入りました。Warning issues（ST-0012）は、テスト中に致命的ではない問題をseverity: .warningで記録する機能です。テストは通すが注意喚起はしたいという場面で使えます。テストキャンセル（ST-0013）はtry Test.cancel()でテストを中断する機能。画像添付（ST-0014〜ST-0017, ST-0020）はAppleプラットフォームとWindowsでテスト結果にスクリーンショットなどの画像を添付できる機能です。
DocC（Swiftのドキュメント生成ツール）では、Markdown出力のサポート、静的HTMLへのnoscriptタグ埋め込み、コードブロックのアノテーション（nocopy、highlight、showLineNumbers、wrap）が追加されています。ドキュメントの品質向上に地道に貢献する変更です。
マクロライブラリ向けには、swift-syntaxのプリビルトバイナリサポートが追加されました。これによりマクロを含むパッケージのビルド時間が短縮されます。swift-syntaxのビルドは重いことで知られており、開発者体験の改善として歓迎されるでしょう。
開発者コミュニティの評価は割れている
Hacker Newsでは316ポイント、205件のコメントがつき、活発な議論が起きています。
好意的な反応として目立つのは、やはりAndroid公式対応です。「クロスプラットフォーム戦略の重要なマイルストーン」という評価や、医療システムでSwiftをフルスタック（iOS + サーバー）で運用している事例の共有がありました。
一方で、繰り返し指摘されている懸念があります。
コンパイル速度です。「Rustよりも遅いコンパイル時間が開発体験を著しく損なう」というコメントが複数あり、Swiftの長年の課題が依然として解消されていないことがわかります。swift-syntaxのプリビルトバイナリ対応はその一部を緩和しますが、根本的な解決には至っていません。
言語の複雑化も議論の的です。Swiftの元々の設計者であるChris Lattner氏が過去に「Swiftは巨大で超複雑な袋になった」と発言したことが引用され、200を超えるキーワードの存在が問題視されています。新機能が追加されるたびに学習コストが積み上がるジレンマです。
Apple自身の採用状況についても疑問の声があります。Apple社内ではGo、Javaも使われており、自社の言語を社内で徹底的に使い倒す「ドッグフーディング」が不十分ではないかという指摘です。サーバーサイドSwiftの採用は社外でも限定的で、VaporなどのWebフレームワークはドキュメント不足が課題として挙がっています。
Swiftは「Apple専用言語」を卒業できるのか
Swift 6.3を俯瞰すると、Appleが描いている絵が見えてきます。Android SDK、@c属性、Embedded Swift。この3つは方向がバラバラに見えて、実は同じメッセージを発しています。「Swiftはもうアプリだけの言語ではない」ということです。
iPhoneアプリの上のレイヤーから、C言語が支配するシステムの底のレイヤーまで。Swiftが手を伸ばす範囲は着実に広がっています。
ただし、意思表示と実態にはまだ距離があります。Android SDKにはUIフレームワークがなく、サーバーサイドの採用は伸び悩み、コンパイル速度の問題は未解決です。2015年にSwiftがオープンソース化されたとき、Linuxで動くことに興奮した開発者は多くいました。しかしそれから11年、「Apple以外でSwiftを書いている人」が大きく増えたかというと、正直なところ苦しい。
それでもSwift 6.3は、Appleがこの方向を諦めていないことを示しています。C言語の資産を活かせる@c属性と、組み込みの世界で実用に耐えるEmbedded Swiftの改善は、地味ですが着実な前進です。Android対応だけが話題になりがちですが、むしろ技術的に面白いのはこちらでしょう。
Swiftがモバイル、システム、組み込みの全方位で戦える言語になれるかどうか。答えが出るにはまだ数年かかりそうですが、少なくとも6.3は「本気度」を見せるリリースでした。