プロポーザル

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.

このセッションでは、継続的デリバリーの理想と現実の狭間で、マンガアプリのリリースプロセスに刻まれた
「シュプール」(雪面に残る軌跡) のような、私たちの改善の歩みを実例とともにお伝えします

• Branch Policy
  • Git Flow から Trunk Based Development への移行の過程とそのメリット
  • Code Review と CI の連携を最適化するために実施した取り組み
  • Feature Flag の管理と運用方法の改善
• Versioning Strategy
  • 優先度変更による Version の混乱を乗り越え、わかりやすく迷わない、Calendar Versioning を採用した経緯
  • Release Note 作成の自動化と情報共有の方法
  • Slackbot を活用した差分出力の簡素化
• Release Cycle
  • Release Train を用いた安定的で計画的なリリース
  • 属人化を避けるためのリリースフローとその実施例
  • 予期せぬ事態でも慌てない Hotfix 対応の実践

個人開発アプリでの具体的な経験に基づき、高評価レビューを増やしつつ低評価レビューを効果的に回避するための実践的なApp Storeレビュー戦略について解説します。
潤沢な広告費を持たない個人開発者にとって、App Store Optimization (ASO) はアプリ成長の生命線であり、中でもユーザーレビューはApp Storeにおける検索順位やダウンロード数に絶大な影響を与えます。

本セッションでは、リリース後7ヶ月で10件程度だったレビューを、わずか4ヶ月で170件に増加させ、さらに平均評価を4.5から4.7へ上昇させた成功事例を元に、その秘訣を余すことなく共有します。

具体的には、適切なレビュー訴求のタイミング、ユーザーの感情に応じた分岐、そしてフォームを活用したフィードバック収集と迅速な対応フローを通じて、App Storeの低評価を回避し、平均評価を向上させる方法をデモを交えてご紹介します。

これは、App Storeでの検索順位上昇にも寄与し、自然流入を強化することで、長く愛されるアプリを作るための重要な戦略となります。

私たちが日常でよく目にするバーコード。その裏には、見た目ではわからない微妙な規格の違いが潜んでいることをご存知ですか？

本 LT では、 STORES レジアプリの開発中に直面した「Vision フレームワークが 12 桁のバーコードを 13 桁として認識してしまう」という現象をきっかけに掘り下げた、バーコードの規格と Vision フレームワークの仕様について紹介します！

この現象により、 12 桁のバーコードで登録されている商品をスキャンしても、ヒットしないという問題が発生しました。
Apple の公式ドキュメントでは明示されていない現象で、「なんでや！」と言いたいところですが、バーコードの規格をよく見ると、Vision フレームワークはその規格の性質を利用して、認識していたことがわかりました。
(Google の API はちゃんと認識できるんだけどな…)

本 LT では、以下の内容について話します。

• UPC-A (12 桁) と EAN-13 (13 桁) バーコードの仕様
• Vision フレームワークの認識ロジック
• 正確なバーコードかどうかを判定するロジック
• 回避方法と実装テクニック

1 桁の違いがオペレーションを止めてしまう、現実世界とアプリを繋ぐアプリならではの知見を共有します！
皆さんもバーコードマスターになりましょう！

本セッションでは「あすけんiOSアプリ」における実践事例をもとに、テスト戦略をどう立て、どう現場に根づかせたのかを紹介します。
当社では、テスト運用が属人化していたり、テストが不足していたり、テスト書くこと自体が目的になってしまっていました。
ただ、ユニットテスト、UIテスト、E2E、さらにはスクリーンショットテストとCI/CDの連携など、全部網羅的にやることは現実的ではないです。
そのため、今の自分たちにとって、本当に必要なテストだけを選び取り、属人化を減らしてチーム全体で理解・運用しやすいテスト戦略を目指しました。
昨今の生成AIとの協働も考慮しつつ、テストの設計や現場で工夫したことなど、運用を見直すヒントを提供します。
例えば、AIを活用して、ユニットテストのコードを生成する取り組みなどをやりました。

ただし、試行錯誤は続いているのでうまくいっていない部分も語っていきたいと思います。 「テストはあるけど、なんとなく不安」「CIが形骸化している」「リリースのたびにUI崩れが怖い」
そんな現場にとって、戦略的にテストを設計・運用する事例や考え方を提供する内容になっています。

アジェンダ

1. 背景と課題
2. テスト戦略の再設計
3. テスト運用方法や手法
   • テスト設計
   • スクリーンショットテスト
   • CI/CDなど
4. 生成AIとの協働
   • テスト設計・運用におけるAIの活用例
5. 継続的な試行錯誤と課題

