プロポーザル

iOSDC Japan 連載4コマ漫画「輝け！俺のViewController」が打ち切r...最終回を迎えたのは、ネタが尽きたからです。
しかし、そんな燃え尽きた俺を差し置いて、Apple Intelligenceは進化を遂げました。

「Apple Intelligencesを使えば無限にネタが出て来ると思うし、自動『輝け！俺のViewController』生成アプリを作ればいいのでは・・・？」

プロンプトに関係なく暴走するAI、足りないAPIで試行錯誤、やばい、デバイスが燃えるほど熱い！あこれ、デバイスあったかいしホッカイロアプリとして使えるのでは...?

AIで「輝け！俺のViewController」は進化するのか？怒涛の5分間、衝撃の結末「刮目」せよ

SwiftUIは年々進化し続け、これまでUIKitに頼らざるを得なかった複雑な挙動も、SwiftUIだけで完結できるようになりつつあります。
例えばScrollView一つとっても、iOS 17では特定のビューへ自在にスクロールできるようになり、iOS 18でスクロール位置の変化を取得し、任意の処理を実行できるようになりました。さらにiOS 26ではLazyStackと組み合わせた際のパフォーマンスが数倍に向上したようです。

しかしプロダクトとしてユーザーのことを考えた時、4年前に登場したiOS 15でも今すぐサポートを終了するのはそう容易ではありません。

このLTでは、OSバージョンによるSwiftUIの機能差やiOS・iPadOS間のプラットフォームの違いに起因する挙動の違い、そしてそもそもSwiftUIでは実現できないことを基に、SwiftUIを諦めてUIKitに頼るべきタイミングを10個ご紹介します！

Swift OpenAPI Generatorは、Appleがオープンソースで開発を主導するOpenAPIから関連コードを自動生成するツールです。このテクノロジーの魅力は、既存のツールと比べてよりSwiftらしい型による安全な表現が実現できる点にあります。
しかしながらSwift OpenAPI Generatorへの移行は必ずしも円滑に進むとは限りません。
APIにリクエストしてからレスポンスを受け取り、それをエンティティオブジェクトにマップするまでの間に、複数のポイントでエラーと向き合う必要があります。

本発表では、その中でも特に多様なエラーをどのように整理し、アプリで統一的に扱うか、その一つの実践的なアプローチをご紹介します。
具体的にはHTTPエラーレスポンス, ネットワークエラー, 特定のオペレーションを実行中に発生するエラーなどから必要な情報を取り出してアプリ固有のエラーに変換する方法、そうしたエラーハンドリングをアプリで画一的に実施する方法、それらの実装の正当性を検証するテストのスマートな書き方をご共有します。

UIKitで作られたアプリにSwiftUIを導入する際の具体的な方法を知りたくありませんか？
開発中のUIKitプロジェクトにSwiftUIを取り入れた経験をお話ししたいと思います。
私たちのプロジェクトでは、ローカル地図機能(NaverMapSDK)を使うために、主要な部分をUIKitで構築する必要がありました。しかし、SwiftUIについて学ぶうちに宣言的UIの魅力に惹かれ、現在のアプリにどう適用できるかを模索しました。
試行錯誤の末、UIKitとSwiftUIを適切に組み合わせた「ハイブリッドな構造」を考案し、幾度かの設計改善を経て、プロジェクトへのSwiftUI導入に成功したのです。
本トークセッションでは、導入にあたっての課題や試行錯誤、そして実際に得られた知見について、実践的な観点からお話しさせていただきます。

<アゼンダ>

• Shucleアプリの概要
  • 使用した技術スタック
  • プロジェクトの構造
• プロジェクトへのSwiftUI導入
  • アプローチ案
  • 最終デザイン案
  • 試行錯誤を含む開発秘話

「一つのコードベースから、複数の異なるアプリを自動生成する」
そんな仕組みが、本当に現実的に運用できるのか？

本セッションでは、ブランドや機能構成が異なる複数のアプリを、単一のSwiftコードベースから自動生成・リリースする仕組みを、設計から実装・運用まで具体的に解説します。

