Swiftの新機能（2026年）: WWDC26アップデート

Appleは1回のWWDCサイクルで2つのSwiftリリースを出荷しました。6.3と6.4が同時に登場し、「What’s new in Swift」セッションは両方を一続きの作業として扱っています¹。この枠組みが重要なのは、変更点が2つの読者層へきれいに分かれるからです。ほとんどの開発者は、より小さな日常的なエルゴノミクスを手にします（anyオプショナルを囲む括弧を省ける、12個もの@availableプラットフォーム名を1つのanyAppleOSにまとめられる、まさに1つの宣言の中だけで非推奨警告を黙らせられる）。一方、パフォーマンスに敏感なコードを書く小規模なグループは、長年待ち望んできた成果を得ます。所有権システムがforループ、計算プロパティ、そして標準ライブラリそのものにまで届くようになったのです。

2026年のSwiftは、クロスプラットフォームかつクロス言語のプロジェクトであることも明確に示しています。Appleはswift.orgを通じて配布される公式のAndroid向けSwift SDK⁶、WebAssemblyによる高速なJavaScriptブリッジング、新しい@C属性によってSwift関数をCへ書き戻してエクスポートする機能、そしてSwift Package Managerをデフォルトで支えるようになったSwift Buildバックエンドを発表しました¹。本記事では、2026年のSwiftストーリーを定義する4つのセッションをたどります。言語とライブラリのアップデート（262）、Swift Testingへの移行パス（267）、gRPCによるリアルタイムサービス（265）、そしてMLX Swiftによる数値計算（328）です。

TL;DR

• Swift 6.3と6.4はWWDC26で同時に出荷されました。日常的なエルゴノミクス: 括弧なしのオプショナルany/some、anyAppleOS可用性、宣言ごとの警告制御を行う@diagnose属性、そして名前衝突に対するモジュールセレクタ（::）です¹。
• 所有権システムが通常のコードに届きました。新しいIterableプロトコルによって、forループは要素をコピーするのではなく借用（borrow）できるようになり、borrow/mutateアクセサがget/setを置き換えて、計算プロパティ内で大きな値をコピーすることを避けます¹。
• 新しい標準ライブラリ型は、古い安全でないパターンの安全な版を出荷します。UniqueArray、UniqueBox、一度だけ再開できるContinuation、そして借用やミューテーションを変数に保持するRef/MutableRefです¹。
• Swift TestingはXCTestと双方向で相互運用できるようになり、4つのモード（limited、complete、strict、none）を備えます。Xcode 27ではデフォルトで相互運用が有効になります²。@Test、@Suite、#expect、#requireの表面は、AppleのSwift Testingリファレンスに記載されています⁵。
• gRPC Swiftは、.protoファイルから型付きクライアントを生成し、単項（unary）に加えて双方向ストリーミングのRPCを得て、クラウド上のLinuxコンテナへデプロイできる段階に達しました³。
• MLX SwiftはNumPyスタイルの配列計算をSwiftにもたらし、自動的なGPU実行とgradによる自動微分を備え、Swift、Python、C++、Cのフロントエンド間で1つのエンジンを共有します⁴。

言語エルゴノミクス: 煩わしさが消える

セッションは「ちょっとした煩わしさが消えること以外にはほとんど気づかないかもしれない」変更点から始まります¹。これらは名前を挙げる価値があります。なぜなら、この言語の10年にわたって積み重なってきた摩擦を取り除くからです。

SwiftチームのBeccaとEvanがSwift 6.3と6.4を解説します。言語セクションは0:45あたりから始まります。

