トーク

ゲーム開発といえばUnityやUnreal Engineが代表的ですが、学習コストやライセンス費用に不安を感じていませんか？
実はApple純正フレームワークだけでも、ゲーム開発に必要な、接触判定・リアルタイム通信・ランキング・ゲームパッド対応など、実用に足る機能群がすべて揃っています。
さらに最近では、iOSのゲーム体験を高めるための公式機能が充実してきており、ユーザーがゲームにアクセスしやすくなるような変化も見られるため、ゲームデバイスとしてのiOSに注目が集まっています。

このトークは、ゲーム好きですが一般のアプリしか作れなかった私が、純正フレームワークのみでオンライン通信対戦ゲームを完成させ、インディーゲームイベントへの出展を目指した経験をもとに、以下のトピックについてお話しします。

• 使用したフレームワークと用途について
  • SpriteKit：アクションゲームの土台となる描画・アニメーション・接触判定
  • GameKit×GameCenter：オンラインマッチングとリアルタイム通信
  • MultipeerConnectivity：オフラインでも動く対戦通信の構築
  • CloudKit：スコアランキングの保存・共有、セーブ機能
  • GameController：ゲームパッド対応
• インディーゲーム展示イベントへの出展について
  • 出展時の反応や工夫したこと
  • Swift製のアプリの割合

Swiftで業務アプリを作っているあなたも、すでにゲーム開発に必要な材料を持っていたのです──
Apple純正フレームワークだけでもここまで「戦える」ということを、実例を交えてお伝えします。
ゲーム開発は特別なスキルが必要──そんな思い込みを、そっと壊す5分間です。

iOS18でQRコードが生成できない───ッ！？

この事件は、文字列として扱われる16進数を、QRコードにData型として渡せるようにそのまま16進数に変換する際に、nilが返ってくるようになっていたことで起こっていました。
この事件の真相とは如何に。そしてこの問題を解決する過程で得たデータ変換のテクニックとは───

また、第2の事件も勃発します。表示はできるけど読み取れない───ッ！？

QRコードには様々な仕様が存在し、仕様が満たせないと読み取ることができないのです。
しかしiOSにおいてQRコードの生成には一般的にCIFilterのCIQRCodeGeneratorを使用しますが、これはQRコードに含めるデータと誤り訂正レベルしか指定することができません。
どのようにQRコードの仕様を満たせば良いのか───そのテクニックを紹介します。

話すこと

• 16進数関連のデータ型変換
• Foundationの実装変更による影響
• QRコードの仕様を満たすためのデータ変換

Flutter を扱う上でもっとも悩まされる要素のひとつに「状態管理」が挙げられます。

Flutter にはローカルな状態を扱う StatefulWidget とグローバルな状態を扱う InheritedWidget という仕組みが標準で用意されているのですが、これだけでは対処しづらいアプリ開発の課題と解決策が長年議論されてきました。その結果、 Riverpod や Bloc をはじめとするサードパーティのパッケージ（ライブラリ）が開発・公開され、ざっと挙げただけでもその数は 50 をゆうに超えています。

一方で SwiftUI に目を向けると、@State や @EnvironmentObjectをはじめとする標準の property wrapper で状態管理を簡潔に行えるため、追加でライブラリを導入するということは少ないようです。

そんな状況の違いはあれど、「不要になったデータを適切に破棄したい」「非同期処理を伴う状態を過不足なく表現したい」「状態の生成・更新処理を抜き出してテストしたい」といった、「状態管理」という共通の観点において発生する課題には共通する部分も多いはずです。そしてその課題を解決するためのアイデアは多く知っておいて損はありません。

「数え切れないほどのパッケージが存在する」ということは、「数え切れないほどの議論とアイデアがそこで生まれてきた」ことを意味します。このトークでは、そんな Flutter が時間と労力をかけて議論してきた状態管理の課題とその対処法を、「50 を超えるサードパーティのパッケージ」のドキュメントとソースコードを私が読んで得た知識と経験を元に整理して共有します。

それにより、アプリ開発において発生し得る課題と対策案を先回りして知ることができる、そんな発表を目指します。

AIツールをコードレビューに導入してみたものの、期待していたほどの効果を感じられない...そんな経験はありませんか？

CursorやGitHub Copilotなど最新のAIツールを組み合わせることで、ようやく「AIが本当に役立つレビュー環境」を構築できました。重要だったのは、AIに全てを任せるのではなく、AIと人間の得意分野を明確に分けることでした。

このLTでは、実際のiOSプロジェクトのPRを使って、複数のAIツールを連携させたレビューフローを実演します。AIがコードの詳細チェックやパターン検出を担当している間に、人間はアーキテクチャやUX観点での判断に集中する。

この役割分担により、レビュー時間の短縮と品質向上を同時に実現した事例をご紹介します！

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の新たな活用方法として、マルチプラットフォームなゲーム開発という選択肢を探ってみましょう。

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

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

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

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

私は以前、勉強会で "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 の可能性

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を書くことが“公開インターフェース”の設計になる時代に備えて、まずは基本と導入の第一歩を押さえてみませんか？

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

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

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

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

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

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の未来を一歩先取りし、変化を安心して迎えるための材料を共有します。

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

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