これは単なるテンプレート共有ではなく、iOSアプリを「構成可能なプロダクト」として再設計し、設定情報をコードの外に追い出し、非エンジニアも含めた運用を可能にする仕組みを作る取り組みです。

このセッションでは、以下の実践知を共有します：

・アプリを「構成」として捉える：コードの中に潜む「差分」をどう抽出し、再設計するか
・XcodeGenとFastlaneによる“生成”の自動化：プロジェクト構造の動的生成とビルド・署名の統合
・設定情報をコード外部に逃がす：API経由で注入するApp Metadataとそのセキュリティの考慮
・エンジニア以外でも使えるUI設計：管理画面を介したノーコードな運用ワークフロー
・プロダクトとしての“スケーラビリティ”：技術的負債を生まないための運用と設計戦略

アプリを“作る”という行為を、どうやって“仕組み化”に昇華させたのか。そのプロセスと工夫を、実践ベースでお話しします。

普段開発でCoreLocationを使っていますが、常に位置情報を更新すると多くのバッテリー消費をしてしまいアプリ削除される要因になってしまいます。逆にバックグラウンド時は何もしないと位置情報を扱うアプリでは思うように位置情報の取得ができずに体験を損なうことになります。そこでバッテリーを抑えつつ、必要な情報を取得するTipsをお話できればと思います。具体的に、ジオフェンスの入出、LocationPushの活用、速度に応じたDistanceFilterの可変、AppDelegateのLaunchOptionを活用したバックグラウンド起動時の工夫について詳しく解説します。

iOS アプリで位置情報トラッキングを実装する際、意識すべきなのがバッテリー消費の効率化です。
位置情報を扱うには Core Location フレームワークの利用が欠かせませんが、デフォルトパラメータのまま使用すると、1時間で20%以上のバッテリーを消費することがあります。
特に位置情報をバックグラウンドでトラッキングするような常駐アプリでは、バッテリー消費はユーザー体験に大きな影響を与えるため、チューニングが必要になってきます。

チューニングにあたってはアプリのユースケースに応じた適切なアプローチを選択することが重要です。
例えば、目的地に近づいたら通知を出すようなアプリの場合、位置情報の精度を落とすことでバッテリー消費を低減できますが、精度によっては反応が遅れたり、通知されない問題が出てきてしまいます。

本セッションでは、ユースケースごとにバッテリー消費を抑えつつ位置情報をトラッキングするための最適な方法を、これまでの開発で得た知見を交えてご紹介します。

内容:

• Core Location の基本実装とバッテリー消費のメカニズム
• バッテリー消費を抑えるためのアプローチ
• ユースケース別の実装方法
• バッテリー消費を半減させたチューニング事例

対象者:

• 位置情報を使った iOS アプリを開発している、またはこれから開発を始めようと思っている方
• 位置情報アプリのバッテリー消費に課題を感じ、改善策を探している方

AppleからリリースされたTN3187: Migrating to the UIKit scene-based life cycleにて、全アプリでUIKit based life-cycleからScene-based life-cycleへの移行が必須になることが発表されました。
また、こちらのドキュメントにはScene-based life-cycleに移行しないとアプリが起動しなくなるということも明記されているので、一定数移行作業を行わなければならないプロジェクトが多く存在するのではないでしょうか？

しかしながら、アプリの心臓とも言うべきライフサイクルは、アプリの要件としてイベントの送信やDeepLink周りのハンドリングなど色々な考慮が求められます。
また、当然無事故で移行することが求められ、アプリのデリバリーはブロックしないように実行しないといけない、慎重さとスムーズさを求められるプロジェクトになると考えられます。
このようにScene-based life-cycleへの移行のようにドラスティックな変更が必要になった背景やどのような対策を行わなければならないのか、時間が許せば移行に関するtipなども交えた実践的な内容をお話ししたいと思います。

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とユースケースについて紹介します。
アクセシビリティ対応を始めて、皆さんのアプリをより多くのユーザに届けられるようにしませんか？