プロポーザル

SwiftはiOSやmacOS開発だけでなく、サーバーサイドやLinux環境でも活用されています。このトークでは、そのSwiftを用いてオープンソースゲームエンジンGodotを活用する方法を紹介します。

Godotは軽量でありながら本格的な2D/3Dゲームエンジンです。iOS、Linux、macOS、Windowsプラットフォームへのエクスポートが可能です(※)。Godotの標準言語は独自スクリプト言語GDScriptおよびC#ですが、GDExtensionという仕組みを通じてほかの様々な言語でも開発が可能です。SwiftGodotは、このGDExtensionによってGodotのAPIにアクセスできるようにした「言語バインディング」です。Swiftで直接ゲームロジックを記述できるため、型安全性やモダンな言語機能を活かしながらのゲーム開発が可能になります。
(※ Godot自体はWebや各種コンソール機へのエクスポートも可能ですが、現時点でSwiftGodotを利用した場合での確認がされていないものについては列挙を避けました。)

実際に開発したカジュアルゲームのコードとデモを通じて、SwiftGodotの導入方法や基本的な使い方を解説し、ゲーム開発に踏み出す第一歩をお手伝いします。Swiftの新たな活用方法として、マルチプラットフォームなゲーム開発という選択肢を探ってみましょう。

2025年6月5日、ビル・アトキンソン氏が亡くなりました。彼は初代MacintoshのグラフィックAPI QuickDrawを開発した人物で、MacPaintの開発者としても知られています。本LTでは、彼が1987年に生み出したHyperCardというソフトウェアを紹介します。

HyperCardは、Macintosh用のオーサリングツールです。「カード」と呼ばれる画面を組み合わせて、インタラクティブなコンテンツを作成できました。プログラミング知識がなくても、ボタンやテキストフィールドを配置し、絵を描き、カード間をリンクでつなぐだけで何かを作れます。さらにHyperTalkというスクリプト言語で、より複雑な動作も実現できました。

当時のMacintoshに無料バンドルされていたこともあり、教育現場からアート作品、ゲームまで多様なコンテンツが生み出されました。インターネット普及前にハイパーリンクでカードを繋ぐ概念は、ローカルで動くWWWのようでした。Cyan社の名作ゲーム「Myst」もHyperCardで開発されたことは、その可能性を物語っています。

実際の画面をざっと見せながら、HyperCardがどんなソフトウェアだったか紹介します。カード、ボタン、フィールド、ペイントツール、HyperTalkスクリプト。これらがどう組み合わさって動作していたのか解説します。また、もしスティーブ・ジョブズのApple復帰後も開発が続いていて、幻のHyperCard 3.0がリリースされた世界線はどんなだったか、少しだけ思いを馳せてみます。

Apple Vision Proの登場などにより、3Dの空間表現は身近なものになってきました。RealityKitをはじめとしたフレームワークのおかげで、Swiftで3Dコンテンツを扱うことも簡単になっています。
では、ここからさらに"次元をひとつ上げる"ことはできないでしょうか？

今回はSwiftを使って3Dのその先、4D空間のオブジェクトを描いてみるという、ちょっと変わった挑戦をしてみました。
RealityKitで直接扱えるのは当然3Dまで。そこで数学の力を借りることで、4Dのオブジェクトを無理やり3Dに落とし込んで描画します。
このLTではRealityKitでの3Dレンダリングの基本をおさらいして、そこから次元を上げて4Dレンダリングを実現する方法を紹介したいと思います。
さらに、ドラッグなどのジェスチャー操作で4Dオブジェクトをぐりぐりと動かすインタラクションも実装しました。4D空間を見るだけでなく、触って体感できるデモをお見せします！

難しい理屈は置いておいて、なんだか不思議で見ているだけで面白い。そんな4Dの世界を一緒に体験してみませんか？

