プロポーザル

【あらすじ】

社内で突然始まった、Swift 6対応プロジェクト。

しかし、iOSエンジニアはたった2人。
そのうちの1人は、「自分でやるのは面倒だから」という理由で、すべてをもう1人に丸投げしてしまう。

重すぎる作業量を前に、残されたiOSエンジニアは1人で抱えきれないと判断し、他部署や他社のiOSエンジニアなど、あらゆるリソースに声をかけて助けを求めた。

「Swift 6対応を乗り切るためなら、手段は問わない」
そうして集まった応援メンバーの協力もあり、プロジェクトは加速度的に進んでいく。

しかしその裏で、誰にも気づかれぬまま、少しずつ歯車は狂い始めていた。

ようやく作業が完了し、落ち着いたかに見えたその時、そのiOSエンジニアの前に現れたのは、思いもよらぬ「代償」だった…！？

このLTは「てんとう虫コミックス ドラえもん5巻収録『ドラえもんだらけ』」のオマージュです。

チームでの実装・レビュー遅延やレビューコメントの反映漏れに悩んでいた経験から、Cursorを導入し「実装→レビュー→修正」の開発フローを効率化しました。本発表では、以下の８ステップでCursorを活用し、開発速度と品質を両立できたプロセスを技術的に解説します。

1. 実装方針をCursor上で共有し、建設的なイテレーションを回す
2. テストコードの叩きを用意し、細かく調整
3. ビルドエラー・テスト失敗を即座に把握して修正
4. 文言修正タスクへの迅速対応
5. ログ挿入→デバッグ→バグ修正サイクルの確立
6. チャットログから良い実装の振り返り・ナレッジ化
7. PRテンプレートによる統一された提出フロー
8. レビュー対応とCursorを使ったコメント反映の高速化

Cursor導入前後でiOS開発が如何ほど効率化されたか、導入を検討中のチームに即活用できる提案をお届けします。

UIKitで長年運用しているアプリに、SwiftUI画面を一部導入する機会がありました。そこで採用したのが、iOSDC2023で紹介された「SVVSアーキテクチャ（Store・ViewState・View）」です。

MVVMやTCAも検討した中で、なぜSVVSだったのか？ UIKitコンテキストとの親和性、学習コスト、段階導入のしやすさなど、現場目線で感じた「ちょうどよさ」を共有します。

5分という短い時間ですが、SVVSの魅力と、実際にどうやって導入し、どんな課題があってどう乗り越えたかを簡潔に紹介します。SwiftUIを使ってみたいけどまだ一歩踏み出せていない方、UIKitとの橋渡しに悩んでいる方に刺さる話です！

課題は以下のような内容になります。
・チームメンバーへの理解促進（勉強会・ペアプロ）
・エラーハンドリングが煩雑になる問題
・Storeの強みが活かせない問題
・UIKitからSwiftUIへの遷移の違和感
・UIKitのタブが正しく表示されない問題

「SwiftUIなら、きっとサクサク動くはず！」
そう信じて開発したアプリのスクロールがカクついた時、パフォーマンス改善という大きな壁にぶつかりました。「一体何から手をつければ…？」と途方に暮れたのは、きっと私だけではないはずです。

このトークは、そんな私がXcodeのInstrumentsと格闘し、Viewの描画の仕組みやLazyVStackなどの基本的な知識を武器に、"もっさりUI"を改善していくまでの奮闘記です。

本セッションでは、

• ルーキーがつまずきがちなパフォーマンスの落とし穴
• Instrumentsを使ったボトルネック特定の第一歩
• ViewのIdentityやレイアウトの工夫など、すぐに実践できる改善テクニック

を、失敗談を交えながら共有します。
パフォーマンスチューニングは、ベテランだけのものではありません。この発表が、同じ悩みを持つ皆さんの「はじめの一歩」を踏み出すきっかけとなれば幸いです。

