iOSDC Japan 2025協賛&参加レポート

こんにちは、DevRelブロックのikkou（@ikkou）です。2025年9月19日の夕方から21日の3日間にわたり「iOSDC Japan 2025」が開催されました。ZOZOは昨年同様プラチナスポンサーとして協賛し、スポンサーブースを出展しました。

technote.zozo.com

本記事では、前半は「iOSエンジニアの視点」から、ZOZOから登壇したセッションとiOSエンジニアが気になったセッションを紹介します。そして後半は「技術広報の視点」から、ZOZOの協賛ブースの様子と各社のブースコーデのまとめを写真多めでお伝えします。

登壇内容の紹介

今年のiOSDCではLTに2名、パンフレット寄稿に2名が採択されました。会場で発表されたLTについて紹介します。

AlarmKitで実現する新時代のシステム通知（レギュラートーク）

續橋からのコメント：
iOS 26から使える最新のAPIということで、Track Dが満席になるぐらい多くの人に足を運んでいただき感謝です！　ちょうどAlarmKitを使ってアプリを作ろうとしていた人や気になっていたけどキャッチアップしていなかったという人にもAlarmKitの素晴らしさと凄さを伝えられたのかなと思います！　また、AlarmKitの人と認知してもらえて会場でも多くの人とコミュニケーションをとる事ができて捗りました。

今回は資料作りや登壇練習も万全とはいえず悔いの残るところもあったので、次も機会がいただけるならば、前もって資料作りを行い、計画性を持ってiOSDCに挑みたい所存です！

speakerdeck.com

全身画像からコーデアイテムを抽出し毎日にIRODORIを！デバイス完結型アプリを作る（ルーキーズLT）

「全身画像からコーデアイテムを抽出し毎日にIRODORIを！デバイス完結型アプリを作る」を発表中の濱田

濱田からのコメント：
コーデ選びの相棒を作るをコンセプトとしたアプリIRODORIにおける、AIモデルを使ったコーデアイテム抽出の話をしました！　ZOZO社員ならではの”ファッション×テック”らしい良い発表ができたのではないだろうかと自画自賛しています。

最近はLLMの発展によってAIが広く使われるようになり、世の中の様々な問題がすごいスピードで解決されています。しかし、LTでもお話しした通り「AIは、便利な反面、金かかる」です。このコストの問題は開発者側に重くのしかかり、個人開発者やMVPで開発し効果検証をスピード感持って取り組みたい方にとってはかなりの障壁になるはずです。この問題を解決するためにLTで「AIをオンデバイスで動かす」という選択をお伝えしました。今回のLTが一人でも多くのエンジニアへ届き、世の中の問題解決に繋がれば幸いです！

最後に、LT登壇に向けてネタ出しから発表練習までサポートしてくれた社内のメンバーに感謝を伝えて締めようと思います。

speakerdeck.com

iOSエンジニアが気になったセッションの紹介

ZOZOのiOSエンジニアが気になったセッションをいくつか紹介します。

カスタムUIを作る覚悟

FAANS部でiOSエンジニアをしている、ましょー（@masho1017）です。まつじさんの「カスタムUIを作る覚悟」というセッションを拝聴しました。このセッションは、私にとって非常に学びの多い内容だったので、本記事でご紹介したいと思います。

まつじさんの発表では、カスタムUI開発の難しさについて、豊富な実例を交えながら解説されていました。具体的には「どのような場合にカスタムUIを作るべきか」「実際に作るとき意識すべき考え方」といった内容です。

本記事では、その中でも私が特に感銘を受けたポイントを2つ取り上げ、それらをFAANSでの開発にどのように活かせると考えたかを、私自身の視点からお伝えします。

1. 「対応しない／対応できていない」を明確に認識する

このセッションではカスタムUIだからといって、標準APIが備えるすべての機能（例：アクセシビリティ、アニメーションの細部）を必ずしも再現する必要はなく、重要なのは、「あえて対応しないのか」「現時点では対応できていないのか」を認識することだと述べていました。

FAANS iOSでは動画投稿機能（参考記事）の実装にあたり、デザインの観点から標準のUIImagePickerControllerではなくカスタムUIを採用しました。私自身がそのUIを実装したのですが、完成に満足してしまい、標準APIで担保されている挙動のうち、自作UIで不足している点を十分に把握できていませんでした。今後は、「どの要素を対応しないと判断したのか」「どの要素が未対応なのか」を設計段階から言語化することで、ユーザー体験を損なわないプロダクトを継続的に届けたいと思います。

2. カスタムUIに対して、UIデザイナー/エンジニアと線を引くのではなく同じクリエイターとして取り組む

