プロポーザル

アプリの品質保証において、既存の機能が意図せず壊れていないかを確認するリグレッションテストは不可欠ですが、その多くが手作業で行われ、リリース前のiOSエンジニアにとって大きな負担となりがちです。
多くのチームがE2Eテストの「完全自動化」という理想を追い求めますが、サービス仕様上スムーズに認証を通す事が難しかったり、特定のUI要素の操作が困難だったりして、現実的な課題に直面し、導入を断念してしまうケースも少なくありません。

本トークでは、「完璧な自動化を目指さない」という発想の転換から生まれた「半自動E2Eテスト」のアプローチを紹介します。
既存の全手動運用をベースに、課題となる箇所を段階的に自動化していくことで、最小限のコストで最大限の効果を得る方法を実践例と共に解説します。
具体的には、SMS認証やカメラ操作、OS標準アラートといった自動化が困難なシナリオに対し、RubyのOCRライブラリ活用や座標指定、手動介入のタイミングを知らせる音声ガイドなどの工夫を通じて、どのように「手っ取り早く」運用可能な状態を構築したかをお話しします。

実際に導入から5ヶ月間、継続的に利用され、リグレッションテストの効率化に貢献している本システムの具体的な運用実績と、そこから得られた「壊れやすさを気にしすぎない」「最低限のメリットから始める」という、挑戦を後押しする考え方と安心感について共有します。
このセッションを通じて、リグレッションテストの負担軽減を模索している方、E2Eテスト導入の壁にぶつかっている方々が、新しいアプローチを見つけるきっかけとなれば幸いです。

LLMエージェントによるコーディングが民主化されたことで、プログラミングに新しい時代が到来しました。"Vibe Coding" という言葉が生まれ、多くの人が数行のプロンプトだけで実際に動作するアプリやWebサイトができあがってしまうのを体験しています。

その中で、こう思われた方もいるでしょう。「で、これを仕事で真面目に使うにはどうしたらいいんだ？」と。

詳細はお任せでゼロから適当に作らせればいい個人の遊びとは違い、業務としてのプロダクト開発には例えば以下のような制約やルールがあります。

• 機能要件が予め詳細に決まっている
• デザイン資料の通りにUIを実装する必要がある
• コーディングルールがある
• gitのブランチ運用など開発フローに関する決まりごとがある

本セッションでは、Anthropic社が提供するClaude Codeを実際にiOSアプリの開発業務で活用し、その中で得られた実践的なノウハウをお話します。

• Webアプリを作るのとは違う、iOSアプリ開発ならではの難しさに立ち向かう
• コンテキストが長くなることによる性能低下を防ぐために適度に記憶をリフレッシュする
• 要件定義と実装の工程を分けることで並列に進められるようにする
• AIエージェントをチームの一員として迎え入れるための準備
• プロンプトで指示しても無視することがあるのを、ToDoリスト機能で確実に実行させるようにする

このセッションで、業務にClaude Codeを組み込む際のコツを知っていただき、LLM時代のiOSアプリ開発者としての姿勢について考えるきっかけとなれば幸いです。

普段はWebのバックエンドを担当している私が、Swiftに興味を持ち、SwiftWasmを使ってオンラインプレイグラウンドを開発した実体験をお話しします。

SwiftWasmは、SwiftコードをWebAssembly（Wasm）にコンパイルして、ブラウザ上で実行可能にする技術です。Swiftに触れてみたいと思っていたものの、普段Web開発に慣れていることもあり、馴染みのあるWeb環境でSwiftを体験したいと考え、自作することにしました。

TypeScriptでの開発には慣れていましたが、SwiftWasmやWasm自体の扱いは初めてでした。特に苦労したのは、Swiftプログラムが正しく動作するために必要なWASI（WebAssembly System Interface）の一部を、TypeScriptで模倣する実装です。たとえば、fd_write は標準出力（print()）の処理を、proc_exit はプログラムの終了、random_get は乱数生成に対応しています。

