トーク

このセッションでは、皆さんが日々使っているYouTubeやTVerなどで流れる動画広告について、それらがどのような規格に基づいて配信/挿入されているかを簡単なiOSアプリ実装のデモを交えながら説明します。

HTTP Live Streaming (HLS)での動画配信をベースとして、
・ 広告の基本的な配信方式であるCSAI（クライアントサイド広告挿入）とSSAI（サーバーサイド広告挿入）についての説明
・ VMAP/VASTといったような「いつ/どんな広告を配信し、計測するか」の規格の説明
・ SCTE-104/35など放送技術との連携について説明
などを行いつつ、普段はGoogle IMA SDKなどの広告SDKにブラックボックス化されている処理を実際にiOSアプリ/Swiftのコードとして実際書いて動かしてみます。

このトークを通じて、普段ブラックボックスになりがちな動画広告SDKの内部動作を理解し、より高度な動画プレイヤーの実装や、広告関連の問題のデバッグに役立つ知識を身につけることができます。
動画配信サービスの開発に携わる方はもちろん、AVFoundationを使った動画再生の実装に興味がある方にもおすすめです。

対象者：
動画サービスに関わっている方
AVFoundationの基礎知識がある方
動画広告の仕組みに興味がある方

キーワード：AVFoundation, HLS, 動画広告, VMAP, VAST, SCTE-35, Google IMA SDK

【このトークが解決する課題】
Apple Walletに関する議論は、キャッシュレス決済やマイナンバーカード搭載といった、大規模で注目度の高いテーマに集中しがちです。
その結果、多くの開発者や企画者にとって、もっと身近で実装のハードルが低いにも関わらず、ユーザー体験を劇的に向上させる可能性を秘めた活用法が見過ごされています。物理的な会員証、ポイントカード、各種の鍵、チケット…。

私たちの身の回りには、未だユーザーに「不便」を強いているアナログな接点が数多く存在し、それらをどうデジタル体験に昇華させるかという具体的なアイデアの発想方法が共有されていません。
というか使ってるサービスが少なくない？！

【トークの概要と目的】
本トークでは、あえて「決済・航空券・公的ID」という巨大テーマを外し、Apple Walletが持つ真の力を「できること」ベースで一緒に考え直してみましょう。
目的は、世の中によりWalletを取り入れた「面白いプロダクト」の創造です！

具体的には以下の内容を話します

• どのような流れで実装されているのか (5分)
• どのような機能や形式が提供されているのか、HIGを交えて考える (8分)
• 海外ではどのような形のサービスにどういうアプローチでWalletが組み込まれているのか？ (7分)

*セッションの内容ではNDAを遵守します

【このセッションから持ち帰ってもらいたい項目】

• マイナンバーや航空券、クレジットカードといった注目度の高い分野ではないプロダクトで Walletという可能性を視野に入れられる思考
• もっと面白いものが作れそう！という希望

面白いプロダクトを作る一助になれば幸いです！！

iOSでGIFやAPNGなどのアニメーション画像を扱うとき、「UIImageViewにセットするだけでは滑らかに再生できない」「全フレームがメモリに展開されて落ちる」といった経験はないでしょうか？
このトークでは、それらの課題を解決するために開発した軽量ライブラリnoppefoxwolf/AnimatedImageの内部構造と工夫について紹介します。
AnimatedImageはMastodonアプリDAWN for Mastodonのために設計されたハイパフォーマンスなアニメーション画像再生ライブラリです。

AnimatedImageは、標準のUIImageViewと同じ使い勝手を保ちつつ、以下のような特徴を持ちます：

• CADisplayLinkによる正確なフレーム制御
• メモリ消費を抑えるフレームごとのデコードとキャッシュ設計
• 並列デコード処理を活かした描画最適化
• APNG, GIFなど複数フォーマットのサポート

セッションでは、開発にあたっての設計判断、パフォーマンスとの向き合い方、低レイヤーAPI（ImageIO, CGImageSource, CADisplayLinkなど）の活用法を、実際のコード例を交えながら解説します。

「どうやって描画スケジューリングを行っているのか？」「標準APIでここまでできるのか？」といった疑問を持つiOS中上級者に向けて、画像表示の深層に踏み込む内容です。

アニメーション画像に関する知識だけでなく、パフォーマンスチューニングやAPI設計にも興味のある方にとって、学びの多いセッションになるはずです。

スマートフォンの登場がエンジニアのキャリアを大きく変えたように、今、私たちはAIという新たな転換点に立っています。
この変革期において、iOSエンジニアは自らのキャリアをどのように設計すべきでしょうか。

