プロポーザル

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

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

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

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

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

Pythonで学習したMLモデルをオンデバイスで動かすには、Core ML形式への変換が不可欠です。

Pythonライブラリ coremltools は、TensorFlowやPyTorchなどのフレームワークから.mlmodelや.mlpackageへの変換を Converter で行い、さらに量子化、パレット化、プルーニングなどの圧縮機能を備え、モデルサイズや推論速度を改善してくれます。

本記事では、coremltoolsを使ってオンデバイス用のMLモデルを作成＆実行する過程を、以下の観点で実例を交えながらご紹介します。

• coremltools を用いた変換
• パレット化（LUT化）や量子化、プルーニングによるモデル圧縮手法とその効果
• .mlmodel・.mlpackage の読み書き、柔軟な入力形態設定、Xcodeでの検証活用など開発効率を高めるユーティリティ紹介

これらを通じて以下の知見を皆さんへお届けします。

• モデル圧縮によるファイルサイズの削減・推論高速化・電力効率の向上が即実感できる
• Neural EngineやGPU活用のパフォーマンス利点を具体的に理解できる

GraphQLは、API用のクエリ言語およびそのランタイムであり、単一のAPIエンドポイントに対してクライアントがデータ取得のためのクエリを準備することで、柔軟にデータを取得できます。Apollo iOSは、GraphQLクライアントの実装の一つであり、ApolloはKotlinやJavaScriptを含む多くのプラットフォームでも一般的に利用されています。本記事では、Apollo iOSを用いたクライアントの参考実装を通じて、GraphQL APIの基本概念を学べるようにします。

この記事では、以下のトピックをカバーします。

• データ取得
  • スキーマとその構成要素
  • Queryとリクエスト数を減らす工夫
  • ページネーションを含んだQuery
• その他
  • データ更新（Mutation）と独自のResult型
  • エラーハンドリング

各トピックについて具体的なコード例を交えながら、わかりやすく解説します。この記事を通じて、参加者がGraphQL APIとApollo iOSの基本的な使い方を理解し、実践に役立てることができるようになります。

コードレビューは、チーム開発における品質担保と知見共有のために不可欠なプロセスです。しかし、「何を指摘すべきかわからない」「観点が人によってバラバラ」「レビューに時間がかかりすぎる」といった悩みは、多くのチームが抱える共通の課題ではないでしょうか。

本セッションでは、iOS開発の現場で実際に起きやすいコードレビューのつまずきやすいポイントを整理し、具体的なコードをもとに「どのような観点でコードを見ればよいのか」を実践的に学びます。たとえば、ViewとModelの関心の分離、命名、非同期処理での注意点、コードスタイルの一貫性、パフォーマンスやセキュリティに関する観点などの多角的な視点を紹介します。

また、「良いレビューコメントとは？」「手戻りを防ぐにはどうすればいいか？」といった、設計やコミュニケーションにも関わる問題についても触れ、レビューの“質”を高めるためのノウハウを提供します。

さらに後半では、効率的なレビューを支援する手段として、AIを活用したコードレビューの手法についても紹介します。GitHub CopilotなどのAIレビュー支援ツールを用いることで、開発者はより本質的な設計や意図の確認に集中する「人とAIの協調によるレビュー」の可能性についても紹介します。

このセッションを通じて、コードレビューの観点を整理し、チーム全体でレビューの質と効率を高めるための実践的なアプローチを学べます。このセッションが、明日からのコードレビューを飛躍させるヒントになるはずです。

セッション内容（予定）

• なぜコードレビューはうまくいかないのか
• コードレビューの7つの観点
• コードレビューでのコミュニケーション
• コードレビュー実践ワークショップ
• 技術育成のためのコードレビュー
• チームで更なる生産性を高める
• 生成AIを用いたコードレビューの最適化

iOSアプリ開発のデファクトスタンダードとなったライブラリ管理ツールCocoaPodsは、Swift Package Managerの成熟によりメンテナンスモードへと移行します。その主要リポジトリは2026年にはリードオンリー化が予定されており、事実上の開発終了フェーズに入ることになります。しかし、その影響と功績はAppleプラットフォームに限定されません。