「print()一つ出すのに、こんなに仕組みが必要なのか」と思いながらも、SwiftとWebAssemblyの仕組みを理解していくのはとても楽しい経験でした。

完成したプレイグラウンドでは、ブラウザ上でSwiftコードが実行でき、配列操作やクラス定義、Optional型の処理のデモを行えます。SwiftWasmの使い方やWebAssemblyの基本を、Webエンジニア視点で解説します。

iOSエンジニアの皆さんに、WebAssemblyでSwiftを実行する過程で得た気づきや発見を共有いたします。

SwiftはもともとiOSを中心に発展してきた言語ですが、最近ではその適用範囲が広がり、小型ゲーム機「Playdate」でも活用できるようになりました。

本セッションでは、白黒ディスプレイと物理ボタン、手回しクランクを備えたミニマルなゲーム機「Playdate」を題材に、その開発手法をご紹介します。Appleが新たに公開した「swift-playdate-examples」を活用することで、Swiftを用いてPlaydate向けのゲームを開発する環境が整いつつあります。

開発環境の構築手順を解説し、制約の多いデバイスで直面する独自の課題を取り上げながら、シンプルなゲームを作成するプロセスを共有します。さらに、リソース制限下でのSwift開発に役立つ実践的なヒントをお伝えし、実際にSwiftで制作したPlaydateゲームをデモします。

クリエイティブコーディングやゲーム開発に興味がある方、そしてSwiftの新たな可能性を探りたい方に向けて、iOSアプリの枠を超えたSwiftの魅力を、遊び心あふれる視点でお届けします。

【セッショントピック予定】

• swift-playdate-examples の概要
• Swift製ゲームをPlaydateで動かすための構築手順
• クランクや物理ボタンによるインタラクション設計
• リソース制限下でのゲーム開発における工夫とテクニック
• 制約された環境だからこそ見える Swift の柔軟性と強み

一見シンプルに見えるUIでも、実装してみると意外と時間がかかる──そんな経験はありませんか？

「このデザイン、30分で実装できそう」と思って始めたら、実際は2日かかってしまった。
そんな見積もりのズレは、デザインの「見た目の複雑さ」と「実装の複雑さ」が必ずしも一致しないことが原因です。

本稿では、SwiftUI・UIKit・Androidでの実装経験や考察から得た知見をもとに、デザイン仕様から実装難易度を読み解くための視点や判断基準を紹介します。

特に以下の観点を中心に、プロジェクト計画や実装方針の見極めに役立つ知見を整理します：

• 標準UIかカスタムが必要かを判断するための着眼点
• テキスト入力やChip、スクロールUIで陥りやすい構造的な課題
• カスタムアニメーションやトランジションの見積もりで考慮すべき要素
• GeometryReaderや座標計算を伴うレイアウトの扱いとその難易度
• 無限カルーセルUIを題材としたSwiftUIとUIKitのアプローチ比較

日々のUI実装における小さな判断を支える技術的な視点を、実例を交えてお届けします。

「このアプリ、自分に使える？」
そんな問いに応えるのが、WWDC25で発表されたAccessibility Nutrition Labelsです。
これはVoiceOverやSufficient Contrast、Captionsなどに対応しているかどうかが食品の栄養成分表示のようにラベル形式で表示されるもので、ユーザーはアプリのダウンロード前に自分に合ったアプリかどうかを判断できるようになります。

開発者はApp Store Connect上でアプリのアクセシビリティ機能対応状況について登録でき、その内容がAccessibility Nutrition Labelsとして表示されます。
今後このラベル表示は新規アプリやアップデート時に必須化される予定で、Appleは明確な評価基準や申告手順をガイドラインとして公開しています。
たとえばSufficient ContrastはWCAGの推奨コントラスト比（4.5:1以上）を満たしているかなど、項目ごとに具体的な条件が示されています。