そのヒントは、iOS技術やエンジニアのキャリアにおける"先進性"と、転職ドラフトが提唱するマインドセット「探索型キャリア」の融合にあります。

・エンジニアにおけるキャリア理論
・転職ドラフトスカウトデータが示すiOSエンジニアの市場価値
・iOS技術の強みや将来性
上記3つの観点から、先進性をどう武器にし、キャリアを設計していくべきか体系的に紐解きます。

ウォンテッドリーは、「究極の適材適所によりシゴトでココロオドル人をふやす」をミッションとして、働く人全てに関わるプロダクトを開発しています。モバイルアプリは主にWantedlyアプリを展開し、求職者と企業の最適なマッチングを提供するサービスを提供しています 。
本セッションでは、弊社の開発現場におけるAIの活用状況についてご紹介します。エンジニアリングチームでは、開発効率の向上を目指し、AIツールや手法を日々の業務に取り入れています。
具体的には、コードの生成支援、レビュー補助、ドキュメント作成、さらには技術的負債の解消といった領域でAIを活用しています。これらの取り組みを通じて、AIが開発の様々な段階でどのようにエンジニアの業務を助け、プロセスを改善しているのか、その実態を概要レベルでお話しします。
本セッションを通じて、弊社の事業内容とともに、AIが開発現場にもたらす変化や、エンジニアリング組織がAIをどのように活用しているかについて、皆様に広くお伝えできれば幸いです。

サイボウズの大規模組織向けグループウェア製品『Garoon』のiOSアプリは、初回リリースから約2年が経ち、10万人を超えるユーザーに利用されており、現在も活発に機能追加や改善が進められています。
そのような中で、リリース当初から親しまれてきたトップ画面が、だんだんとアプリ進化のスピードについていくことができなくなってきました。
WebViewで特定機能のページを表示する形になっていたため、他の機能まで遷移するのに手間がかかったり、ネイティブで新たな機能を追加しても導線の実装に苦慮したりといった課題を抱えていました。

そこで私たちは、ネイティブで作成した新しいデザインのトップ画面に置き換えることを決定しました。
今までの操作感や体験を損なうことなく、ユーザーがスムーズに移行できるような仕様を考えながら、段階的に移行を進めていきました。
最終的には、ロールバック率5%未満という数字で、多くのユーザーに受け入れられた状態で移行することができました。

このトークでは、Garoonモバイルチームが取り組んできた以下のトピックを紹介します。

• チーム体制と意思決定
• デザイン検討
• 採用技術要素
• ユーザーからのフィードバック収集と対応

このトークが、今後皆さんが大規模なUI刷新を行う際の助けとなれば幸いです。

ビジネスチャット「Chatwork」を提供する株式会社kubell（旧Chatwork株式会社）では、iOSDC Japan 2023で「SVVS」に関する発表を行いました。
あれから2年、Swiftの進化とともに、私たちの実装も大きく前進しています。

本セッションではその続編として、最新のSwiftを活用した「SVVS実装戦略」をお届けします。進化の過程で、私たちは以下のような課題に向き合ってきました。

・アプリ全体で有効なものと、ログイン中にのみ有効なもののライフサイクル設計
・CombineからObservationへの移行とその影響
・DIを用いたUIロジックの単体テスト手法

これらの課題に対するkubellでのアプローチを、具体的なコードの変遷とともにご紹介します。

WebPは、画像に対する高品質な可逆圧縮と非可逆圧縮を実現する、モダンな画像形式です。
WebP画像形式は同品質のPNG画像より約23〜26%小さく、非可逆圧縮の場合はJPEG画像より25〜34%小さくできるため人気の画像形式です。

iOS 14から標準でWebP画像の読み込みがサポートされ、UIImageで直接WebP画像を扱えるようになりました。

では、今から新しくWebP画像を扱うライブラリを作るということは無意味でしょうか？いいえ、そんなことはありません。自分で作るという行為は動作の原理や仕組みを学ぶことに非常に優れた手法です。

学習だけでなく実用の面でも、自作の場合は特定のユースケースに処理を最適化してパフォーマンスを発揮したり、標準のライブラリで発生する問題を回避できます。特にiOS 18では標準の方法では特定のケースでパフォーマンスが大きく悪化する問題があることがわかっています。

この講演ではWebPファイルフォーマットの基本仕様と構造、Swiftで構造を解析する方法、画像を圧縮する技術の原理と仕組みをステップバイステップで実際のコードを用いて解説します。

WebPのコーデックを実装することは「画像圧縮の理論」「ビット操作の職人技」「高速化・安全化の実務」を一気に学べる実践的な場です。特にSwiftで実装する場合は安全なメモリ管理と低レベルの最適化の両立というノウハウまで得られます。

