プロポーザル

去年のiOSDCのパンフレットでは、私は@Environment(.keyPath)について、入門から実践の応用まで、さまざまな活用法を紹介しました。8ページにも及ぶボリュームでしたが、おかげさまで非常に好評をいただきました。

ところがそれが@Environment(.keyPath)の全てだと思いました？いえいえ、@Environment(.keyPath)の底力はまだまだそんなものではありません！

今年は、その更なる高みを目指して、いかに@Environment(.keyPath)を使ってスッキリしたアーキテクチャを作れるか、ご紹介していきたいと思います！刮目せよ、@Environment(.keyPath)の真の実力を！

RealityKit は Apple の 3D フレームワークです。iOS、iPadOS、macOS、tvOS、visionOS で利用でき、特に Vision Pro での 3D 体験の実装に注目されています。

この RealityKit では、Entity Component System（ECS）設計パターンを採用しています。ECS パターンは、ゲーム開発やシミュレーションで広く使われるデータ指向の設計パターンですが、アプリ開発者にとってはあまりなじみがないでしょう。

ECS パターンとは、アプリケーションオブジェクトを Entity、Component、System の 3 要素に分割する設計パターンです。Entity はゲーム世界の中の「物」を表す識別子、Component は Entity に付与する属性や状態、System は Component に対して実行するロジックです。従来のオブジェクト指向では、データと振る舞いをクラスにまとめていましたが、ECS ではデータ（Component）と振る舞い（System）を分離します。このアプローチによって、オブジェクトが軽量になりパフォーマンスが向上します。また、拡張性が高い仕組みでもあり、RealityKit の機能追加は Component の追加という形で行われます。

本記事では、RealityKit の ECS の考え方をコードを挙げながら具体的に説明します。そして、RealityKit の Component を活用する例、特に図形を描画する例をいくつか紹介します。

この内容は、RealityKit に触れたことがない方の入門として、また少し触れたことがある方の理解を深める一助となるでしょう。

iOSDC2021以降、SPMマルチモジュール構成をプロジェクトへ採用するサービスが多く見られます。
マルチモジュール構成では、小さくモジュール分割を行い依存を疎結合に保つことでビルド時間の短縮が期待できますが 画面遷移時にFeatureモジュール同士で呼び出しを行い、依存関係が密結合になっている場合、ビルド時間の短縮が効果的ではありません。

本パンフレットでは、Protocolに各画面の生成処理を記述し、swift-dependenciesを使い遷移先画面をDIする手法を紹介します。
これによって、SPMマルチモジュールにおいて、疎結合な画面遷移が可能となり、ビルド時間の短縮が可能となります。
また、複数のDI手法や画面遷移実装を比較し各手法のメリットデメリットを紹介していきます。

以下の順番に従い、各実装の問題点と解決策を交えながら説明します

• SPMマルチモジュールの導入
• DIを用いた疎結合な画面遷移を可能に
• swift-dependencies を用いたリッチなDI

Skipは、SwiftだけでiOSとAndroid向けアプリを同時に開発できるマルチプラットフォームツールです。
皆さんが愛してやまないSwiftを使いつつAndroidアプリを開発できるなんて、魅力的すぎて日本のiOSアプリ開発者全員が試したいものだと私は確信しています。

しかし国内での導入事例はまだまだ少なく、詳しく解説された日本語での情報はあまり存在しません。また、Skipの進化が凄まじいこともあり、最新の情報を網羅した解説記事もないと思います。

本記事では、実際にSkipを使ったアプリのリリース経験がある筆者が、Skipの基礎から実践的なTips、リリースに至るまでのアレコレを解説します。

これを読むことで即座にSkipを使ったアプリ開発に取り組むことができ、他では得られないSkipの知見を得ることができます。
本記事を通してSkip入門への壁を取り除き、さらなるSkipの発展につながるよう願っています。

WWDC25に現地参加して驚いたのは、非常に多くの人が「Ray-Ban Metaグラス」をごく自然に日常使いしていたことです。まるでスマートウォッチのように、屋内外を問わず装着されており、現地では“次は眼鏡型が来るのでは？”という空気感も強く感じられました。


WWDC後には、MetaとOakleyのコラボによる「Meta HSTN」が正式に発表され、さらに「次はPradaと組むのでは」といった噂も流れています。これらの動きは、WWDC現地での肌感を裏付けるものだと感じました。一方で、これらの製品は日本国内では正規販売されておらず、日本の開発者にとってはまだ“遠い存在”にも見えるかもしれません。

しかし実際には、XREALシリーズをはじめ、日本国内でも購入可能な眼鏡型デバイスは着実に増えており、家電量販店でも普通に見かけるようになっています。これらの製品は、ディスプレイの有無や投影方式（空中映像型、視野投影型など）によっていくつかに分類でき、それぞれ用途や体験にも違いがあります。

本稿では、そうした眼鏡型デバイスの系譜と技術的な分類を整理したうえで、「今、何が使えるのか」「どこまで来ているのか」、そして「この先どこへ向かいそうか」について紹介・考察します。Vision Proのような“没入型”とは異なる方向にある“軽量で日常的な空間コンピューティング”の可能性に、いま改めて注目してみませんか？

モバイルアプリ開発において、アプリに組み込まれた WebView はWeb サイトを表示するだけとは限りません。既存サービスの HTML を活用したり、最軽量かつ最小限のクロスプラットフォームを実現します。これらを制御する場合、HTML や JavaScript などの知識が欠かせません。しかしながら、モバイルアプリエンジニアは必ずしもそれらに精通しているとは限らず、実装上の問題に直面することも少なくありません。