any P?を括弧で囲まずに書けるようになりました。Swift Concurrencyのタスクがスローされたエラーをひっそりと取りこぼすと警告が出るようになり、タスク内で処理するか、タスクを保存して後で確認するよう促されます。deferブロックからasync関数を呼び出せないという古い制約はなくなり、非同期のクリーンアップは、遅延された同期クリーンアップが常にそうしてきたのと同じように実行されます（SE-0493、Swift 6.4）⁷。weak varプロパティのために@unchecked Sendableが必要だっただけのクラスは、そのプロパティをweak letに切り替えることで、適切なSendableチェックの対象になれます。Sendableであるべきでない型は、新しい~Sendable構文で明示的にそう宣言できます。これはサブクラスがSendableになることを妨げません¹。

確実に気づく変更が2つあります。1つ目は可用性です。Appleは昨年OSのバージョン番号を揃えましたが、Swiftはそれをさらに推し進め、すべてのプラットフォーム名を1つのanyAppleOSに凝縮できるようにしました。気にかけているプラットフォーム全体で可用性が一致する場合は、それらをまとめて一度に指定します。例外がある場合は、anyAppleOSをデフォルトに設定し、例外用にプラットフォーム固有の属性を追加します。同じ名前は#if os(...)条件でも機能します¹。

2つ目は@diagnose属性で、1つの宣言の内部で特定の警告の挙動を変更します。新しいAPIへ移行する間、プロジェクト全体で警告を黙らせることなく、1つの関数の中だけでdeprecated declaration警告グループを無視するようSwiftに指示できます。逆方向にも使えます。セキュリティ上重要な関数の内部で厳格なメモリ安全性を有効にしたり、将来エラーになる警告を今すぐエラーへ昇格させたりできます¹。SwiftチームのエンジニアリングマネージャーであるHolly Borlaは、WWDC26を締めくくる際にこれを際立った機能として挙げました。「私のお気に入りの新機能の1つが@Diagnose属性です。これはコード内の警告の挙動を制御でき、たとえば非推奨を抑制するようなことができますが、それだけでなく、より細かい粒度で厳格なメモリ安全性や厳格な並行性の診断にオプトインすることもでき、たとえばSwift 6言語モードへの移行に役立ちます。」⁸ 彼女は6.4リリース全体を同じように位置づけました。これらのアップデートは「摩擦点となるものを取り除く」ことであり、開発者が明快で美しいコードでアイデアを表現することに集中できるようにするものだ、と⁸。

そしてモジュールセレクタがあります。インポートした2つのモジュールがどちらもViewという名前の型を宣言している場合、従来の対処法はドット構文（Rocket.SaturnV）でしたが、Rocketという名前のモジュールがRocketという型も含んでいると、Swiftが型を優先してメンバーを見つけられなくなり、破綻します。Swift 6.3は::を導入します。左側の名前は常にモジュール名であるため、Rocket::SaturnVはモジュールへ直接たどり着きます。このセレクタはメソッド名やプロパティ名でも機能します。Appleのガイダンスは的を射ています。自分が制御していないモジュール間の衝突に使い、マクロ生成コードでは防御的に使うべきですが、意図的に衝突するAPIを設計したうえでセレクタに頼って曖昧さを解消するようなことはしてはいけません¹。

標準ライブラリとFoundation

標準ライブラリは的を絞った追加を取り入れました。タスクキャンセルシールド（withTaskCancellationShield、SE-0504、Swift 6.4）は、キャンセルチェックが常にfalseを返す短い領域を実行します。これにより、周囲のタスクがキャンセルされた後でも、ディスクへの書き込みを完了させるような非同期クリーンアップが実行されます⁷。mapKeyedValuesはキーと古い値の両方をマッピングクロージャに渡し、キーが必要なときにmapValuesが強いていた手作業の辞書再構築を置き換えます。Swift Systemのものをベースにした新しいファイルパス型は、パス表現におけるプラットフォームの違いを扱います¹。