身分証をApple Walletをはじめとしたデジタルウォレットに搭載する動きが、近年世界的に広がっています。アメリカでは一部の州において、州発行の運転免許証の搭載が進んでいます。各国での実証実験が進行しており、これらはISO/IEC 18013-5や-7、23220といった国際標準で定められ、セキュリティやユーザープライバシーに配慮しながら世界中で互換性を持たせる動きが進んでいます。
こうした流れの中で、2025年6月24日から、日本でもiPhoneへのマイナンバーカードの搭載が始まりました。Apple WalletにNational IDを搭載するのは、日本が世界で初めての事例であり、デジタル庁とAppleとの協業によって実現されました。
マイナンバーカードを持っていれば、誰でもApple Walletにmdoc（Mobile Document）として搭載することができ、iPhoneだけでさまざまな行政サービスを利用できるようになります。
これに限らず、開発者もAppleが提供するID Verifier APIを使えば、自分のアプリに年齢確認や本人確認といった機能を国際標準に準拠した形で実装することが可能です。たとえば、酒類購入時の年齢確認や、オンライン口座開設時の本人確認など、民間サービスへの応用が期待されています。
このトークでは、「iPhoneのマイナンバーカード」を活用し、アプリ内、対面、ブラウザの3種類のVerifier APIの使い方とユースケースを紹介します。
また、mdocとはそもそも何であるか、そのデータ構造と検証手法など実装詳細にも触れていきます。
さらに、電子証明書をiPhoneから取り出して利用できる日本のために作られたAPIについても紹介しながらBehind the Sceneにも少し触れてみたいと思います。

iOS 26で新たに登場した BGContinuedProcessingTask により、ユーザ起点で開始した処理をアプリのバックグラウンドでも継続できるようになりました。
今までiOSはバックグラウンド制御は大きな壁があり実行に大きな制限がありました。
本セッションでは、このAPIの導入背景や制限の変化を、実際のコードや動作デモを通じて、iOSにおけるバックグラウンド制御の制約に焦点を当てて解説します。

私は、iOSおよびAndroidのアプリエンジニアとして長年の経験を積んできました。
このトークでは、クロスプラットフォームからiOSネイティブ開発に戻る際に直面する課題について、コードベースで具体的にお話しします。以下の内容について詳しくお話しする予定です。

SwiftとDartの言語仕様の違いについて（null安全性や型システム）
Swift Concurrencyの導入による非同期処理のモダン化について（async/awaitやActor）
SwiftUIを用いた宣言的UI実装のFlutterとの差分の実例
FlutterのHot Reload機能に依存した開発体験から、ネイティブ開発に戻った際のギャップと対策

これらのトピックを通じて、フレームワーク間の移行がもたらす技術的および開発体験上の影響について共有したいと思います。

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

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

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