このトークでは、Accessibility Nutrition Labelsの概要や各項目の評価基準を整理した上で、iOSアプリでこれらの基準をどのように満たすか、具体的な実装例を交えて紹介します。
VoiceOver対応のための accessibilityLabel や accessibilityHint、Dynamic TypeやReduce Motionといったシステム設定への対応などの実装方法に加え、XcodeのAccessibility Inspectorを活用した検証手法も解説します。

アクセシビリティは一部のユーザーのためだけの機能ではなく、誰もが恩恵を受けられる設計原則です。
このトークを通じて、あなたのアプリの「アクセシビリティ健康診断」を始めてみませんか？

シニアエンジニアに必須の能力はなんだと思いますか？そうですね、WWDCでの引率能力ですね。後輩たちを博物館や交流会へ連れていきApple Parkへ辿り着かなくてはいけません。
そこで選択肢に挙がるのがレンタカーです。ライドシェアより安く済み、アジア人女性150cmの私が知らない人の車に乗る不安からも解放されます。自動運転タクシーはエリア外だしサービス一時停止してたし。
とはいえ異国での運転は楽ではありません。ご想像の通りの右側通行左ハンドル。愛車の倍の体積のアメ車。そして日本とは違う道路のつくり。ペーパードライバーを脱して1年ですが運転しないことにはスキルが身につきません。やっていきましょう💪

本LTでは、スキルアップのため私がアメ車に初挑戦した経験をもとにサンノゼの交通事情を紹介します。
CarPlay（アメリカのすがた）にも触れますよ！さっそくCarPlayからお昼のピザの注文を……えっ？電話じゃないと注文できないの？？ていうか数百メートル先にHazard Aheadってなになに！？！？

話すこと

• 日本との違いは右側通行だけじゃなかった…
• 助手席からあるとありがたいサポート
• アメリカのCarPlayを研究だ🔍

対象者

• 観光や交流もしなくちゃもったいないと思っている人
• 正直ライドシェアに乗るのが怖い人
• アメリカにおけるCarPlay（navigation, quick food ordering）に興味がある人🍕

2017年以来お世話になった西早稲田。過去参加された方はこの地にいろんな思い出をお持ちでしょう。

あれ？私、駅と63号館との往復しかしてないや。高田馬場や西早稲田や大学のことを何も知らない。たくさんお店があるのに、母の生まれ育った地なのに、10年前に理工展の人と交流したことあるのに、この街のことを何も知らない…！

本記事では、高田馬場&西早稲田を何も知らないまま有明へ行く皆さんのために散策用のマップを提供します。
機会を見つけて散歩してみると面白いですよ！

【掲載内容】

★高田馬場&西早稲田エリアの散策マップ
学生街と住宅街がいい感じに隣り合った街並みを紹介します。
ときどき史跡があったり、少し東に行くとヤギさんがいたりします。

★高田馬場&西早稲田メシの食レポ
個人的に気になったお店をいくつか紹介します。
高田馬場といえばラーメンですが、甘いものも要チェックです。それにカレーとラム。

★早稲田大学西早稲田キャンパスができるまでの歴史
山手線内にまとまった土地があったということは、つまりそういうことですね。

★理工展2024の参加レポ
去年参加された方は、iOSDC Japan 2024のフォトモザイクに「理工展にもきてね！！」と書き込まれていたことに気づいていましたか？私は行ってきましたよ！
学園祭はお子様連れの皆さんにおすすめのイベントです。
理工展の様子はもちろん、キャンパスツアーや学生チーム開発ノウハウ共有カンファレンスも紹介します。

【こんな人におすすめ】

• 街歩きが好きな人
• 食いしん坊な人
• 63号館と居酒屋にしか目がいってなかった人
• こっちのキャンパスにも大隈重信像があることに気づかなかった人

私はSwiftUI学園２年生のまつじ！

今日は転校生が来るって聞いてたのに遅刻遅刻〜〜！ViewHierarchyを口に挟みながら走ってたら角から出てきたコに...！キャッ！ぶつかっちゃった
もうなんだったの！あいつ！ってイライラしながらホームルームに出席すると...! 転校生ってあいつじゃん!