ゲーム開発といえばUnityやUnreal Engineが代表的ですが、学習コストやライセンス費用に不安を感じていませんか？
実はApple純正フレームワークだけでも、ゲーム開発に必要な、接触判定・リアルタイム通信・ランキング・ゲームパッド対応など、実用に足る機能群がすべて揃っています。
さらに、WWDC25にて紹介のあったApple Gamesアプリの登場やGame Centerの機能拡張が追加など、ユーザがゲームに触れやすくなるような状況が増え、ゲームデバイスとしてのiOSに今注目が集まっています。

このトークは、ゲーム好きですが一般のアプリしか作れなかった私が、純正フレームワークのみでオンライン通信対戦ゲームを完成させ、インディーゲームイベントへの出展を目指した経験をもとに、以下のトピックについてお話しします。

• 使用したフレームワークと用途について
  • SpriteKit：アクションゲームの土台となる描画・アニメーション・接触判定
  • GameKit×GameCenter：オンラインマッチングとリアルタイム通信、新機能の導入
  • MultipeerConnectivity：オフラインでも動く対戦通信の構築
  • CloudKit：スコアランキングの保存・共有、セーブ機能
  • GameController：ゲームパッド対応
• インディーゲーム展示イベントへの出展について
  • 出展時の反応や工夫したこと
  • Swift製のアプリの割合

Swiftで業務アプリを作っているあなたも、すでにゲーム開発に必要な材料を持っていたのです──
Apple純正フレームワークだけでもここまで「戦える」ということを、実例を交えてお伝えします。
ゲーム開発は特別なスキルが必要──そんな思い込みを、そっと壊す5分間です。

iOSDC Japan 連載4コマ漫画「輝け！俺のViewController」が打ち切r...最終回を迎えたのは、ネタが尽きたからです。
しかし、そんな燃え尽きた俺を差し置いて、Apple Intelligenceは進化を遂げました。

「Apple Intelligencesを使えば無限にネタが出て来ると思うし、自動『輝け！俺のViewController』生成アプリを作ればいいのでは・・・？」

プロンプトに関係なく暴走するAI、足りないAPIで試行錯誤、やばい、デバイスが燃えるほど熱い！あこれ、デバイスあったかいしホッカイロアプリとして使えるのでは...?

AIで「輝け！俺のViewController」は進化するのか？怒涛の5分間、衝撃の結末「刮目」せよ

2025年6月5日、ビル・アトキンソン氏が亡くなりました。彼は初代MacintoshのグラフィックAPI QuickDrawを開発した人物で、MacPaintの開発者としても知られています。本LTでは、彼が1987年に生み出したHyperCardというソフトウェアを紹介します。

HyperCardは、Macintosh用のオーサリングツールです。「カード」と呼ばれる画面を組み合わせて、インタラクティブなコンテンツを作成できました。プログラミング知識がなくても、ボタンやテキストフィールドを配置し、絵を描き、カード間をリンクでつなぐだけで何かを作れます。さらにHyperTalkというスクリプト言語で、より複雑な動作も実現できました。

当時のMacintoshに無料バンドルされていたこともあり、教育現場からアート作品、ゲームまで多様なコンテンツが生み出されました。インターネット普及前にハイパーリンクでカードを繋ぐ概念は、ローカルで動くWWWのようでした。Cyan社の名作ゲーム「Myst」もHyperCardで開発されたことは、その可能性を物語っています。

実際の画面をざっと見せながら、HyperCardがどんなソフトウェアだったか紹介します。カード、ボタン、フィールド、ペイントツール、HyperTalkスクリプト。これらがどう組み合わさって動作していたのか解説します。また、もしスティーブ・ジョブズのApple復帰後も開発が続いていて、幻のHyperCard 3.0がリリースされた世界線はどんなだったか、少しだけ思いを馳せてみます。

iOS 26で新たに登場した BGContinuedProcessingTask により、ユーザ起点で開始した処理をアプリのバックグラウンドでも継続できるようになりました。
今までiOSはバックグラウンド制御は大きな壁があり実行に大きな制限がありました。
本セッションでは、このAPIの導入背景や制限の変化を、実際のコードや動作デモを通じて、iOSにおけるバックグラウンド制御の制約に焦点を当てて解説します。