Foundationは、Objective-Cから離れてSwiftへ移行する複数年がかりの作業を続けました。AppleはさらにDataの一部をモダン化し（より高速なspanアクセス、等価性チェック、イテレーション、ミューテーション）、NSURLとCFURLを、より高速で省メモリな単一のSwift実装へ統合しました。ProgressManagerはasync/await向けに作られた新しい進捗報告型です。そしてSubprocessパッケージは1.0に到達し、簡素化された実行型、AsyncBufferSequenceとしてストリーミングされる出力、そして書記素クラスタの境界を尊重しながら出力を1行ずつ読むstrings()メソッドを備えました¹。

所有権が通常のコードに届く

パフォーマンスのストーリーこそ、じっくり読むべきものです。これは、複数年がかりのコンパイラプロジェクトが、日常的な型で使えるものになった瞬間を表しているからです。中心となる問題はコピーです。あるデータが1か所にあり、別の場所で必要になるため、プログラムはそれをコピーします。ストレージが割り当てられたままで、両側がSwiftの排他性ルールに従っていれば、そのコピーは不要です。借用（borrow）は、コピーせずに既存のストレージへの読み取りアクセスを許可します。ミューテーション（mutate）は排他的な書き込みアクセスを許可します。コンパイラはコンパイル時に両方を検証します。これが、生のUnsafePointerでは実現できなかった安全性をこの手法に与えているのです¹。

所有権とパフォーマンスチューニングのセクションは19:55あたりから始まり、インライン化の制御、特殊化、そして新しいアクセサを扱います。

いくつかのプロトコルがコピーなしで動作するようになりました。Equatable、Comparable、Hashableはnoncopyable型で使えるようになり、EquatableとComparableはnon-escapable型へも拡張されます。関連型もnoncopyableまたはnon-escapableにできるようになり、これが目玉機能を可能にしています。それはforループが直接サポートする新しいIterableプロトコルです¹。

誰もが知るSequenceプロトコルは、イテレーションしながら要素をコピーして取り出します。Iterableはループに代わりにそれらを借用させます。つまり、noncopyableな要素で動作し、オブジェクトやcopy-on-write型での参照カウントをスキップします。AsyncSequenceと同じように、イテレーション中にスローすることもできます。借用はミューテーションを禁じるため、排他性チェックによって、ループ中にコレクションをミューテートすることが止められます（Sequenceでよくあるパフォーマンスの落とし穴です）。forループは利用可能ならSequenceを優先し、Iterableへフォールバックします。そしてIterableイテレータは要素を1つずつではなくspanのバッチで返すため、すべてを1つのspanで返せる型に対してループが測定可能なほど効率的になります¹。

アクセサも同じ扱いを受けました。Appleの例は、256個のIntのInlineArrayを保持するUniqueBoxで、64ビットデバイス上では2キロバイトの構造体です。get/setでは、1つの要素を変更すると配列全体をコピーして取り出し、また戻します。この計算プロパティをborrowアクセサ（コピーなしの読み取り専用アクセス）とmutateアクセサ（排他的なインプレース変更）に切り替えると、Swiftは1つの要素をその場で変更でき、型はnoncopyableな値を保持できるようになります¹。

いくつかの新しい標準ライブラリ型は、以前は安全でないコードを必要としていたパターンの安全な置き換えを出荷します。

• UniqueArrayはArrayのように振る舞いますがnoncopyableであるため、noncopyableな要素を格納し、固定サイズに縛られることなく参照カウントのオーバーヘッドを避けます。
• UniqueBoxは新しいアクセサを使う、実際の標準ライブラリ型です。
• Continuationは、ちょうど一度だけ再開することをコンパイル時にチェックするため、CheckedContinuationより安全でありながらUnsafeContinuationと同じくらい効率的です。
• RefとMutableRefは、単一の値に対するSpanのように振る舞います。借用やミューテーションを格納するコンテナで、変数に保持したり、渡したり、返したり、ジェネリック型で使ったりできます。MutableRefは接頭辞の&を付けた書き込みアクセスから構築します。refはnon-escapableであるため、Swiftは変数がスコープを離れるときにアクセスが終わると分かります¹。

