WWDC 2022に向けて、まったく同じ趣旨の記事を昨年すでに書いており、私のトップ3の願いをリストアップしました。ありがたいことに、そのうちの1つ（願い#3）が実際に叶いました。Xcode 14 Release Notesでは、関連する新機能を次のように説明しています：
Simplify an app icon with a single 1024x1024 image that is automatically resized for its target. Choose the Single Size option in the app icon’s Attributes inspector in the asset catalog. You can still override individual sizes with the All Sizes option. (18475136) (FB5503050)
残りの2つの願いはまだ叶っておらず、引き続きウィッシュリストのトップにあります：
#1：CoreDataを将来的に置き換える新しいSwift専用データベースフレームワーク。このようなフレームワークがどう機能するか想像したものをこちらに書きました。詳細はそちらをご覧ください。
#2：Xcode内でのアプリのモジュール化サポート。現在、アプリをモジュール化するために長いPackage.swiftファイルを手動で管理しなければなりません。詳しくはこちらをお読みください。
これらを踏まえた上で、今年のWWDCに対する3つの新しい願いを紹介します。
#3：Swift Chartsライブラリに円形チャートを
昨年の記事の最後に、こう書きました：
過去を振り返ると、2019年のSwiftUI、2020年のWidgetKit、2021年のDocCのように、毎年1つか2つのフレームワークには完全に驚かされてきました。今年は何でしょうか？楽しみでなりません！
それは間違いなくSwift Chartsでした！すべてのアプリがすぐに必要とするわけではないかもしれませんが、多くのデベロッパーがアプリのデータを可視化して、ユーザーに貢献したデータの概要を提供するインスピレーションを得るライブラリです。SwiftUI専用なので、まだすべてのチームが活用できているわけではありません。
Chartsライブラリの最初のバージョンには、1つまたは2つの直線軸を必要とするチャートタイプが豊富に含まれていました。例えば、折れ線グラフ、棒グラフ、さらにはヒートマップも（カスタマイズ可能な状態で）描画できます。Jordi BruinがGitHubリポジトリにスクリーンショットとソースコードをまとめてくれているので、現在何ができるかの概要を把握するのに役立ちます。
しかし、Twitchでのライブ配信中に開発しているオープンソースアプリOpen Focus TimerでSwift Chartsライブラリを実際に使おうとしたとき、作業時間がプロジェクトごとにどう分かれているかを円グラフで表示したいと思いました。しかし、円グラフはChartsライブラリでは現在サポートされておらず、レーダーチャート、ドーナツチャート、サンバーストチャートも同様です。これらは非常に一般的なので、今年のChartsライブラリの第2バージョンにすべて追加されるべきだと思います。
そして来年には、ツリー型のチャート（またはダイアグラム）も追加されるかもしれません。これにより、アプリのモデルレイヤーのUMLダイアグラムの描画、B木などのデータ構造の可視化、機能をより抽象的なレベルで理解するためのインタラクティブな状態機械の構築など、プロフェッショナルなツールの作成に役立つでしょう。そのようなチャートやダイアグラムを活用できるアイデアは十分にあります！
#4：コードを隠すためのXcodeストリーマーモード
コンテンツを共有することは素晴らしいことです。共有されたコンテンツを消費する他の人が新しいことを学んだりインスピレーションを得たりするだけでなく、フィードバックによってコンテンツクリエイター自身が気づいていなかった新しい側面――微妙なバグ、UXの問題、アクセシビリティサポートの不足など――を発見できます。しかし、共有するコンテンツがコーディングプロジェクトに関連する場合、セキュリティと機密性の懸念が生じます。
例えば、サードパーティサービスと連携するオープンソースフレームワークをコミュニティと共有する場合、テスト用の認証情報がリポジトリにコミットされないよう確認する必要があります。さもなければ漏洩して悪用される可能性があります。実は、これはまさに私がオープンソースツールBartyCrouchのSwiftPMで遭遇した状況で、この記事で解決方法を説明しました。
そして、他者から隠したいのはシークレットだけではありません。どの企業も、多大な労力をかけて見つけた製品のコアバリューを潜在的な競合他社に漏らしたくはないでしょう。コピーキャットはビジネスを破壊しうる深刻な問題です。Gitリポジトリの解決策はシンプルです：漏洩すべきでない価値のあるコードはクローズドソースにして、外部と共有しないことです。
写真：Kristina Flour / Unsplash
しかし、Gitリポジトリからシークレットを隠したり、コードベースの一部をプライベートに保つことは話の一部に過ぎません。助けてくれようとする友人や見知らぬ人とのビデオ通話はどうでしょうか？できるだけ多くの作業をライブ配信したいインディーデベロッパー（私のような）はどうでしょうか？実際のアプリケーションのコンテキスト内で特定の問題や解決策を画面共有で見せたい場面は非常に多いのですが、私はそうしていません。機密コードを誤って漏らすリスクが高すぎるのです。これにより多くの可能性が失われています：
インディーデベロッパーとして、クローズドソースアプリのアップデート開発もライブ配信したいのですが、漏らしたくない部分があります。だから私はオープンソースの作業だけを配信しています。非常に残念です。
フレームワークユーザーとして、画面を素早く録画してコンテキスト内での使用状況の動画を共有することで、バグや機能リクエストを報告したいのですが、現状ではデモを準備するのが面倒すぎて報告を省略してしまうことがよくあります。あるいはコンテキストからコードの一部をコピーして、なぜそのようにしているのかを説明するためにいくつもの質問に答えなければなりません。
週次のデベロッパー交流会の参加者として、問題に遭遇した場合は画面を共有して詳細に見せるよりも、抽象的なレベルでコードについて話す方を好みます。画面を共有しても、相手に画面を操作させる（例えば何かを素早く見せてもらうために）ことは絶対にしません。確かに信頼の問題もありますが、私だけではないはずです。
そこで私が望んでいるのは、Xcode内でコードベースの特定の部分を「機密」としてマークし、画面共有時にすべての機密部分が共有画面から隠される機能です。このような機能は、Discordなどのアプリでは「ストリーマーモード」と呼ばれています。実装方法はいろいろ考えられますが、私が想像する仕組みはこうです：
機密コンテンツは配信者には表示されたまま、共有コンテンツに表示されないことをXcodeがハイライトで示す。
コンテンツの「機密」マーキングは、ファイルレベル（ファイル全体が編集される）、型レベル、関数レベル、変数レベルなど、異なるレベルで行える。変数レベルの場合は行全体が隠される。
隠されたコンテンツの名前は表示され（ファイル名/型名/関数宣言/変数名）、本体/値のみが隠される。
「機密」としてマークされたすべてのコンテンツの名前は編集ロックされ、名前の変更によってコンテンツが一時的に漏洩しないようにする。
機密マーキングはGitにコミットできるファイルに保存され、チームの他のデベロッパーも外部との通話で利用できる。
いずれかのアプリが画面キャプチャAPIを使用している場合、ストリーマーモードが自動的に有効になり、デベロッパーが手動で「ストリーマーモード」をオンにするのを覚えている必要がない。これにより、ビデオ通話（FaceTime/Zoomなど）と画面録画（OBS/QuickTimeなど）の両方で機能する。
このような機能がXcodeに導入されることについてはあまり楽観的ではありません。多くのデベロッパーが一般的に述べている問題ではないと感じるからです。ニッチな問題に感じます。しかし私の考えでは、使い始めるまで必要だと気づかず、慣れたら二度と手放したくなくなる機能の1つだと思います。
#5：iPhoneを使ったAR/VR OS開発
Tim Cookは2016年という早い時期からARの可能性について公に語ってきました。Appleが少なくとも丸1年は研究していないものについて語ることはないと仮定すると、Appleは少なくとも8年間AR製品に取り組んでいると言えます。最初のiPhoneの開発には2年半かかりました。最初のApple Watchの開発には3年かかりました。なぜAppleの最初のARデバイスがまだ出ていないのかと問うこともできますが、今年出ると想定しましょう。そしてこの新しいデバイスには独自のオペレーティングシステムが搭載されると想定します。仮に「AR/VR OS」と呼びましょう。
このようなデバイスが発表された場合、デベロッパーにとっての問題がすでに予見できます。すべてのデベロッパーがすぐに新しいデバイスを購入できるわけではありません。金銭的な制約がある人もいれば、第1世代の製品はすべての国で同時に発売されない傾向があるため入手できない人もいます。過去にはこれは大きな問題ではありませんでした。Xcodeには、iPhone、iPad、Apple Watch、さらにはApple TVのシミュレータが付属しています。カメラサポートがないなど一部の制限はありますが、ほとんどのアプリは問題なく完全に開発・テストできます。それは、これらのデバイスすべてが開発デバイスであるMacと共通点を持っているからです：すべてフラットスクリーン上に仮想インターフェースを表示します。
しかしARデバイスは異なります。定義上、「現実を拡張する」ものなので、有用なアプリを適切に開発・テストするには、「拡張する」対象となるカメラフィードにアクセスする必要があります。Appleは位置情報シミュレーションで行ったように、AR/VRシミュレータ用のサンプル仮想環境を提供できるかもしれませんが、Appleがカバーしていない多くのユースケースではかなり制限的で、使いにくい可能性もあります。
代わりに私が望んでいるのは、接続されたiPhoneまたはiPadのカメラフィードを使ってAR/VR OS開発をテストする方法をAppleがデベロッパーに提供することです。技術的な要件であれば、LiDARスキャナー搭載デバイスに制限されるかもしれません。ただし、さまざまな場所で機能をテストするために持ち歩きたいので、ワイヤレスでも動作する必要があります。そのための基本技術は、iPhoneをウェブカメラとして使える連係カメラとしてすでに出荷されています。もしかすると、この機能はもともとAR製品に取り組んでいた社内チームのために構築されたテスト機能の副産物だったのかもしれません。誰にもわかりませんが、これは実現の兆しかもしれません。
さらに重要なのは、AppleにはできるだけAR/VR OSを実機なしでテストできる何らかの方法を提供する動機があるということです。Appleは可能な限り多くのアプリがデバイスをサポートすることを望んでいます。つまり、アプリケーション開発はできるだけ簡単である必要があります。結局のところ、（ユニークな）アプリの存在は、新しいソフトウェアプラットフォームの重要なセールスポイントです。
AIのハイプについて
Xcodeでのより良い自動補完サポートや、やりたいことを伝えればコードを書いてくれるバーチャルコーディングアシスタントのようなものは確かに欲しいですが、まだそこまで到達していないと思います。ChatGPTを試してみましたが、コードを頼むと80%の確率で間違えました。非推奨のAPIを常に使うだけでなく、ビルドできないコードも生成しました。そもそも私が何を望んでいるのか理解していないことも多かったです。
AppleのコーディングSpecializedモデルならより良い結果になるかもしれませんが、「信頼できる」と考えるレベルに近づくことはないと思います。Appleもこれを理解しているはずです。将来このような機能を探求するかもしれませんが、現在のハイプに飛び乗ってXcodeに中途半端なものを組み込もうとしないことを願っています。私は信頼でき、予測可能なツールが好みです。Appleもそうだと思います。しかし技術はまだそこまで到達していません。この方向で何か大きなものが出るのは来年が最速で、今年はあったとしてもごくわずかなものでしょう。
まとめ
以上が、WWDC 2023に対する私のトップ5の願いです。同意しますか？あなたの願いは何ですか？Twitterでこちらから、またはMastodonでこちらからぜひ教えてください。