普段のプログラミングとは一味違う、低レイヤーの実装を楽しんでみませんか？

Swift で日時・数値・名前などの情報を String との間で変換（フォーマット）してくれる仕組みのひとつである「FormatStyle」は、2021年の Swift 5.5（iOS 15.0 等）から使えるようになりました。

これまでのフォーマットでは Objective-C ベースの DateFormatter・NumberFormatter といったものを使ってきました。これを Swift のプログラムから使おうとするとき、高度なカスタマイズについて学習する必要があったり、型安全性などのコンパイラの支援が足りなかったり、また Formatter 自身のキャッシュについて考慮する必要もあったりと問題も抱えていました。

新しい「FormatStyle」は Swift ベースで構築されており、それらの問題へアプローチされパフォーマンスが良いとされています。また、フォーマットしたい形式を SwiftUI の View の Modifier のようにチェーン式で記述してカスタマイズするインターフェイスを備えています。

一方で、従来の Formatter とは使い方が異なるため、これまでと同じフォーマットを FormatStyle を使うように移行する際に、混乱しているようすも見受けられます。

登場から4年経った今、FormatStyle へ移行するのにぴったりな時期が訪れました。このトークでは、Swift でのフォーマットについてこれから勉強される方や、従来の Formatter からの移行を検討している方、移行に困っている方などを対象に、FormatStyle の使い方、カスタマイズの仕方、作り方について述べます。さらに、従来の Formatter との比較や、移行の際の考え方・勘所のノウハウ、そして FormatStyle の内部実装についても解説します。

iOSアプリにおいて Bluetooth 接続のレシートプリンターで印刷するにあたって、私は各メーカーのSDKに頼らず、 Foundation Framework に含まれる Stream API を使用したアプローチを採用しています。
複数メーカー製プリンターを共通の仕組みでサポートするためのプロトコルを定義し、 OutputStream に印刷データを書き込むことでレシート印刷を実現しました。

この方法は、各メーカーSDKの仕様変更や機能差異に左右されにくいという大きなメリットがあります。
一方で、 Stream API の仕組みや Bluetooth を使用したiOSアプリとレシートプリンター間通信の特徴を正しく理解していないと、私が実際に経験したように「印刷が途中で止まってしまう不具合」に遭遇することもあります。

本トークでは、レシートプリンターとの通信に必要な Stream API の基本知識を整理しつつ、複数メーカー製プリンターを共通の仕組みで制御する方法、そして印刷が途中で止まってしまう不具合の対処法について具体的に紹介します。

トーク内容
・Stream API でバイナリデータを送受信する方法
・レシートプリンターの特徴と Bluetooth 接続方法
・レシート印刷に必要な技術的な構成
・複数メーカー製プリンターをサポートする仕組み
・印刷が途中で止まる不具合と Stream.Event を用いた対処法

本トークは、iOSアプリでレシート印刷をしたことがない方はもちろん、これから実装したいと考えている方にも楽しんでもらえる内容です。
本トークのテーマであるレシート印刷の内容を通してバイナリデータ通信全般に応用できる技術知見をお届けします！

長年にわたり、みてねiOSアプリにおいて、写真/動画のアップロード中にアプリを開き続けていないとアップロードが中断されてしまう課題に直面してきました。
具体的にはiOSのバックグラウンド実行の30秒制限により、アプリが中断されるとアップロードが停止してしまう問題です。このトークでは、アプリをバックグラウンドに遷移させてもアップロードを完了まで継続できるようにするために実施した解決策、経緯、そして今後の展望について紹介します。

解決策としては、アップロード中にバックグラウンドに遷移した際、ピクチャインピクチャ機能を活用してアップロード進捗を表示することで、バックグラウンド制限を突破しました。このトークでは、そこに焦点を当ててつつそこまでの経緯/苦戦したところ/制限についてお話しします。

• 正攻法であるBGProcessingTaskをなぜ採用しなかったのか
• ピクチャインピクチャによるアップロードの制限
• ピクチャインピクチャのUIカスタマイズの限界
• バックグラウンド遷移時に自動的にピクチャインピクチャを表示するための方法 / 苦戦したところ
• Appleのレビューを通過するための検証
• 特許の出願
• iOS26のBGContinuedProcessingTaskへの移行の可能性とその準備

このトークを通じて、同様の課題に直面している開発者の皆様に有益な情報を提供できれば幸いです。