UniqueArrayと固定容量のRigidArrayは、新しいContainersモジュール（SE-0527、原則として受理）に存在し、標準ライブラリに落ち着く前でも、swift-collections 1.3を通じて両方とも今日から使えます⁷。

オプティマイザの制御のために、Swift 6.4は長らく存在してきた@inline(never)に対応する@inline(always)を追加し（オーバーライド可能なメソッドはインライン化されないことがあるため、クラスメソッドではfinalと組み合わせてください）、Swift 6.3は@specializedを追加します。これはwhere句によって、最もよく使う具体的な型に対するジェネリック関数の特殊化版を事前生成するようコンパイラに伝えます¹。これらが必要になることはめったにありません。必要になったとき、セッションが言うように「あってよかったと思うでしょう」¹。

Swift Testing: 移行が双方向になった

Swift Testingは、モダンでマクロベース、デフォルトで並列なテストライブラリとしてXcode 16で出荷されました²。2026年のストーリーは移行であり、その鍵となる追加がテストフレームワークの相互運用性です。これは、一方のフレームワークのAPIを、もう一方のテスト本体の中から呼び出す機能で、双方向に使えます²。

Swift TestingチームのJerryが、Swift TestingのテストからXCTestのヘルパーを呼び出す方法を実演します。相互運用のウォークスルーは5:48あたりから始まります。

Appleが推奨する移行戦略は変わっていません。ほとんどのXCTestはそのままにし、新しいテストはSwift Testingで書き、最も頻繁に触れるものを移行します。両方のフレームワークはすでに1つのターゲット内で共存しています。新しいのは、XCTestの上に構築したヘルパーコードを再利用できることです。Swift TestingのテストがXCTFailをラップするassertUniqueヘルパーを呼び出すと、それはクロスフレームワークイシューを生み、Xcodeは今やそれを4つのモードで扱います²。

• Limited: XCTestからのクロスフレームワークイシューは警告になります。Xcode 27より前に作成されたテストプランはこのモードを継承し、swift-tools-version: 6.3のSwiftパッケージはこれをデフォルトにします。
• Complete: これらと同じイシューはエラーのままになります。Xcode 27は新しいプロジェクトでcompleteモードを使います。Swiftパッケージはswift-tools-version: 6.4以降へ上げることでオプトインします。
• Strict: XCTestからのクロスフレームワークイシューは致命的エラーでテストを停止し、XCTest APIを置き換えるべきすべての箇所を指し示します。
• None: 完全にオプトアウトします（これらのイシューは本物のバグを示すことがあるため、一時的にのみ使ってください）。

Swift Testingからのクロスフレームワークイシューはどのモードでもエラーのままなので、XCTestCaseの内部から#expectや#requireを安全に呼び出せます。パッケージでのデフォルトはSWIFT_TESTING_XCTEST_INTEROP_MODE環境変数で上書きします（モード名は小文字です）²。XCTestを扱うセッション262は、対応する標準ライブラリ側を確認しています。XCTestのアサーション失敗は、Swift Testingから呼び出されたときにテストイシューとして表面化するようになり、ひっそりとカバレッジを失うことなく移行できます¹。

移行クックブックは一般的なパターンを扱います。XCTSkipはTest.cancelになります（あるいは、より良いのは、有効化のロジックをテスト本体の外へ移す.enabled/.disabledトレイトです）。continueAfterFailure = falseは#requireになり、これは失敗時にスローしてテストを止めるため、どの失敗が実行を停止するかを期待値ごとに選べます²。相互運用性は、限定的ながらも実用的なAPIセットをサポートします。すべてのXCTestアサーション、両方の期待値マクロ（#expectと#require）、XCTestの失敗を既知のものとしてマークするknown-issue API、そしてXCTestケースをスキップするTest.cancelです²。