freddi先生新作。ドタバタ☆恋愛コメディ！始まる三角関係！UIViewControll太くん！私のためにあいつと争わないで〜〜〜〜〜

どっきどき！学園モノ４コマ漫画「SwiftUI学園 ~発動編~」堂々のスタート！

ますますグローバル化が進み、海外からのリクルートも活発になっている現状を踏まえ、多くの技術者が英語力の向上を求められています。そんな中で英語学習に苦労している方々に向けて、WWDCの動画を活用したシャドーイング学習法を紹介します。発表者は元英会話講師であり、その経験を活かして、効果的な英語学習法をお伝えします。シャドーイングは、リスニングとスピーキング能力を同時に鍛える効果的な方法であり、特に最新のiOS26に関するWWDCセッション動画を教材として使用することで、英語力と技術知識を同時に習得できます。

具体的には、シャドーイングのやり方、効果、そしてシャドーイングを継続するためのモチベーション維持のコツや、効果を最大化するためのテクニックを共有します。元英会話講師としての視点から、実践的なアドバイスや学習のヒントも提供します。このトークを通じて、参加者は英語学習と技術習得を同時に進める新しいアプローチを体験し、WWDC動画を活用した学習の楽しさと有効性を実感できるでしょう。英語力を向上させたい方、WWDCの動画たまってるな〜という方、そして効率的な学習法を探している方にとって、ぜひ聴いていただきたい内容です！

スクリーンショットや画面収録、画面共有などによって、ユーザーの機密情報が意図せず漏洩するリスクは、モバイルアプリにおける重要な課題です。特に、パスワードやクレジットカード番号、決済バーコード、有料コンテンツなど「画面には表示したいが、スクリーンショットには映したくない情報」のニーズは年々高まっています。

本トークでは、SwiftUIアプリにおいてこれらの情報を保護するための、セキュアなViewの構築法を紹介します。対象コンテンツの表示にUIKitを経由せず、SwiftUIのみで完結する実装により、状態管理やアニメーションとの整合性を保ちつつ、安全性と保守性を両立するSwiftUIらしいアプローチ方法を具体例と共に解説します。

トーク内容
⚪︎実際の利用事例
⚪︎スクリーンショットからの保護の必要性と課題
⚪︎従来取られたきたアプローチ
⚫︎どういった仕組みで実現されているのか
⚫︎SwiftUIでどう対応するか
⚪︎これを応用したUIの構築

2022年に公開されたApp Intentsですが、皆さんはもう活用されていますでしょうか？

最近のmacOS TahoeではSpotlightからの活用が可能になり、App Intentsの用途は着実に広がっています。しかし、カンファレンスや実際のアプリケーションで話題になることは、まだ少ないと感じます。

本トークでは、まずApp Intentsの概要とその基本的な利用方法を振り返ります。
その後、App Intentsに対応することでAppleエコシステムがどのように発展していくのかを考察します。

現在、MCPやモデル性能における大競争が繰り広げられていますが、Appleファンである我々はAI時代にどのように向き合っていくべきなのでしょうか？
このトークを通じて、その考え方の一例を皆さんと共有できれば幸いです。

今を去ること 6 年前、iOSDC Japan 2019 にて、トレーニング企業で受講者に利用してもらうための多数の Mac の環境構築に関する試行錯誤についてお話ししました。

弊社では Mac を多数用意してトレーニング環境をあらかじめ構築し、受講者にご利用いただいています。その際、機材ごとにアプリケーションのバージョンが異なっていたり、macOS の設定が異なっていると受講者が混乱してしまいます。そのため、できる限り環境を統一した状態で用意したいのですが、それを手作業で行うのは人の温かみはあるものの、非常に大変です。
以前は NetRestore を利用して環境の完全なクローニングとリストアが高速にできていました。しかし、macOS のバージョンアップやファイルシステムの APFS への変更、ハードウェア自体も T2 Security Chip の導入や Apple Silicon へのアーキテクチャ変更などもあり、その度に制限事項が増えています。