あなたのiOSスキルを使って、もっと多くのユーザーにアプリを届けられたら、素敵だと思いませんか？本セッションでは、ソニーのアプリチームがなぜKotlin Multiplatform（KMP）& Compose Multiplatformを選択したのか、どのように既存のスキルを最大限活用したのか、そして実際の開発で得られた貴重な学びを詳しくご紹介します。KMPにより、iOSとAndroidの両方で迅速かつ高品質なアプリを実現し、開発の可能性を大きく広げました。
クロスプラットフォーム開発に興味はあるけれども、iOS開発のクオリティを維持したい方に最適な内容となっています。ぜひご参加ください！

株式会社ヤプリは、ノーコードアプリプラットフォーム「Yappli」を提供しています。
1つのコードベースから約900アプリを生成しているため、レイアウトを含むアプリの構成情報は全てサーバーから取得しています。

その中で、多種多様なデザインニーズに素早く応えるため、より柔軟で再利用性の高い画面構築基盤「Block UI」をゼロから設計し、まるでフルスクラッチでアプリを開発したようなリッチな表現を可能としました。
開発においては、SwiftUIの特性を活かす設計、型安全性と柔軟性の両立など、数多くの技術的課題に向き合ってきました。

本セッションでは、プラットフォームの進化と共に生まれたBlock UIのアーキテクチャについて、以下の観点から実践的な知見を共有します。

• プラットフォーム課題の解決: データとレイアウト分離による「機能数×レイアウト数」から「機能数+レイアウト数」への実装コスト削減
• Block UIのコアコンセプト: 6つの階層での構造化設計と3つのAPIへの分割戦略
• SwiftUIでの実現: 型安全性と柔軟性を両立させるViewの設計パターン

Server-Driven UIに興味のあるiOSエンジニア、SwiftUIでの大規模アプリ開発に取り組む方、また汎用アーキテクチャの設計と運用課題に向き合っている方に向けて、実践的で具体的な技術的知見をお届けします。

ABEMAのiOS・Androidモバイルアプリ開発では、2020年頃からKotlin Multiplatform（KMP）の検証を開始し、段階的に導入を進めてきました。現在では、サービスの中心となる画面の多くの実装がKMPによって共通化されている状態になっています。

マルチプラットフォーム開発の選択肢としてKMPが注目される一方で、長期にわたり大規模なサービスで運用してきた事例は多くありません。本セッションでは、私たちのチームにおけるKMP導入と運用の約5年間を振り返り、以下のようなトピックについて具体的な事例を赤裸々にご紹介します。

• KMP導入の背景とプロセス、直面した課題
• チームの実装効率は向上した？
• UI、ロジック、通信…どこまで共通化するべき？
• KMPを活用しながら、Swift 6の新機能やSwiftUIの導入をどのように進めたか
• KMPは他のチームや開発者へおすすめできる？

KMPの導入を検討している方・実際に使われている方はもちろん、アプリ開発へのマルチプラットフォーム技術の導入に関心のある全ての方の参考になるように、具体的で実践的な事例をお話しします。

炎上の中リリースされ、
長い間メンテナンスされず、
当時の担当者もチームに不在。

アーキテクチャも成立しておらず、
ソースコードはスパゲッティ、
テストコードはもちろん書けない。

私は、そんなレガシーなアプリのリニューアルプロジェクトにアサインされたAndroidエンジニアです。
iOS未経験の立場でチームのリードとしてiOS版の技術的な意思決定にも関与することとなりました。

Androidエンジニアとしての知見をベースに
・リアーキテクト
・ユニットテストの整備
・SwiftUIの導入
・生成AIとの協働
をiOSアプリで実現するまでの取り組みをお話しする予定です。

少しイロモノなトピックかもしれませんが、レガシーから脱却するために効いた取り組みの事例が、皆さんのエンジニアリングの参考になればと思います。

サブスクリプションの機能をアプリに導入する際に、ペイウォール（サブスクリプションの登録を促す画面）のデザイン、文言、表示タイミングで悩んだことはありませんか？Human Interface Guidelinesにはアプリ内課金についてのドキュメントがあり、自動更新サブスクリプションに関してはデベロッパー向けのドキュメントがあります。ペイウォールをガイドラインに沿って設計することは、サブスクリプションの機能をリリースするための前提です。しかし、そのことと、ペイウォールが効果的であることは別の事象です。ガイドラインに沿っていたとしても、ペイウォールを前にしたユーザが好意的に受け取るとは限りません。

では、効果的なペイウォールとはどのようなものでしょうか？世界中のアプリの中から、サブスクリプションの機能があり、かつ売上も十分に立っている人気アプリを、リージョンとカテゴリを分散させて100個ピックアップし、実際のペイウォールを気合いと根性で分析しました。