私は以前、勉強会で "noncopyable types" という、 Swift 5.9 で導入された値型で一意なデータ表現を実現するための新たな言語機能ついて紹介しました (https://speakerdeck.com/andpad/about-noncopyable-types)。

上記発表の最後にどういった場面で利用できるかについて紹介しましたが、発表では WWDC 2024 の関連動画 ( "Consume noncopyable types in Swift" ) で言及のあったファイル関連機能を中心とした事例紹介に留まっており、別なアプローチで noncopyable types の利活用シーンを探ってみたいと考えました。

そこで、本記事では noncopyable types と同じような言語機能 ( "Ownership" ) が搭載されている Rust 言語での事例を参考に、 iOS アプリ開発において noncopyable types の利用に適したシーンについて検討した結果をご紹介します。

想定読者：

• noncopyable types は知らないが興味をお持ちの方
• noncopyable types の活用シーンについて模索している方

目次：

1. Swift 言語の noncopyable types について
2. Rust 言語における Ownership について
3. iOS アプリ開発における noncopyable types の可能性

Swift 6がリリースされてからまもなく1年が経過しようとしていますが、数々のUpcoming Feature FlagsやStrict Concurrency Checkingによる影響度合いの大きさからSwift 6モードに完全移行が叶ったプロダクトはまだまだ多くないのではないでしょうか。
そしてそれはOSSとして公開されているライブラリも同様です。

一方、Upcoming Feature FlagsやStrict Concurrency Checkingは段階的に適用させることが可能です。
そしてそれらはPackage.swiftの差分として可視化できます。

本稿では、Swift Packageで公開しているライブラリをSwift 6に対応させるためにPackage.swiftを魔改造した過程を紹介します。

Siri、Spotlight、ショートカット、Widget…。近年のiOSでは、アプリのUIに触れなくても機能を呼び出す手段が増えています。
その中心にあるのが「App Intents」です。
本セッションでは、App Intentsの基本的な仕組みとiOS 18以降で広がった用途を紹介しながら、「今、自分のアプリでどう使えるのか」がイメージできるようになることを目指します。

App Intentsはアプリの機能やデータを構造化して、Siri・Spotlight・ショートカット・Widgetなどから呼び出せる形で公開できるApple公式のフレームワークです。
自然言語や検索、トリガー操作を通じて、アプリを“意図”で動かすための仕組みと言えます。

本セッションは「App Intentsを実際に導入したことがない」iOSエンジニアを主な対象とし、以下の内容をお話しします：

・App Intentsの実装方法
・SiriやSpotlightなど、各文脈でのIntentの使われ方
・iOS 18やiOS 26で追加された新たな統合先（Apple Intelligence・Widgetなど）
・実装時につまづきやすいポイントと回避方法

App Intentsはまだ一般的とは言えませんが、Apple Intelligenceとの統合が進む中でアプリの呼ばれ方・見つけられ方を根本的に変える技術です。
今後、App Intentsを書くことが“公開インターフェース”の設計になる時代に備えて、まずは基本と導入の第一歩を押さえてみませんか？

WWDC24で発表されたSwiftとJavaの相互運用に興味を持ち、Xcode 26とSwift 6.2の環境で試行を重ねています。本トークでは、筆者が入門時に直面した課題や解決策を紹介し、これからSwiftとJavaの相互運用を始めたいと考えている方々がスムーズに学習を進められるよう、具体的なステップとポイントを分かりやすく説明します。特に、開発環境の構築から基本的な相互運用の実装方法、よくある問題とその対処法について詳しく解説します。興味を持っている皆様が第一歩を踏み出す手助けとなれば幸いです。

皆さんのアプリは、アクセシビリティに配慮したアプリになっていますか？
アクセシビリティ対応は、多くのユーザに使いやすいアプリを届けるための重要な要素です。
2025年AppleはApp Storeの製品ページにAccessibility Nutrition Labelsを導入することを発表しました。
これにより、アプリをインストールする前にアプリが対応するアクセシビリティ機能を確認できるようになり、アクセシビリティ対応への注目はますます高まっています。
https://www.apple.com/jp/newsroom/2025/05/apple-unveils-powerful-accessibility-features-coming-later-this-year/

しかし、実際にアクセシビリティ対応に取り組もうと思っても
「対応が難しそう」
「どこから始めればいいかわからない」
「時間がかかりそう」
と感じる方もいるかもしれません。

実は、数行のコードでアクセシビリティ対応を始められます。
本パンフレットでは、そんな開発者に向けてSwiftUIで使用できるアクセシビリティ対応のためのModifierとユースケースについて紹介します。
アクセシビリティ対応を始めて、皆さんのアプリをより多くのユーザに届けられるようにしませんか？

iOSDC Japan 2020 よりパンフレット記事の公募が始まり、私は 2020 からこれまでほぼ毎年のようにプロポーザルを応募してきました。

過去、 1 度だけ同人誌を作った程度で印刷物の制作経験が少ない状態からのスタートでしたが、原稿制作ガイドに記載されている内容を理解した上で納得いくレイアウトへ落とし込めるようになるまでには様々な試行錯誤がありました。

また、社内メンバーと一緒に応募した際にはそれまで個人で利用していたツールとは別なツールに変更して入稿したこともありました。

本記事では、私のこれまでのパンレット記事に関する経験を元に、パンフレット原稿を入稿するまでの流れやパンフレット原稿執筆の魅力についてご紹介します。

想定読者：

• パンフレット記事の執筆に興味があるが「入稿」と聞くと身構えて応募をためらってしまう方
• Adobe InDesign (または Affinity Publisher) を使用して技術記事を書いてみたいとお考えの方
• Re:VIEW を使って A4 サイズで同人誌を作ってみたいとお考えの方

目次：

1. iOSDC Japan パンフレット原稿の特徴 (A4 サイズ、解像度など)
2. Adobe InDesign (または Affinity Publisher) を利用した入稿データ作成
3. Re:VIEW を利用した入稿データ作成
4. パンフレット原稿を書いて良かったこと

少しでも多くの方がパンフレット原稿の執筆にチャレンジするきっかけとなれば幸いです。

iOS 17以降に登場したAssistive Accessは、主に認知障がいのある方々に向けて設計されたアクセシビリティ機能です。
Appleらしい洗練されたUIを保ちながらも、情報量を制限し、最も重要な機能にフォーカスするこの仕組みに触れて、多くの開発者が「UIにおける認知負荷」について再考するきっかけを得たのではないでしょうか。

本セッションでは、認知にやさしいUIとは何か？という問いを出発点に、Assistive Accessが示した設計原則やSwiftUIによるアプリ実装の手法を通して、日々のアプリ開発に活かせる設計の考え方を掘り下げます。
また、iOS 26から導入されたAssistiveAccessシーンタイプやaccessibilityAssistiveAccessEnabled環境値を活用した表示分岐など、SwiftUIでAssistive Accessを取り入れる具体的な方法も紹介します。

さらに本セッションでは、Assistive Accessの背景にある設計思想を心理学やHCI研究の文脈から深掘りします。
認知負荷理論やヒックの法則を手がかりに、「選択肢を絞る」「明確な誘導を行う」といったAssistive Accessの設計要素を理論的に捉え直します。

また、非言語表現の設計や状態変化の制御といった細部にも注目します。
例えば、「アイコン＋ラベル」の併用による視認性向上、操作不能なジェスチャーの排除、破壊的なアクションへの再設計など、認知的ハードルを下げる工夫は通常のアプリ設計にも多く応用可能です。

このセッションを通して、認知に配慮したUIとはどうあるべきかを理論と実践の両面から捉え、支援技術の知見を一般アプリの設計改善へと活かす視点を得ていただければと思います。

アプリ開発において、エラー管理は重要な課題です。多くの場面で Error や NSError を利用した経験がある方も多いのではないでしょうか。

Error は Swift のエラーオブジェクトで、プロトコルとして定義されています。また NSError は Objective-C のエラーオブジェクトで、クラスとして定義されています。NSError を初期化する際には、domain、code、userInfo の 3 つを指定でき、エラーの種別を識別したり、エラーに関する付加情報を追加したりすることが可能です。Error を NSError にキャストしたい場合には、as NSError を用いることで、安全にキャストすることができます。それでは、キャストした際に、Error の情報が NSError の domain、code、userInfo にどのように引き継がれるのでしょうか。例えば、Error が Struct で実装されている場合、NSError に変換した際の code は 1 で固定されます。一方で、Enum で実装されている場合、変換した際の code は case の定義順や associated value の有無によって動的に変わります。

本記事では、Error を NSError に変換する際の振る舞いを LocalizedError や CustomNSError なども交えながら解説します。さらに、この知見を活かし、Firebase の Crashlytics に情報量豊かな非重大ログを送信する方法も紹介します。

Swift 6の導入に苦労している現場が多い中、Swift言語はすでに次のステップへと進み始めています。
Swift 7では5つの「Upcoming Feature Flags」がデフォルトで有効化され、型システム、モジュール設計、並行性の挙動において重要な変化が生じます。
本セッションでは、これらの変更がどのような文脈で導入されようとしているのかを、Swift Evolutionの提案に基づいて読み解きます。

（現時点で）対象とする機能は以下の5つです。
・ExistentialAny
・InternalImportsByDefault
・MemberImportVisibility
・InferIsolatedConformances
・NonisolatedNonsendingByDefault

それぞれの機能は、単なる文法変更ではなく、型安全性・依存性の明示・並行性制御といった観点で、Swiftの設計上の一貫した方向を示唆するものと捉えられます。
本セッションではそれぞれの提案が登場した背景や、過去の関連するSwift Evolutionとの関係性を整理しながら、言語仕様の変化を体系的に理解する手助けを目指します。

また、これらのUpcoming Feature Flagsを事前に有効化する方法として、SwiftPMやXcodeでのフラグ指定方法についても簡潔に紹介します。
日々の開発に無理なく取り入れながら、将来の言語仕様変更に備える知識を得られる構成です。

将来のSwiftを正確に予測することはできなくとも、これらの仕様変更を通じて言語が解決しようとしている課題や、設計上の一貫性を読み解く視点は、日々のコード設計にも役立つはずです。
Swift 7の未来を一歩先取りし、変化を安心して迎えるための材料を共有します。

Xcode は多機能な統合開発環境ですが、日常的に使えるショートカットを把握しているかどうかで、開発スピードとストレスの量が大きく変わってきます。
この記事では、実際に現場で「よく使う」「使うと効率が上がる」Xcodeショートカットを厳選し、一覧形式で紹介します。

以下のような項目を収録予定です：

• 定番ショートカット：ビルド、実行、停止、コメントアウトなど
• ナビゲーション操作：ファイル間移動、シンボル検索、定義ジャンプ
• エディタ操作：マルチカーソル、行の移動・複製、リファクタリング操作
• 便利だけど知られていない操作：UI切り替え、ウィンドウ分割、コードフォーマット
• カスタムショートカットの設定例：個人やチームで使える設定のコツ

初心者から中級者まで、「Xcodeを使っているけれど意外と知らない」という方々に向けて、すぐに試せるTipsとして活用いただける内容を目指しています。

みなさん、Objective-C を書いたことはありますか？
Swiftが登場してはや10年以上が経ちました。
今や多くのiOS開発では Swift が主流になっており、Objective-C に触れる機会は減っているかもしれません。
ですが、世の中にはまだまだ Objective-C で書かれた iOS アプリやライブラリがたくさん動いています。
保守や改修の現場で、避けて通れない場面も多いのではないでしょうか。
Objective-C の経験があると、既存のプロジェクトへの貢献や古いコードの理解が容易になります。特に保守や改修の場面で、そのスキルが役立つことが多いです。

この記事では、Objective-C の基本的な文法を丁寧に解説しながら、最低限の iOS アプリを開発できるレベルになることを目指します。

ショッピングサイトの商品リンクをタップしたら、ブラウザではなく専用アプリがスッと開いて商品ページが表示された体験はありませんか？
この快適なユーザー体験は「Universal Links」という技術で実現されています。

ユーザーにとっては非常に便利な一方、開発ではWebサーバーに apple-app-site-association (AASA) という、アプリとサイトを紐付けるためのJSONファイルを設置する必要があるなど、導入には特有の知識が求められます。
この設定が正しくないと「リンクをタップしてもアプリが起動しない」という問題が発生します。特に、一度設定した後に「変更内容がなぜか反映されない」といったトラブルは、CDNのキャッシュが原因であることも多く、多くの開発者が頭を悩ませるポイントです。
この記事では、Universal Linksの仕組みといった基本から、AASAファイルの書き方、そして「落とし穴」であるCDNキャッシュについても詳しく解説します。

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 に触れたことがない方の入門として、また少し触れたことがある方の理解を深める一助となるでしょう。