これらの制限との戦いを経て、一度は回帰してしまった「温かみのある手作業」による環境構築から抜け出すことができたのか？
現在の状況と環境構築の工夫とは？そしてまだ手作業の温かみは残っているのか？

我々の試行錯誤の数々と、現在の状況をぜひお聞きください！

Cybozuで内定者アルバイトをしている中、テストマイグレーションの一環でSwift Testing、Parameterized Testを導入していた最中、異常なパフォーマンスの低下を検知しました。
なんとその倍率７５万倍?！

これはヤベェ...と独り言をいいながら色々検証した結果ある結論にたどり着きました。
「Xcodeが悪いんじゃね？」
このシンプルな結論にたどり着くまでに考えた、原因探索やそれまでのフローは簡単に調べたら出てくるものではありません。

そこで、このテーマを人生初めてのiOSDC登壇テーマとして
「XCTestからSwift Testingへの移行におけるParameterized Testの採用で75万倍のパフォーマンス低下に直面した件」 についてお話します。

[本セッションで取り上げる内容]

• ParameterizedTestとは何か？（軽く）
• Swift Testing導入中に起きた75万倍のパフォーマンス低下に直面した時どのような対処を取ったのか
• ここで学んだ原因の探索におけるプラクティス

WWDC24から多くのプロダクトのテストを担うようになったテストフレームワークである Swift Testing
参加者の皆さんが関わるプロダクトでも導入が進んでいるのではないでしょうか？
AIによるコーディングの台頭により、今後おそらくもっとテストに対する意識は高まってくるでしょう。

AIで効率化されたナウでヤングでトレンディな開発を行う今！　テストについてのルーキーズLTを "5分だけ" 聞いてみませんか？

2021年、東急株式会社は内製開発組織「URBAN HACKS」を立ち上げました。URBAN HACKSは最初期からモバイルアプリエンジニアを戦略的に採用し、アプリを起点としたDXに取り組んできました。

本セッションでは、iOSDC2022のLT『鉄道アプリを支えるテクノロジー』で紹介した東急線アプリのフルリニューアルの裏側を振り返りながら、「なぜスマホアプリからDXを始めたのか？」という問いを改めて掘り下げていきます。

リニューアルを表面的なアプリの改善だけで終わらせないため、デザインや機能を刷新するだけでなく、それをきっかけにどのように組織のマインドや風土を変革していったのか。現場からDXを駆動させるプロセスと、その中でアプリが果たした役割について、実践を通じて得たリアルな学びを共有します。

SwiftUIでの開発は、宣言的で簡潔な記述ができる一方で、画面が大規模・複雑になるにつれて思わぬ設計課題に直面することがあります。多くの開発者は、以下のような課題に直面することも多いでしょう。

1. UI構造の可読性の低下
2. コードからデザインの想像が困難
3. 再利用性・コンポーネント化のハードル
4. 状態管理における責務の分離
5. Preview機能の破綻

SwiftUIの宣言的な記法は一見シンプルで強力ですが、実際の開発現場では、構造の複雑化や保守性の低下といった課題が顕在化しやすくなります。たとえば、1つの画面に複数の状態や分岐が含まれる場合、ifやswitchの入れ子が増えてbody が肥大化し、Viewの構造を把握するのが困難になります。また、共通化を目的にViewを切り出しても、柔軟性を持たせようとするあまりPropsが増えてしまい、かえって使いづらくなることもあります。

このような問題に対する1つのアプローチが、「コンポーネント指向」による設計です。UIを意味のある小さな単位として切り出し、それぞれが明確な責務を持つ自己完結型の部品として設計することで、再利用性や可読性を高めるとともに、状態管理の整理にもつながります。

とはいえ、SwiftUIにおけるコンポーネント設計は簡単ではありません。Propsが増えることでかえって複雑になることもあれば、状態やデータフローの設計次第で再利用性が損なわれることもあります。