去年 WKWebView 関連の開発をするとき、どうしても解決できない問題を発見しました。

当時作った issue： https://bugs.webkit.org/show_bug.cgi?id=274818 （クリックがランダムで反応しなくなる問題。）

それを頑張って調べて、WebKit のバグだと確認し、WebKit の Bugzilla に提出しました。
WebKit の開発者から、それはすでに別の PR で解決されていると言われ、でも再現できませんでした。

色々試した結果、それは WebKit のテスト用スクリプトに問題があると判明しました。
このスクリプトは、ローカルでコンパイルした WebKit を既存のアプリに取り込んで実行するスクリプトです。
実行する際、必要な環境変数の設定に失敗して、アプリは古い WebKit のままで実行されます。
このバグは将来 WebKit の修正に取り組む皆に影響するので、私は新しい Issue を作って、PR を出して、マージされました。

https://bugs.webkit.org/show_bug.cgi?id=275207
（SIP環境でDYLD_FRAMEWORK_PATHが設定できない問題）
https://github.com/WebKit/WebKit/pull/29578

この LT は、この問題発見から PR を出した流れとその中の面白いところを話します。

iOS 13からUIFontPickerViewControllerが利用できるようになり、アプリ内でフォントピッカーを提供したい場合に簡単に実装を行うことができるようになりました。
またFonts capabilityによってカスタムのフォントも利用できるようになりました。

しかし、これらの仕組みは任意のフォントを自由にシステムにインストールできるというものではありません。
そのため、ユーザーが用意したフォントをアプリ内で利用できるようにするためには、アプリごとにフォントローダーやフォントピッカーを用意する必要があります。

この記事では以下のような内容を紹介します

• iOSで利用可能なフォントの種類とその制限について
• CoreTextのAPIとフォントローダーについて
• CTTextから各種Attributeを取得する方法について
• フォントピッカーとしてフォントの表示・選択を行えるようにする実装について

皆さんはIn-App Purchases(以下IAP)を提供するサービスに関わっていますでしょうか？
IAPによってサービスは継続的に収益を得ることができ、StoreKit 2によって以前よりも簡単に実装が可能です。

IAPを公開するためにはIAP名などメタデータを用意し審査に出す必要がありますが、色々と考慮しなければならない点があります。
・配信国が1つも設定されていないとrejectされます。
・IAPは審査通過した後、自動で公開されるため、配信日時をコントロールすることが不可能であり、公開日より前に審査だけ通しておこう、ということをやると意図せずApp Storeに提供予定の機能が公開されてしまうことになります。
・公開されたIAPは配信国を0にすることでApp Storeより削除できますが、Account Holderしか配信国を削除することができず、権限を持つ人が忙しい場合などは対応が遅れる懸念があります。
などなど…

では、これらの事象に対して我々は何ができるのでしょうか。
このLTではIAPを申請するために必要なこと・注意点や、WWDC25の現地labで質問してきた内容を実際に用いた資料も併せて共有します。
果たして解決策は得られたのか？皆さんに多くの最新情報を共有できたら幸いです。

ゴール:
・IAPの申請に準備が必要な情報や申請作業内容がわかる
・申請時に起こりうる問題とそのワークアラウンドを得られる
・本件についてのlabの回答内容を共有できている

アジェンダ:

1. IAP申請に必要な準備
2. 申請後、実際に起こった問題・ワークアラウンドの紹介
3. WWDCのlabで聞いてみた&回答について

対象者：
・IAPをリリース予定のエンジニア・非エンジニア
・IAPについてあまり詳しくないが興味がある方
・labの様子や回答内容が知りたい方

Stable Diffusion を活用し、既存のキャラクターイラストから新たな創作を展開する制作手法について紹介します。

取り扱うトピック：

• 手描きキャラクターを起点にしたプロンプト生成
• 画像比率の違いによる構図・生成結果の変化
• アウトペインティング（画面からはみ出た体の補完）
• マスク機能（Inpaint）を使った指やパーツの修正
• Image2Image による SD キャラ（スーパーデフォルメ）の生成
• アニメイラストに適したアップスケーラーの選び方
• Stable Diffusion 活用時の権利と、安全なアウトプット設計

アウトペインティングやマスクインペイントといった主要な画像操作手法に加え、アニメ系イラストに特化した高精細なアップスケーリング手法も扱いながら、Stable Diffusion の具体的な可能性をお伝えします。

「なかなか思い通りのイラストが生成されない」
「何度も作り直しているうちに API リミットに達してしまった」

このような経験をしたことのある方も多いのではないでしょうか。
本稿は、そんなみなさんにとっての“救いの一手”となる、とっておきの 2 ページです。