本稿では、CocoaPodsがいかにiOS開発のライブラリ管理を簡素化したかを振り返ります。そして、CocoaPodsがなぜRubyで作られたのかについても掘り下げます。さらに、CocoaPodsのために開発された依存解決アルゴリズム「Molinillo」が、そのインスピレーション源であるRubyの主要パッケージマネージャーBundlerやRubyGemsに採用され、Rubyコミュニティを長年苦しめた依存関係地獄を大きく改善したという逆転現象に焦点を当てます。

CocoaPodsがSwift Package Managerへと主役の座を譲りつつある今、iOSアプリ開発を支え、Rubyエコシステム全体を変革したその物語を紐解き、パッケージ管理の重要性を再考する機会を提供します。

徳島大学で学生の60％以上が使っているiOSアプリ「トクメモ＋」。
本稿では、開発・運用・譲渡までの実践知を共有します。

大学生活の中で感じた「使いづらさ」を、誰も解決しないなら自分がやる。
そんな思いから始まったのが、学内システムを一元化するiOSアプリ「トクメモ＋」の開発です。

「ログインのたびに毎回IDとパスワードを入力」「講義資料・履修情報・時間割がすべて別サイト」など、日々の小さな不便を一つずつ解消することで、口コミを通じてユーザーが増加。大学側のサポートもAPIもない中で、MAU 3500人に使われるアプリへと成長しました。

本稿では「どう作ったか」だけでなく、以下のような実装・運用・引き継ぎの工夫も紹介します：

• WKWebViewを使った大学Webサイトへの自動ログインの仕組み
• GAS・GitHubによるノーコスト運用と引き継ぎ戦略
• DOS攻撃を防ぐための状態設計
• 個人開発アプリとしてユーザーから信頼を得るためのUI/UX構成・計画
• 大学側との交渉の顛末
• アプリ譲渡時に発生するKeychainの技術的課題と解決方法

大学からサポートが無くても、お金がなくても、個人でも、価値あるプロダクトは作れる。
そんな実例として、学生開発や個人開発に関心のある方々にヒントを届けられたら嬉しいです。

Actor境界はSwift concurrencyにおいてデータ競合を防ぐための強力な概念ですが、実際のアプリ開発においてはこれが障壁となることがあります。Actor境界を跨ぐデータの受渡は通常非同期で行われますが、これを同期的に行わなければならないことがあります。例えばレガシーなスレッドベースのAPIを使う場合、引数として渡すコードブロックにおいて、そのActor context外のデータに同期的にアクセスすることが必要になることがあります。

このトークでは、AVFoundationを用いてサウンドを再生する例を題材にして、こうしたケースにおいてもActor境界を安全かつ同期的に跨ぐ方法について説明します。Custom actor executorや、OSAllocatedUnfairLockやMutexといったロックAPIを用いることで、unsafeキーワードを用いることなくActor境界外のプロパティにアクセスし、Swift 6でコンパイル可能な実装方法を紹介します。
Swift concurrencyとともに、どんなAPIも安全かつ効果的に利用できるようになりましょう。

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

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

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

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

SwiftUIでのWebView実装に悩んだことはありませんか？

従来のWKWebView実装では、UIViewRepresentableでのラッピング、複雑なデリゲート処理、状態管理の同期問題など、多くの課題に直面した方も多いでしょう。

これらの問題を解決するために、WWDC 2025で発表された「WebKit for SwiftUI」をご紹介します。

WebKit for SwiftUIを使用することで、WebViewの実装が驚くほどシンプルになり、数行のコードで簡単にWebページを表示できます。
WebPageクラスを活用して状態を監視し、ページの読み込み状況やエラーを自動的にビューに反映させることができます。

また、Observable対応による自動状態管理、宣言的な設定、強力なJavaScript通信機能を備えており、「シンプルなURL読み込み」から「PDF生成・スクリーンショット・アーカイブ保存」まで、実務で必要な機能を簡潔に実現できます。