カスタムUIでは、アニメーション（長さやアニメーションカーブ）、ダイナミックタイプ（レイアウト変更やアクセシビリティ対応）など、多くの考慮点があります。これらを「UIデザイナーが考えるべきか、それともエンジニアが考えるべきか」と分担を意識してしまいがちですが、このセッションでは両者が同じクリエイターとして取り組むべきだと強調されていました。

私はこの考え方に強く共感しました。iOS開発に限らず、幅広い分野のエンジニアにも通じる考え方だと感じます。

実際のFAANSチームでは、カスタムUIに関するアニメーションや細部の検討は基本的にUIデザイナーが行い、エンジニアはそれを実装する、という役割分担が定着しています。そのため、どうしても委ねがちになってしまう部分がありました。今後は、カスタムUIの設計・実装においてUIデザイナーと積極的に協業し、同じ目線で議論しながらプロダクトを作り上げる文化を育てていきたいと考えています。

以上が、私が感銘を受けたポイントと、それをFAANSでどのように活かしていくかについての考えです。セッションの最後には「カスタムUIは実装もメンテナンスも大変であり、終了は突然訪れる。すなわち、カスタムUIを作るには覚悟が必要だ」とまとめられていました。実際にまつじさん自身、iOS 18まで作り込んでいたカスタムUIが、iOS 26に追従できず破棄せざるを得なかった経験を共有されていました。それでも、仕様やデザインによってはカスタムUIを作らなければならない場面は必ずあると思います。そうした時こそ、このセッションで得た学びを活かし、UIデザイナーと協力しながら、ユーザー体験を損なわないカスタムUIを届けたいと思います。

iOSアプリのバックグラウンド制限を突破してバックグラウンド遷移後もアップロード処理を継続するまでの道のり

ZOZOTOWNでiOSエンジニアをしているつっきー（@tsuzuki817）です！　家族アルバム「みてね」のバックグラウンドアップロード技術に関するセッション「iOSアプリのバックグラウンド制限を突破してバックグラウンド遷移後もアップロード処理を継続するまでの道のり」を大変興味深く拝見しました！

複数の実装方法を試し、それぞれのメリット・デメリットを丁寧に比較されていたのが非常に分かりやすく、学びの多い内容でした。

中でも、Picture in Pictureを用いてバックグラウンドでのアップロードを継続させるというアイデアには「その手があったか！」と唸らされました。技術的な制約や課題がありながらも、「ユーザーの体験を絶対に止めない」という強い意志を感じ、開発者として大いに刺激を受けました。

ZOZOTOWNのサービスにおける直接的な応用シーンはまだ未知数ですが、複雑な課題に対して粘り強く最適解を探求する姿勢は、すべてのエンジニアにとって非常に参考になるはずです。まだご覧になっていない方は、ぜひ視聴をおすすめします！

***

FAANS部でiOSエンジニアをしている、イッセー（@15531b）です。私が特に印象に残ったセッションも續橋と同じ「iOSアプリのバックグラウンド制限を突破してバックグラウンド遷移後もアップロード処理を継続するまでの道のり」です。

私たちが開発しているFAANSには動画投稿機能があり、現状ではアプリを開いたままでなければアップロードを完了できません。家族アルバムアプリ「みてね」も同様の課題を抱えており、アプリを開いたまま写真や動画をアップロードする必要がありました。セッションでは、様々なバックグラウンド手法を検証した結果、最終的にPicture in Picture（PiP）を用いることでバックグラウンドでもアップロードを継続できるようになった経緯・実装方法が紹介されていました。

中でも興味深かったのは、バックグラウンド実行の多くの方法には制約がある一方で、PiPならそれを突破できたという点です。実装には難しさや制約があったものの、枠に囚われない発想でエンジニアリングの可能性を切り開いた事例として感銘を受けました。

また、iOS 26から追加されたBGContinuedProcessingTaskなどの複数のバックグラウンド実行の手法が検証されており、それぞれのメリット・デメリットが分かりやすく整理されていました。この技術的な比較は、FAANSにどの方法が適しているかを考える上で大変参考になりました。

今回のPiPによるバックグラウンドアップロードは特許出願中であり、そのまま活用することは難しいかもしれません。しかし、制約を乗り越えて機能を実現しようとするエンジニアの探究心に強く刺激を受けました。FAANSでも現在の制約を超え、バックグラウンドでのアップロードが可能となるよう検討していきたいと考えています。

『ホットペッパービューティー』のiOSアプリをUIKitからSwiftUIへ段階的に移行するためにやったこと

WEARフロントエンド部でiOSエンジニアをしているセータです！　UIKitからSwiftUIにリプレイスする中で出てきた課題についての取り組みに関するセッション「『ホットペッパービューティー』のiOSアプリをUIKitからSwiftUIへ段階的に移行するためにやったこと」が個人的にかなり刺さる内容でしたので、ご紹介いたします。