本記事では、アプリに組み込まれた WebView（WKWebView）で遭遇しやすい問題、JavaScript の実行やイベント受信などに関する問題を整理して、その原因と具体的な解決方法を解説します。HTML や JavaScript に不慣れなモバイルエンジニアが、WebView を安全に活用して堅牢なアプリを開発するためのポイントを明示します。また、アクセシビリティの観点についても補足し、誰もが使いやすいアプリを実現するために必要な考え方を紹介します。

2024年、Swift界隈で地域コミュニティイベント Japan-\(region).swift の一大ムーブメントが巻き起こりました。
日本各地でSwiftのコミュニティが発足し、Swiftに関する学びがあるだけでなく、各地域の魅力を発信する場にもなりました。

私も「このビッグウェーブに乗るしかない！」とKanagawa.swiftを開催することに。初めての外向けオープンイベントの主催でしたが、多くの方々の協力のおかげで大成功を収めることができました。

本記事では、Kanagawa.swiftの開催記録と、これからSwift地域コミュニティを立ち上げたい方のための手引きをご紹介します。

さらに、全国のJapan-\(region).swiftマップも提供します！あなたも次に行ってみたい Japan-\(region).swift が見つかるかもしれません！

一見シンプルに見えるUIでも、実装してみると意外と時間がかかる──そんな経験はありませんか？

「このデザイン、30分で実装できそう」と思って始めたら、実際は2日かかってしまった。
そんな見積もりのズレは、デザインの「見た目の複雑さ」と「実装の複雑さ」が必ずしも一致しないことが原因です。

本稿では、SwiftUI・UIKit・Androidでの実装経験や考察から得た知見をもとに、デザイン仕様から実装難易度を読み解くための視点や判断基準を紹介します。

特に以下の観点を中心に、プロジェクト計画や実装方針の見極めに役立つ知見を整理します：

• 標準UIかカスタムが必要かを判断するための着眼点
• テキスト入力やChip、スクロールUIで陥りやすい構造的な課題
• カスタムアニメーションやトランジションの見積もりで考慮すべき要素
• GeometryReaderや座標計算を伴うレイアウトの扱いとその難易度
• 無限カルーセルUIを題材としたSwiftUIとUIKitのアプローチ比較

日々のUI実装における小さな判断を支える技術的な視点を、実例を交えてお届けします。

私はSwiftUI学園２年生のまつじ！

今日は転校生が来るって聞いてたのに遅刻遅刻〜〜！ViewHierarchyを口に挟みながら走ってたら角から出てきたコに...！キャッ！ぶつかっちゃった
もうなんだったの！あいつ！ってイライラしながらホームルームに出席すると...! 転校生ってあいつじゃん!

freddi先生新作。ドタバタ☆恋愛コメディ！始まる三角関係！UIViewControll太くん！私のためにあいつと争わないで〜〜〜〜〜

どっきどき！学園モノ４コマ漫画「SwiftUI学園 ~発動編~」堂々のスタート！

SwiftUIでの開発は、宣言的で簡潔な記述ができる一方で、画面が大規模・複雑になるにつれて思わぬ設計課題に直面することがあります。多くの開発者は、以下のような課題に直面することも多いでしょう。

1. UI構造の可読性の低下
2. コードからデザインの想像が困難
3. 再利用性・コンポーネント化のハードル
4. 状態管理における責務の分離
5. Preview機能の破綻

SwiftUIの宣言的な記法は一見シンプルで強力ですが、実際の開発現場では、構造の複雑化や保守性の低下といった課題が顕在化しやすくなります。たとえば、1つの画面に複数の状態や分岐が含まれる場合、ifやswitchの入れ子が増えてbody が肥大化し、Viewの構造を把握するのが困難になります。また、共通化を目的にViewを切り出しても、柔軟性を持たせようとするあまりPropsが増えてしまい、かえって使いづらくなることもあります。

このような問題に対する1つのアプローチが、「コンポーネント指向」による設計です。UIを意味のある小さな単位として切り出し、それぞれが明確な責務を持つ自己完結型の部品として設計することで、再利用性や可読性を高めるとともに、状態管理の整理にもつながります。

とはいえ、SwiftUIにおけるコンポーネント設計は簡単ではありません。Propsが増えることでかえって複雑になることもあれば、状態やデータフローの設計次第で再利用性が損なわれることもあります。

本記事では、これらのSwiftUI特有の設計課題を整理しつつ、実際の開発の中で見えてきたコンポーネント指向設計の工夫や考え方を紹介します。宣言的UIで複雑な画面を設計している方、構造的なView設計に悩んでいる方の参考になれば幸いです。

2024年7月、徳島で開催された神山.swiftをきっかけに、Chiba.swift、Kanagawa.swift、Osaka.swift、Minokamo.swift、Nagoya.swift...と、全国各地でSwiftの勉強会が広がりました。
この“地域xSwift”の流れは「Japan-\(region).swift」と名付けられ、コミュニティとして活発に動き出しています。

2025年7月には、全国を横断するWWDCまとめイベントやHakata.swiftの開催も予定されています（2025年6月現在）。

本記事では、ムーブメントを生み出したオーガナイザーたちのインタビューや、実際のイベントの写真とともに、この1年間の歩みと、各地で生まれだ“つながり”を振り返ります。

次にムーブメントを起こすのは、もしかしたらあなたかもしれません。全国各地でまた新しい”つながり”が生まれるのを楽しみにしています。