macOSはWi-Fi Awareの公開APIをまだ開放していない

iPhoneとiPadの間はWi-Fi Aware(NAN)のPublisher/Subscriberで実際に接続でき、往復遅延も実測できました。一方macOS 26のSDKでは WACapabilities.supportedFeatures のようなAPI宣言そのものが利用不可とマークされていて、公開APIの型チェックの時点で先に進めません。実機で確かめた公開SDKの境界を扱います。

Wi-Fi Awareを試した理由

Wi-Fi Aware は、アクセスポイントを介さずに近くの端末同士が直接ピアリングできるフレームワークです。従来のWi-Fiが、同じネットワークに参加したうえでアクセスポイントを経由して通信するのに対し、Wi-Fi Awareは端末同士が直接リンクを張ります。ネットワークへの参加そのものが要らなくなる、というのが構図の違いです。

従来のWi-FiとWi-Fi Awareの通信経路の比較。左は端末Aから端末Bへ送るのにアクセスポイントまで上げて折り返すコの字型の経路、右は端末どうしが直線1本で直接つながる

WWDC25でiOS向けに公開され、Network framework の NetworkListener / NetworkBrowser から .wifiAware サービスとして扱えます。NetworkListener / NetworkConnection / NetworkBrowser は同じくWWDC25の「Use structured concurrency with Network framework」で追加された、async/await前提の新しいAPI群です。低遅延の実測値やペアリングの仕組みが公開APIだけでどこまで動くのか、手元の端末で確かめました。

iPhoneとiPadは実際に繋がった

検証アプリは DeviceDiscoveryUI でペアリングし、Network frameworkの NetworkListener / NetworkConnection でPublisher側とSubscriber側の両方を実装しています。

var isWiFiAwareSupported: Bool {
    WACapabilities.supportedFeatures.contains(.wifiAware)
}

var isServiceDeclared: Bool {
    WAPublishableService.allServices[LabConfiguration.serviceName] != nil
        && WASubscribableService.allServices[LabConfiguration.serviceName] != nil
}

WACapabilities.supportedFeatures にサポート状況が入っていること、WAPublishableService / WASubscribableService にサービス定義が登録されていることをまず確認し、両方が揃って初めて NetworkListener(for: .wifiAware(...)) でリスンを始める作りです。

iPhoneをPublisher、iPadをSubscriberにして接続したところ、双方向でメッセージのやり取りができました。往復遅延はiPhone側の計測で約22ミリ秒、iPad側の計測で約14ミリ秒、連続計測では16ミリ秒前後に収束します。Wi-Fi Awareが「近距離ならではの低遅延P2P」として謳っているとおりの数値が、公開APIだけの実装で確認できました。

macOSでは型チェックの時点で止まる

同じ検証をmacOS側からも試すため、Macから同じサービスにPublish/Subscribeできるかを確認する最小コードを用意しました。

// probes/public-api-availability.swift
import WiFiAware

let supportedFeatures = WACapabilities.supportedFeatures
print(supportedFeatures)

これをmacOS 26 SDK上で型チェックだけ通してみます。

xcrun swiftc \
  -module-cache-path /tmp/wifi-aware-swift-module-cache \
  -typecheck probes/public-api-availability.swift

結果は失敗します。import WiFiAware 自体はモジュール解決に成功するのに、WACapabilities.supportedFeatures という宣言を参照した時点で availability 診断が出ます。実行時エラーではなく、コンパイル前の型チェックで弾かれるので、macOS向けにこのAPIを呼ぶコード自体を書けない状態だと分かります。

同じソースコードのどの行で型チェックが分かれるか。import は両方のプラットフォームで解決し、WACapabilities.supportedFeatures を参照した2行目で iOS は通過、macOS 26 は availability 診断で失敗する

Hacker Newsの議論でも、macOSがWi-Fi Awareの対応デバイス一覧に載っていないという指摘が出ています。今回の検証は、その状況を実際のSDKに対する型チェックで一次確認した記録です。

確認したのは公開SDKの境界だけ

今回の検証は、公開APIの宣言だけを対象にしています。プライベートフレームワークの読み込みや非公開セレクタの呼び出し、システムサービスの改変、非公開のentitlementの要求はしていません。WiFiAware.framework のようなコンポーネント自体はmacOS内に存在しますが、サードパーティーのアプリから公開APIとして触れる経路が今のSDKでは閉じている、という一線だけを確かめました。

iOSとiPadOS側の実装は、そのまま公開APIのリファレンス実装として動きます。Wi-Fi Awareでのペアリングやパフォーマンスモードの指定、アクセスカテゴリの設定を試したいときは、iPhoneとiPad(または2台のiOS/iPadOS端末)の組み合わせであれば公開APIの範囲で再現できます。

再検証する条件

macOS 26時点での結論なので、この境界は今後のSDKで変わる可能性があります。再検証するタイミングは、次のmacOS SDKで WACapabilities や関連する宣言の availability が変わったとき、またはXcodeやSDKの更新でWiFiAwareフレームワークのドキュメントにmacOSが対応プラットフォームとして追加されたときです。判定の起点は毎回、公開APIの型チェックが通るかどうかに置きます。プライベートAPIを迂回して動かせたとしても、サードパーティー配布のアプリで使える経路にはならないため、判断材料には使いません。