もはやWebView実装で悩む必要はありません。
新しいWebKit for SwiftUIを活用して、アプリ開発を次のレベルへと進化させましょう。

WKWebViewを介してWebサイトと連携するiOSアプリを開発する場面では、「アプリのWebViewだけうまく動かない」「表示が崩れる」といったトラブルに遭遇することが珍しくありません。そんなとき、多くのiOSエンジニアがまずWebサイト側に原因を求めがちですが、本当にそれは正しいアプローチでしょうか？

本記事では、iOSアプリのWKWebViewを利用した実装で何が行われているのかを段階的に確認することの重要性をお伝えします。たとえば、CSSの上書きをevaluateJavaScriptから行っていると、意図せずDOM構造を壊し、レイアウト崩れや表示フリーズの原因となる場合があります。また、特定のドメインのみUser-Agentを上書きしていたり、MessageHandler経由で何か処理をしている実装があると、同じWebサイトであっても挙動が変わってしまうことがあります。

こうした点をまずアプリ側で整理・把握したうえで、その後にWebサイト側で意図しない挙動になっていないかを切り分けていくアプローチを、簡単な具体例とともに紹介します。

• アプリを再起動するとログイン状態が維持されない
• evaluateJavaScriptでCSSを上書きし、DOM構造が壊れて表示が崩れる
• User-Agentの上書きによってWebサイト側にアクセスを拒否される

「この不具合の原因はアプリ側？それともWebサイト側？」と迷ったとき、どこから調査を始めればよいかを、具体例を通じて掴んでいただければ幸いです。

私はいわゆる“飛行機オタク”で、BoeingやAirbusといった大型旅客機を操縦できるフライトシミュレーターをよくプレイします。
おそらく多くの人が一度は夢見るのではないでしょうか？「本物に近いコックピットを自宅に再現してみたい！」という願望を。
それを実現するための一つの手段として「TrackIR」のような視線トラッキングデバイスがありますが、こちらも価格が高く、なかなか気軽に手を出せるものではありません。そんな中、ある日YouTubeで「iPhoneを使って代替している」事例を見つけ、「これなら自分でもできそうだ」と思い立ち、iPhoneを使った自作の視線トラッキングデバイスアプリを開発してみました。

このトークでは、iPhoneのARKitを使ってリアルタイムでYaw（ヨー）/Pitch（ピッチ）/Roll（ロール）を取得し、それをUDP通信でローカルPCに送信。PC上のOpenTrackというプログラムにデータを受け渡し、最終的にMicrosoft Flight Simulatorに視点データとして連携させるまでの流れをご紹介します。

扱うトピックは以下の通りです：
• ARKitのFace Tracking（ARFaceAnchor）から取得できる顔の姿勢データの活用
• UDP通信の実装
• OpenTrackの仕組み、設定方法
• フライトシミュレーターゲーム（MSFS）と連携した話

このプロジェクトを通じて、ARKitのFaceTracking機能が想像以上に高精度であり、iPhone単体でも本格的な入力デバイスとして十分活用できることを実感しました。
市販のデバイスを購入せずとも、身近なデバイスと少しの工夫で、理想に近い環境を作ることができるという発見は、なかなか面白いトピックだと思います。

モロッコの伝統衣装の美しさと多様性を、日本語でも気軽に体験できるアプリがあったら？
このLTでは、モロッコ文化とモダンなアプリ設計を融合したSwiftUIアプリの構想「KiyanKa」をご紹介します。
MVPでは、ユーザーが写真をアップロードすると、その色や模様からインスピレーションを得たドレスが提案される仕組みをAIで実現。文化的な発見を促す形です。
SwiftUIを使って多言語対応（日本語・アラビア語・フランス語）を実装しながら、AIを活用した小さな工夫で、文化的価値のあるアプリ体験を模索しています。
This talk is an invitation to think about apps not just as tools, but as bridges between cultures.