私は、iOSおよびAndroidのアプリエンジニアとして長年の経験を積んできました。
このトークでは、クロスプラットフォームからiOSネイティブ開発に戻る際に直面する課題について、コードベースで具体的にお話しします。以下の内容について詳しくお話しする予定です。

SwiftとDartの言語仕様の違いについて（null安全性や型システム）
Swift Concurrencyの導入による非同期処理のモダン化について（async/awaitやActor）
SwiftUIを用いた宣言的UI実装のFlutterとの差分の実例
FlutterのHot Reload機能に依存した開発体験から、ネイティブ開発に戻った際のギャップと対策

これらのトピックを通じて、フレームワーク間の移行がもたらす技術的および開発体験上の影響について共有したいと思います。

モロッコの伝統衣装の美しさと多様性を、日本語でも気軽に体験できるアプリがあったら？
この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.

皆さんは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の様子や回答内容が知りたい方

iOSDC Japan参加者のみなさんなら、きっとiPhone、iPad、MacBookを持っていますよね！人によってはVision ProやHomePod、Apple TVもお持ちかもしれません。
私達にとっては仕事道具ですが、世間ではAppleプロダクトを使用していることは一種のステータスとも捉えらており、「おしゃれ」や「スタイリッシュ」の代名詞の一つということもできます。

そしてさらにこのスタイリッシュさは「無国籍」です。アメリカでも日本でも、喫茶店でMacBookを広げた姿は国を問わずスタイリッシュと言えるでしょう。
そのため私達はこれらAppleプロダクトを持っていれば世界中どこの国でも「スタイリッシュ」に仕事をすることができます。

でも、なぜAppleプロダクトは世界中どこで使っても「スタイリッシュ」なのでしょうか？

ソフトウェアのUI/UXの良さでしょうか？それともハードウェアのデザインが良いからでしょうか？
もちろんAppleプロダクトはソフトウェアのUI/UXは良いですし、ハードウェアのデザインも最高です。

実は、Appleプロダクトがそのイメージからは一見無関係に見える「建築」の世界からきた「素材」によってもスタイリッシュさが支えられていますとお話したら驚くでしょうか？

このLTではみなさんと一緒にモダニズムの生い立ちと、私達ソフトウェアエンジニアには意外に見えるガラスやアルミニウムといった「素材」の2観点から、Appleプロダクトがスタイリッシュに見える理由を深堀りします。
ソフトウェアエンジニアである私達が普段は見落としがちな「素材」という現実世界の要素が、なぜ「スタイリッシュ」に繋がっているのかを知ることで、皆さんの「プロダクト」作りに素材という新たな視点をもたらすことができれば幸いです。

LT会場でお会いしましょう！

εε＝┌|▼▼|┘ ｳｯﾎｳｯﾎ

Xcodeは素晴らしいIDEって伝えなきゃ

ｳｯﾎｳｯﾎ └|▼▼|┐＝33

本LTでは、Xcodeの素晴らしいところをウホフクロウが軽快に紹介します。
5分間でXcodeをより快適に使えるようになるはずです。

●話すこと
・Xcodeの素晴らしいところ

●話さないこと
・Xcodeの素晴らしくないところ

ウホフクロウを生暖かい目で見守ってくれると幸いです。

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

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

話すこと

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

対象者

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

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

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

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

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

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を含む開発プロセスの最適化を愚直に実施しました。

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

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

なんとiOSDC2025は最初の開催から今回で10回目！！
そんな記念すべき節目を祝うにふさわしい舞台...

そう、それはDJしかねえ！！アゲアゲ⤴︎⤴︎

でも、ただのDJじゃ物足りない...
エンジニアなら、機材だってコードで動かしたい！

そこでStream Deckを使っていくぜ！
なんとSwiftからコントロールすれば立派なエンジニア向けDJ機材に早変わり！

このステージでは、Stream Deck を使った華麗な DJ さばきで会場を沸かせます。
このセッションでは、Swift を使って Stream Deck を操作し、音を楽しみつつ実装を解説していきます。
　
俺のステージでみんなを沸かせるぜ！！
みんなでiOSDCをお祝いしましょう！！