現在、WEARでは一部画面でSwiftUIへのリプレイスを進めており、デザイナーとの意思疎通やリプレイスの方法などで模索している段階のため、チームにとっても非常に学びの多い内容でした。

まず、フェーズ分割という方法がとても印象的でした。いきなり画面単位のリプレイスをするのではなく、まずは画面を構成するUIコンポーネント単位からリプレイスを行います。WEARでは最初から画面単位でリプレイスを行っており、画面ごとで出てきたコンポーネントを実装するようにしています。そのため、1画面にかかる工数が肥大化し、実装者から、レビュアー、デザイナーまで全員の負荷が大きいと感じておりました。フェーズ分割をすることにより、UI実装の単位が最小化されることによる実装コストの削減、レビュアの負荷軽減、デザイナーとの連携強化が期待できるということでした。

具体的なポイントがさまざまありましたが、特に印象的だったものを2つご紹介します。

1つ目はスナップショットテストについてです。こちらでは、関心のあるスコープに閉じてテストできる点が強力だと感じました。スナップショットテストでは、同じ入力に対してアプリケーションの状態や出力が変化していないことを検証しますが、画面単位で検証をする場合、関心のある観点以外でテストが失敗してしまったり、1つのテストケースに対して複数の観点が必要になったりするなど、効率の悪くなる可能性があります。コンポーネント単位で検証をすることで、不要なパターンのテストもなくなり、無駄な実装を大幅に削減することができます。また、Previewsを利用してテストが可能なので、テストのためにわざわざ何かを作成しないといけないということもなく、効率的で導入しやすいと感じました。

2つ目はUIカタログアプリについてです。こちらでは、UIコンポーネントを集約したアプリをデザイナーに共有することで、デザイナーが実際に触って操作感などを確かめることができるという点が画期的であると感じました。現状のWEARでは、デザイナーによるレビューはスクショとFigmaの差分を確認したり、動画キャプチャで確認してもらったりしていますが、DeployGateを用いて自動で配信して手元で確認してもらうことが可能なので、コードによる実装とデザインの乖離、認識の違いなどをほぼ無くすことができると思います。また、スナップショットテストの自動生成がUIカタログの作成にも活用できるため、一貫してメリットを享受できる点がとても良かったです。

これらの仕組みを導入するのは、初期段階では時間がかかり、コストを要するものですが、将来的にチームメンバーが変わったり、細かいデザインが変わった際などに強力な効果を発揮したりするため、長期的にはとても効率的なものになると思います。WEARでもまだSwiftUIのリプレイスを少しずつ始めている段階ですので、デザイナーと協調し、効率的な開発体制を整えられるように今回の学びを活かしたいと思います。

スマートフォン来し方行く末〜どこから来てどこへ往くのか〜

iOSテックリードのらぷ（@laprasdrum）です。iOS 4（当時はiPhone OS・iPhone SDKと呼ばれていました）とAndroid 2.3からスマートフォンに触れ、開発者としてはiOS 4.3・Android 4.3からコードに携わってきました。今回のセッション「スマートフォン来し方行く末〜どこから来てどこへ往くのか〜」では、その頃の思い出を懐かしみつつ、PDAから現在のスマートフォンに至る約2時間の歴史を存分に楽しませていただきました。

セッションの中で特に印象に残ったポイントを1つに絞るのは難しく、すべてが見応えある内容でした。当時マウス操作の延長だったタッチUIの概念を変えたiPhoneのCocoa Touch、CPU・GPUアーキテクチャ史におけるPowerVRの立ち位置、GPSの進化、プッシュ通知の仕組みと通信コストの背景、Retinaディスプレイの登場。これでもまだ序盤のトピックですが挙げきれません。

ハードウェアの進化が人々の生活を変えていくのを見たり体験したりするのは本当に素晴らしいことです。同時に、限られたハードウェア仕様の中で工夫を凝らしてニーズを実現していくことには開発者としての喜びがあります。今回のセッションを聞いて、その両方の良さを改めて思い起こすことができました。

博識な@hakさんと@tomzohさんだからこそ、最後まで聞き飽きないセッションでした。ぜひ来年も楽しみにしています。

ZOZOブースの紹介

会期中はiOSエンジニアを中心として多数のZOZOスタッフが入れ替わりながらブースに立っていました。iOSDC Japan 2025では、DroidKaigi 2025と同じように、モニターでiOSエンジニア向けにまとめた技術スタックなどを紹介しつつ、昨年リリースした「ZOZOMAT for Kids」を体験できるコーナーを設けました。