API表面そのもの（マクロ、トレイトの語彙、XCTestに残るもの）については、コンパニオン記事であるSwift TestingとXCTestの比較がメンタルモデルを扱います。そこから引き継がれる2つの注意点があります。UI自動化とパフォーマンステストはXCTest専用のままであり、Objective-Cの例外をスローするコードはObjective-Cで書かれたXCTestの中に留めなければなりません。Swiftコードはそれらの例外を安全に扱えないからです²。移行が完了すると、パラメータ化テスト（各引数が個別のケースとなり、すべてが並列で実行されます）と、クラッシュが予想されるコードを子プロセスで実行して終了を検証する終了テスト（exit test）が手に入ります。これらはmacOS、Linux、FreeBSD、Windowsで利用できます²。

gRPC Swift: 型付きのリアルタイムサービス

サーバーのストーリーは、Swiftが今や1つの言語でクライアントとバックエンドにまたがることの最も明確な実証です。gRPCセッションは、.proto仕様から完全に生成された、Swiftサーバーと通信するiOSアプリを構築します³。

Swift ServerチームのGeorgeが4つのRPCタイプを説明します。双方向ストリーミングを含むストリーミングのセクションは11:06あたりから始まります。

gRPCはCloud Native Computing Foundationのプロジェクトで、APIをHTTPエンドポイントではなく型付きの入力と出力を持つ関数として定義し、仕様からクライアントコードを生成します³。ワークフローはこうです。.protoファイルでサービスを定義し、grpc-swift-nio-transport（SwiftNIO上のネットワーキング）とgrpc-swift-protobuf（ビルドプラグイン）をパッケージ依存関係として追加し、GRPCProtobufGeneratorのrun-build-toolプラグインを取り付け、再コンパイルして型付きクライアントを生成します。

ListRacesのような単項RPCは、1つのリクエストを送って1つのレスポンスを得ます。セッションのゴーカートデモは、withGRPCClientでそれをSwiftUIビューに組み込み、その後、SwiftUI環境を通じて単一のクライアントを共有するようリファクタリングしてビューが接続を再利用できるようにし、シーンがバックグラウンドに入ったら切断します³。Protobufはメッセージを、フィールド名ではなくフィールド番号でキー付けしたバイナリへシリアライズするため、メッセージは「同等のJSONメッセージのおよそ半分のサイズ」になります³。これは貧弱なモバイルネットワークでの実質的な利点です。Appleは、同じ効率性が自社のインフラを動かしていると指摘しています。gRPC Swiftはオープンソースの「Containerization」フレームワークにおけるプロセス間通信を支え、Private Cloud Compute、iCloud KeychainおよびPhotos、そしてSharePlayのファイル共有の基盤となっています³。

リアルタイムを可能にするのがストリーミングのサポートです。単項RPCの先には、クライアントストリーミング（多くのリクエスト、1つのレスポンス）、サーバーストリーミング（1つのリクエスト、多くのレスポンス、ライブ実況フィードのようなもの）、そして双方向ストリーミングがあります。デモは双方向ストリーミングをライブのレース更新に使います。クライアントが欲しいイベントタイプをストリームする一方、サーバーが一致するイベントをストリームします。サーバー側では、それはリクエストパラメータがメッセージのAsyncSequenceで、レスポンスパラメータがライターであるasync関数になり、タスクグループとミューテックスで保護された購読中イベントタイプの集合で処理されます³。デプロイはマルチステージのContainerfileです（swift:latestでビルドし、リリースバイナリをswift:slimへコピーします）。HTTP/2を使ってGoogle Cloud Run上で実行し、その後クライアントはトランスポートのセキュリティを平文からTLSへ切り替えます³。

MLX Swift: 数式のように読める数値計算

MLXセッションは、まったく異なる開発者を対象にしています。シミュレーション、信号処理、レンダリング、あるいはモデル訓練を書く人なら誰でもです。MLX Swiftは、NumPyがそうであるように、n次元配列を中心的な抽象として使うため、「ほとんどのNumPyコードは最小限の変更でMLX Swiftへ翻訳できます」⁴。