本セッションでは、まず前提であるアプリ内課金が従うべきHuman Interface Guidelinesに軽く触れます。次に100個のアプリのペイウォールを以下の7つの観点から分析した結果とその考察を共有します。そして、それらを踏まえて実際のアプリに適用して得られた結果をお伝えします。最後に、ペイウォールを設計する際に重要となる心得および今日から使えるTips集を紹介します。

分析の7つの観点
（1） UIの構成要素
（2） 情報量・情報強度およびレイアウト
（3） コピーライティング
（4） 訴求ポイント
（5） 価格とプランの構成
（6） ペイウォールを表示するタイミング
（7） 無料の機能群と有料の機能群の比率

私はいわゆる“飛行機オタク”で、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単体でも本格的な入力デバイスとして十分活用できることを実感しました。
市販のデバイスを購入せずとも、身近なデバイスと少しの工夫で、理想に近い環境を作ることができるという発見は、なかなか面白いトピックだと思います。

Apple Watchのようなリソース制約が厳しいデバイスで、音・振動・UIアニメーションをリアルタイムに動かし続けるにはどうすればいいのか？
watchOSを使った開発では、シミュレーターでは軽快に動いても実機では長時間安定して動作しないことが多々あります。

私がwatchOS向けのメトロノームアプリを開発した時はwatchOSでリアルタイムな処理を安定させるための設計が欠かせませんでした。

本発表では、watchOSで高負荷な処理を安定して動かすための設計とパフォーマンスチューニングの実践知見を、背景から具体的な施策事例まで解説します。

具体的には

• AVAudioEngineの基礎知識とwatchOS実機での注意点
• watchOSにおける触覚フィードバック(WKHapticType、SensoryFeedback)の概要
• 音・振動・UIアニメーションを同時に動かすタイミング制御の実装
• 実機で発生しやすい処理落ち・中断のパターンと防止策
• AVAudioEngineをwatchOS上で効率良く動かすためのパフォーマンス改善施策

について詳細に話します。

また、実用に耐えるようにチューニングが成功した証としてメトロノームアプリで練習した作品をチューバで実演奏します。

Apple Watchで高負荷なリアルタイム処理に挑む方へ向けて役立つノウハウをお伝えできれば幸いです。

「アプリにリアルタイム通信を導入したいけれど、サーバ構築の学習コストや使用するライブラリ選定に不安がある」──そんな理由で導入をためらった経験はありませんか？
iOSアプリエンジニアの私もゲーム開発で同じ壁にぶつかりましたが、「標準技術であるApple純正フレームワークだけでリアルタイム対戦アクションゲームを作り上げる」という道を選びました。
そして今、 Wi-Fiなどを利用したオフライン環境での端末間通信技術への関心が高まっており、インターネット接続に頼らないリアルタイム連携の可能性が広がっています。

このトークでは、私が個人開発したSpriteKit製の対戦アクションゲームを題材に、Apple純正技術を活用したリアルタイム同期の構成や設計の工夫を紹介します。

• GameKit × GameCenterを用いたオンライン対戦のマッチングと通信設計
• MultipeerConnectivityを用いた近くの端末とのオフライン通信の構築
• 通信方式の通信範囲、レイテンシなどの比較と選定ポイント
• アクションゲームにおけるプレイヤー座標やダメージ処理を例にしたデータ同期設計

また、トークでは実際のゲームを用いたデモを通して、通信方式の違いがユーザー体験に与える違いをご覧いただけます。
「サーバ構築せず、Apple純正フレームワークだけでここまでできるのか！」という驚きとともに、「自分のアプリにもリアルタイム通信を組み込みたい」と感じてもらえるような、実践的なトークをお届けします。

2025年2月、AppleはビルドシステムのSwift Buildをオープンソース化しました。
Swiftコンパイラに始まり、xcodebuildやSwift Package Manager、swift-driver、llbuild、果てはClangやldまで、Swiftのビルドを支えるツール群は多様で、それぞれの役割もわかりづらいです。

この複雑怪奇なシステムたちはどのように協調・動作しているのでしょうか。

このトークでは、オープンソースSwiftを中心に、Swiftビルドシステムの全体像を解説します。また、今回新しく公開されたSwift Buildの内部を紐解き、ビルドパイプラインを駆け抜けましょう！

• コンパイラの基本、ビルドとリンクのおさらい
• Swiftのビルドを支えるツールたち
• XcodeプロジェクトとSwift Packageのビルドパイプラインの違い
• Swift Buildの登場と新しいビルドパイプライン
• Swift Buildのアーキテクチャを見てみよう