本記事では、これらのSwiftUI特有の設計課題を整理しつつ、実際の開発の中で見えてきたコンポーネント指向設計の工夫や考え方を紹介します。宣言的UIで複雑な画面を設計している方、構造的なView設計に悩んでいる方の参考になれば幸いです。

Apple Vision Proを日常の中で活用？している様子をゆるく漫画でお届けします！

「CursorでSwiftコード生成→Xcodeに切り替えてビルド→エラー確認→また戻って...」

AIを活用した開発ツールで効率化したはずなのに、 Xcodeの操作で結局時間を失っていませんか？
実は、AIツールからxcrunコマンドを活用すれば、IDE間の切り替えを減らしつつ開発できます。

本セッションでは、LLM時代の新しい開発フローを実例とともに紹介します。

【解決する課題】
・AIツールとXcodeを頻繁に行き来する煩雑さを解消します。
・GUIからしかできないと思っていた操作をAIに実行させます。
・AIが生成したコードの即座の動作確認ができます。

【実演内容案】

• なぜ今xcrun/CLIが重要なのか
• CLI/AI開発ツールから呼び出せるコマンド群
• xcodebuild：AIツール内でビルド、テストの実行等々
• simctl: iOS Simulatorのコントロール等々
• AIツールと組み合わせて開発する実例を紹介

LLM時代を活用する、古くて新しい開発知識を身につけましょう！

iOS 26において発表された「Glass UI」は、Appleのデザイン哲学を体現する新たな表現形式として注目を集めています。その最大の特徴は、半透明かつ多層的なUIを通じて、情報と視覚の境界を曖昧にすることにあります。しかし注目すべきは、視覚効果そのもの以上に、誰もが容易にこのUIをプロトタイピングできる開発環境が整備された点です。

従来、こうした視覚的表現の実現には高度なレンダリング技術やパフォーマンス最適化が必要とされてきました。しかし、Appleが提供する新たなUIKitおよびSwiftUIのAPI群により、Glass UIの導入は非常に簡潔かつ再現性の高いものとなっています。標準化されたBlurやDepth、Material効果を用いたコンポーネント設計は、開発者にとって「まず試す」ことを可能にする環境を提供します。

さらに、iOS 26で実装されたGlass UIは、単なる美的表現にとどまらず、ユーザー体験そのものの再構築を促す契機として捉えることができます。情報の重なりと空間性をデザインに組み込むことで、従来の二次元的な画面遷移に依存しない、より直感的かつ没入感のあるUIフローが設計可能となりました。とりわけ、通知、設定画面、コンテンツビューアといった多層的情報を扱う場面において、Glass UIの導入はインタラクションコストの軽減と視認性の向上を両立させる新しいアプローチとなり得ます。

本講演では、Glass UIを用いた実際のプロトタイピング手法とともに、その表現力と制約、そして現場での活用可能性について考察します。また、UI設計における「触覚から視覚への比重の移動」についても理論的に分析し、視覚演出が操作性やユーザー認知に与える影響を探ります。

iOSアプリケーション開発において、「拡張性」「可読性」「効率性」の三要素は、理想として繰り返し語られてきました。しかし、それを現実のプロダクト、特に複雑かつ長期運用を前提とするゲームアプリにおいて愚直に実践することは容易ではありません。

本セッションでは、筆者が2年間にわたり携わった、複雑なゲームアプリにおける機能追加・バグ修正・運営を通じて得た知見を共有します。このアプリでは、オブジェクト指向設計をはじめとする基本原則を徹底的に適用し、ソースコードの構造的な整備とCI/CDを含む開発プロセスの最適化を愚直に実施しました。

その結果、少人数の体制でも新機能の追加や安定的な運用が可能となり、一定の収益を継続的に得ることができました。本発表では、設計・実装・運用の観点から、どのようにして「基本を忠実に行うこと」が品質と成果に結びついたのか、具体的なコード例や運用体制とともにご紹介します。

複雑なアプリの開発・運用に課題を感じているエンジニアにとって、「原則を疑わず、信じて実践すること」がなぜ有効なのか、その一つの実践例として参考になれば幸いです。