David KoskiがMandelbrotの例を解説します。素のSwiftとの配列計算の比較は4:28あたりから始まります。

MLXは既存のApple数値スタックを置き換えるのではなく、それと並んで存在します。手作業でチューニングされたCPUベクトルプリミティブにはAccelerate、ニューラルネットワークの構成要素にはBNNS、直接的なGPUカーネルにはMetal Performance Shaders、そしてComplex型にはSwift Numerics、という具合です。MLX Swiftに手を伸ばすのは、目標が「パフォーマンスを意識しながら数式的なコードを書くこと」であり、コードを数式そのもののように見せたいときです⁴。

それを可能にするのが2つの機能です。遅延評価（lazy evaluation）は、配列操作を書くにつれて計算グラフを構築し、evalを呼び出すか値を読み取るまで何も実行しません。だからこそループは各ステップでevalを呼び出してグラフを小さく保ちます。遅延評価はまた、自動的なGPU実行と、grad関数変換を通じた自動微分を支えます⁴。Mandelbrotの例は、ピクセルごとのスカラーループを2行に折りたたみ（グリッド全体に適用されるz = z * z + c、続いて有界なイテレーション回数のカウント）、デフォルトでGPU上で実行され、セッションは「10倍高速も確かに可能だ」と述べています⁴。熱分布ソルバーは、ヤコビ反復を単一のconv2d呼び出しとして表現します。曲線フィッティングの例は、gradを使って手書きの導関数なしに正確な勾配を計算します。これはあらゆるMLモデルの訓練の背後にある考え方と同じです⁴。

MLX SwiftはMITライセンスのオープンソースで、Swift Package Managerを通じてインストールでき、同じ操作と遅延評価モデルを共有する4つ（Swift、Python、C++、C）のうちの1つのフロントエンドです。そのため「Pythonでプロトタイプを作り、Swiftで出荷する」ことができます⁴。このエコシステムには、mlx-swift（コアフレームワーク）、mlx-swift-lm（言語モデルの実装）、そしてmlx-swift-examples（実行可能なLLM、拡散、訓練のサンプル）が含まれます⁴。その周辺にあるオンデバイスMLの文脈については、Apple SiliconでのMLXオンデバイスMLをご覧ください。

まず何を採用すべきか

自分が誰であるかによって、作業の順序を決めましょう。

アプリを出荷していて、コンパイラのパフォーマンスのつまみにめったに触れないなら、今すぐエルゴノミクスを採用し、所有権システムは無視してください。プラットフォームが揃うところでは、積み重なった@available行をanyAppleOSに置き換え、移行の途中にある場所でちょうど非推奨警告を黙らせるのに@diagnoseを使い、依存関係がViewのような名前でSwiftUIと衝突した次の機会にモジュールセレクタ（::）へ手を伸ばしてください¹。

大規模なXCTestスイートを保守しているなら、相互運用性を有効にし、今日からSwift Testingで新しいテストを書き始めてください。既存のテストプランをcompleteモードへ移して、クロスフレームワークイシューを見逃せないエラーにし、XCTestヘルパーを前もって書き直すのではなく相互運用性を通じて再利用し、最も頻繁に触れるファイルを移行してください。UI自動化、パフォーマンステスト、そしてObjective-C例外のテストはXCTestに留めてください¹²。

パフォーマンスに敏感なコードを書くなら、所有権の追加が目玉です。大きな値を保持するホットな計算プロパティを監査し、get/setからborrow/mutateへ切り替えてください。以前UnsafePointerへ落ちていたところでは、Ref/MutableRef、UniqueArray、そして一度だけ再開できるContinuationを検討してください。@inline(always)や@specializedへ手を伸ばす前に計測してください。オプティマイザはたいてい正しく、それを強制するとバイナリがより大きく、より遅くなることがあるからです¹。

作業がサーバーサイドや数値計算なら、新しいパッケージは本番運用に耐える入り口です。gRPC Swiftは.protoファイルから型付きクライアントと双方向ストリーミングを与え、MLX SwiftはGPUで加速される配列計算と、数式のように読める自動微分を与えます³⁴。

FAQ

Swift 6.3とSwift 6.4の違いは何ですか?

Appleは両方を同じWWDC26サイクルで開発・出荷し、一緒に発表しました。大まかには、Swift 6.3はモジュールセレクタ（::）と@specialized属性を導入し、初の公式Android向けSwift SDKを提供しました。Swift 6.4はanyAppleOS可用性、括弧なしのオプショナルany/some、forループ向けのIterableプロトコル、borrow/mutateアクセサ、@inline(always)、Swift関数をCへエクスポートする@C属性、そして組み込みSwiftのデバッグ改善を追加しました。セッションは、この2つを1つの連続した作業として扱っています¹。

XCTestからSwift Testingへ移行しなければなりませんか?

いいえ。XCTestは今も出荷され、今も動作します。Appleの推奨は段階的なものです。新しいテストはSwift Testingで書き、古いものは触れるたびに移行してください。テストフレームワークの相互運用性によって、両者は1つのターゲットで共存し互いのAPIを呼び出せるため、Swift TestingのテストからXCTestヘルパーを再利用できます。UI自動化、パフォーマンステスト、そしてObjective-Cの例外をスローするコードはXCTestに留めてください¹²。

新しいIterableプロトコルはSequenceにできないことを何ができますか?

Sequenceはイテレーションしながら要素をコピーして取り出します。Iterableはforループに代わりに要素を借用させるため、noncopyableな要素で動作し、オブジェクトやcopy-on-write型での参照カウントをスキップします。要素を1つずつではなくspanのバッチで返すため、より効率的であり、イテレーション中にスローすることもできます。借用はミューテーションを禁じるため、ループ中にコレクションをミューテートできません。forループは利用可能ならSequenceを優先し、Iterableへフォールバックします¹。

AccelerateやMetal Performance Shadersではなく、いつMLX Swiftを使うべきですか?

主な目標が、パフォーマンスを意識しながら数式的なコードを書くことであり、自動的なGPU実行とgradによる自動微分を備えてコードを数式のように読ませたいときに、MLX Swiftを使ってください。Accelerateは手作業でチューニングされたCPUベクトルプリミティブの選択肢であり続け、BNNSはニューラルネットワークの構成要素、Metal Performance Shadersは直接的なGPUカーネルアクセスのためのものです。MLXはそれらを置き換えるのではなく、並んで存在します⁴。

gRPC Swiftはバックエンドサービス専用ですか?

いいえ。WWDCセッションはiOSアプリをgRPCクライアントとして構築し、.protoファイルから型付きクライアントを生成して、単項に加えて双方向ストリーミングのRPCがライブのUI更新を駆動する様子を示します。Protobufのバイナリエンコーディングは、同等のJSONのおよそ半分のサイズのメッセージを生み、貧弱なモバイルネットワークで役立ちます。Appleはまた、プロセス間通信のためにgRPC Swiftを使い、Private Cloud Compute、iCloud KeychainおよびPhotos、そしてSharePlayのファイル共有を含むサービスでも使っています³。

Apple Ecosystemクラスター

Swiftの2026年アップデートは、Apple Ecosystemシリーズの残りの部分を貫いています。テストモデルを分解したSwift TestingとXCTestの比較、並行性の変更が触れるSwiftUIにおけるObservableの内部、フレームワークレベルでのSwiftUIは何でできているか、そして数値計算の文脈のためのApple SiliconでのMLXオンデバイスMLです。これらすべてのハブがApple Ecosystemシリーズです。AIエージェントをループに組み込んでiOSアプリを構築することについては、iOS Agent Development guideをご覧ください。

References