トーク

本LTでは、単体テストのフレームワークをXCTestからSwift Testingへ移行したいと考えている方向けに、具体的にどのようにSwift Testingへ移行するのかを経験談を交えて紹介します。

WWDC24で新たに紹介されたテストフレームワークであるSwift Testingも、紹介されてから1年以上経ち導入事例も増えてきていると思います。
そのような情勢もあり、まだXCTestで単体テストを行なっているチームでも、Swift Testingへ移行していきたいというモチベーションが高まっているところも多いでしょう。
しかし、実際にSwift Testingへ移行するときにどのように移行するのが良いのか、どれぐらい大変なのかが掴めないとなかなか踏み出しづらいです。

本トークでは、実際に担当しているiOSアプリプロジェクトの単体テストをXCTestからSwift Testingへ移行した経験をもとに、以下内容についてお話しします。

• 実際の単体テストをXCTestからSwift Testingへ移行した手順
• 移行時の工数感
• 移行時に困ったこと

新しいフレームワークを導入するにあたって、メンバーを巻き込んでいく必要がありますが、実際にどのように説得して、導入まで漕ぎ着けたかというところまでお話しします。

実際に移行した経験からSwift Testing移行のよりリアルな知見を共有できると思います！
Swift Testing移行を考えている開発者にとっては、移行を検討する上で大きなヒントになるはずです！

プログラマーの資本と聞いて、あなたは何を思い浮かべるでしょうか？

これまで読んだ技術書の厚み？
経歴書に書ける経験の長さ？
チーム開発でうまくやっていけるソフトスキル？

いいえ、違います。

腰です。
それも健康な、腰です。

プログラマーの真の敵は刻々と変わりゆく仕様ではなく、集中力を阻害する腰痛です。
そんなわけで、健康な腰の維持のために職場や自宅で昇降式デスクを使われている方も多いかと思いますが、本当に「昇」してますか？
スタンディングデスクなのに最後にスタンダップしたのがいつだったか思い出せない人も多いでしょう。
いいえ、あなたを責めているわけではありません。
人間の意志とは実に弱いもので、楽な方に流れていってしまいます。

しかし、ご安心ください。
立つことが億劫になってしまうのなら、スタンディングデスクに一定時間毎に自動で上昇する機能をつけて、仕組みで解決してしまいましょう。
本LTでは、昇降デスク FlexiSpot、コントローラーとなる M5Stack、サーバーとなる Raspberry Pi, スマートホームを実現するOSSのHomeAssistantとを組み合わせて、FlexiSpotをスマホやパソコンから操作したり、時刻やアクションをトリガーに自動で昇降する機能を実現する方法をご紹介します。

本LTでは、テストでHealthCareデータの登録が必要だけど毎回面倒と思っている方に向けて、データの登録を簡易に行うアプローチを紹介します。

HealthKitを用いたiOSアプリでは、テストの際にHealthCareデータの登録が必要になるはずです。
しかし、テスト用にHealthCareデータの登録を簡易に行うためのツールはAppleから公式には出ておらず、手動で登録を行うケースも少なくないでしょう。
手動での登録は、テストごとに煩雑な操作を伴うため、特にE2Eテストの自動化においては大きな障害となり、結果的にテストの工数が増加する要因となります。
私の所属するチームでもその課題に直面したため、試行錯誤の末、CLIコマンド一つで指定の端末に必要なデータを自動登録するツールを作成しました。

本トークでは、実際にデータ登録自動化ツールを作成したことと、それを業務で運用してみた経験から、次のような内容についてお話しします。

• CLIでHelthCareデータを登録する仕組み
• CLIでHelthCareデータ登録を実現するときにハマったこと
• 業務で実運用してみての感想

ツールの実装は単なるシェルスクリプトではなく、XCTestやシェルスクリプトを組み合わせて行いました。具体的な実装方法について、ソースコードを交えながら詳しく説明します。

HealthKitを使った開発をしている、もしくはこれからしようとしている開発者にとっては、テストの工数を短縮する上で大きなヒントになる知見を共有します！

Swift Package Manager 5.6から登場した Build Tool Plugin。
ビルド時にコードやリソースを生成できる強力な機能として、登場から3年が経ち、多くのプロジェクトで利用が進んでいます。

そんな Build Tool Plugin、便利さの裏で「あること」を見落としていませんか？

Derived Data に出力される成果物。
それがどこまでアプリに影響を与えるか、普段どこまで意識してビルドしていますか？

今回の発表では、Build Tool Plugin を通して気づいた“とある落とし穴”と、それにまつわる 実体験からの学びを共有します。
思わず「ヒヤッ」としたその出来事、Derived Dataの奥底から灼熱の有明にお届けします。

本トークでは、Appleが公開した研究向け機械学習ライブラリMLXのSwift向けバインディング「MLX Swift」を用いて、任意のモデルをローカルLLMとして動かす手順を解説します。

具体的には、Hugging Faceで公開されている軽量モデルの選定、モデルへのプロンプト送信と応答の取得方法、そして実際にモデルとの対話を行った際の挙動や、処理速度・メモリ使用量など実用面で見えてきた課題や使い所について共有します。

【話すこと】

• MLXとMLX Swiftの概要
• MLX Swiftを用いたローカルLLMの構築と実行までの実装ステップ
• 実際に動かして見えてきた課題とオンデバイスAIの可能性について

AIツールをコードレビューに導入してみたものの、期待していたほどの効果を感じられない...そんな経験はありませんか？

CursorやGitHub Copilotなど最新のAIツールを組み合わせることで、ようやく「AIが本当に役立つレビュー環境」を構築できました。重要だったのは、AIに全てを任せるのではなく、AIと人間の得意分野を明確に分けることでした。

このLTでは、実際のiOSプロジェクトのPRを使って、複数のAIツールを連携させたレビューフローを実演します。AIがコードの詳細チェックやパターン検出を担当している間に、人間はアーキテクチャやUX観点での判断に集中する。

この役割分担により、レビュー時間の短縮と品質向上を同時に実現した事例をご紹介します！

SwiftUIは年々進化し続け、これまでUIKitに頼らざるを得なかった複雑な挙動も、SwiftUIだけで完結できるようになりつつあります。
例えばScrollView一つとっても、iOS 17では特定のビューへ自在にスクロールできるようになり、iOS 18でスクロール位置の変化を取得し、任意の処理を実行できるようになりました。さらにiOS 26ではLazyStackと組み合わせた際のパフォーマンスが数倍に向上したようです。

しかしプロダクトとしてユーザーのことを考えた時、4年前に登場したiOS 15でも今すぐサポートを終了するのはそう容易ではありません。

このLTでは、OSバージョンによるSwiftUIの機能差やiOS・iPadOS間のプラットフォームの違いに起因する挙動の違い、そしてそもそもSwiftUIでは実現できないことを基に、SwiftUIを諦めてUIKitに頼るべきタイミングを10個ご紹介します！

Swift OpenAPI Generatorは、Appleがオープンソースで開発を主導するOpenAPIから関連コードを自動生成するツールです。このテクノロジーの魅力は、既存のツールと比べてよりSwiftらしい型による安全な表現が実現できる点にあります。
しかしながらSwift OpenAPI Generatorへの移行は必ずしも円滑に進むとは限りません。
APIにリクエストしてからレスポンスを受け取り、それをエンティティオブジェクトにマップするまでの間に、複数のポイントでエラーと向き合う必要があります。

本発表では、その中でも特に多様なエラーをどのように整理し、アプリで統一的に扱うか、その一つの実践的なアプローチをご紹介します。
具体的にはHTTPエラーレスポンス, ネットワークエラー, 特定のオペレーションを実行中に発生するエラーなどから必要な情報を取り出してアプリ固有のエラーに変換する方法、そうしたエラーハンドリングをアプリで画一的に実施する方法、それらの実装の正当性を検証するテストのスマートな書き方をご共有します。

AppleからリリースされたTN3187: Migrating to the UIKit scene-based life cycleにて、全アプリでUIKit based life-cycleからScene-based life-cycleへの移行が必須になることが発表されました。
また、こちらのドキュメントにはScene-based life-cycleに移行しないとアプリが起動しなくなるということも明記されているので、一定数移行作業を行わなければならないプロジェクトが多く存在するのではないでしょうか？

しかしながら、アプリの心臓とも言うべきライフサイクルは、アプリの要件としてイベントの送信やDeepLink周りのハンドリングなど色々な考慮が求められます。
また、当然無事故で移行することが求められ、アプリのデリバリーはブロックしないように実行しないといけない、慎重さとスムーズさを求められるプロジェクトになると考えられます。
このようにScene-based life-cycleへの移行のようにドラスティックな変更が必要になった背景やどのような対策を行わなければならないのか、時間が許せば移行に関するtipなども交えた実践的な内容をお話ししたいと思います。

Apple Vision Proの登場などにより、3Dの空間表現は身近なものになってきました。RealityKitをはじめとしたフレームワークのおかげで、Swiftで3Dコンテンツを扱うことも簡単になっています。
では、ここからさらに"次元をひとつ上げる"ことはできないでしょうか？

今回はSwiftを使って3Dのその先、4D空間のオブジェクトを描いてみるという、ちょっと変わった挑戦をしてみました。
RealityKitで直接扱えるのは当然3Dまで。そこで数学の力を借りることで、4Dのオブジェクトを無理やり3Dに落とし込んで描画します。
このLTではRealityKitでの3Dレンダリングの基本をおさらいして、そこから次元を上げて4Dレンダリングを実現する方法を紹介したいと思います。
さらに、ドラッグなどのジェスチャー操作で4Dオブジェクトをぐりぐりと動かすインタラクションも実装しました。4D空間を見るだけでなく、触って体感できるデモをお見せします！

難しい理屈は置いておいて、なんだか不思議で見ているだけで面白い。そんな4Dの世界を一緒に体験してみませんか？

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

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

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

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

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

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

去年 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 を出した流れとその中の面白いところを話します。

はじめてSNSアプリを作るとき、多くの開発者が直面する最大の壁。それがApp Storeの審査(App Review)です。

SNSアプリをApp Storeにリリースするには、他ジャンルのアプリ以上に厳しいApp Reviewの壁が立ちはだかります。
特に、ユーザー生成コンテンツ（UGC）を扱うアプリは、ユーザー保護の観点から求められる機能は多岐にわたり、設計段階から審査基準を意識していないと、何度もリジェクトされてしまうことも珍しくありません。

このLTでは、個人で開発したSNSアプリが何度もリジェクトされながらも、最終的にApp Storeに掲載されるまでの実体験をベースに、以下のような具体的なノウハウを共有します。

LTで話すこと：

• 実際にAppleにリジェクトされた理由と、それにどう対応したか
• App Reviewガイドラインに則った設計・実装で気をつけるべきポイント
• ガイドラインには明記されていないが、対応すべきこと

「はじめてのSNSアプリ開発」でつまずかないための実践的な知見を、リアルな失敗談とともにお伝えします。
今後、UGCを扱うアプリを作成する方の、少しでも力になれたら幸いです。

いつでもどこでもキャンプができたらいいな。そう思ったことはありませんか？
visionOSアプリで、現実では難しい「理想のキャンプ体験」を仮想空間で実現することができます。

本LTでは、Reality Composer Proを用いてvisionOSアプリに「春夏秋冬」の季節感を演出するパーティクルを作成・実装する方法をご紹介します。
春には桜の花びら、夏にはホタルの舞、秋には紅葉の舞い散り、冬にはしんしんと降る雪。それぞれ異なる自然の動きを再現するために、表現や動きの調整に多くの工夫が必要でした。そんな自然の表現が、visionOSでどのように再現できるのかをハッカソンのチームで開発したキャンプアプリの実例を交えて話します。

LTで話すこと：

• Reality Composer Proとは
• 春夏秋冬の異なるパーティクルの作成方法
• visionOSアプリでのパーティクルの活用実例

「このfullNameプロパティ、安心して呼んで大丈夫かな...？」
Swiftでコードを書く中で、Computed Propertyと関数の境界線に、ふと迷った経験はないでしょうか？
そして、その些細な迷いが、時として「期待とのギャップ」を生み、コードのパフォーマンスや可読性に影響を与えることがあります。

このトークでは、「なんとなく」で使い分けられがちなこの問題について、改めて基本から見つめ直します。

「フルネームの取得はComputed Propertyと 関数のどちらを使うべき？」という身近な疑問から出発し、なぜそれがパフォーマンス問題に関わるのか、そしてAppleはどのような設計思想を持っているのかを、実際のプロジェクトでよくあるケーススタディを通して、Computed PropertyとMethodの選択基準を皆さんと共有できればと思います。
このセッションが、皆さんの日々のコーディングにおける迷いを少しでも減らし、ご自身の意図をより明確にコードへ反映させるための一助となれば幸いです。

クラシルリワードでは、レシートの撮影・送信機能を提供しており、レシートを送信してもらうことでユーザーに還元を行っています。この機能では、Vision Framework を利用した領域やテキストの検出を行なっており、サーバーでのレシートの解析に大きく貢献しています。しかし、これらの処理を加えたことにより、撮影ごとにかかる時間が増加してしまうことになります。ユーザー体験を考慮して、撮影から送信までパフォーマンス改善を行っていたところ初回の実行だけ異常に時間がかかっていることがわかりました。このトークでは、この課題に対する対応策となぜこのようなことが起こっていたのかの考察をご紹介します。このトークを通じて、同様の課題に直面している開発者の皆様がスムーズに問題を解決するための手がかりを得られることを期待しています。

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

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

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

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

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

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

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

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

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

私たちが開発しているiOSアプリはリリースから3年以上が経過し、多くの方にご利用いただいております。しかし、長期運用に伴う機能追加や改修により、コードベースは徐々に肥大化し、レガシーコードの蓄積という課題に直面していました。特に、過去のプロジェクトメンバーが書いたコードや、仕様変更によって不要になったコードが残存していることが、コードの保守性や可読性を低下させる原因となっていました。

この課題を解決するために導入したのがPeripheryです。Peripheryは、Swiftプロジェクトの未使用コードを静的に解析するツールです。単に使われていないコードを検出するだけでなく、未使用の関数引数や不必要な public 指定に対しても警告を出してくれるため、非常にきめ細やかな検出が可能です。これにより、コードの肥大化を防ぎ、品質を向上させることができます。

Peripheryの導入には主に3つの方法があります。
・Xcodeに統合し、Aggregateターゲットで警告を表示
・CI/CDツールを用いて定期的にPeripheryを実行し、検知
・PR（Pull Request）作成時にCI/CDツールを用いてPeripheryを実行し、検知

本セッションでは、Peripheryの具体的なセットアップ手順から上記のCI/CDの構築方法を解説していきます。
またGitHub上にサンプルプロジェクトを公開することにより、Peripheryの導入を検討されている方がスムーズにプロジェクトに取り込むことができるようにします。

「名前書くの、正直めんどくさい…」

きっかけは、そんな僕自身の心の声でした。
僕の学校の図書館は紙で本の貸し借りが管理されているアナログ方式。
図書の管理表に学籍番号や本のタイトルを書くのが面倒で、紙に何も書かずに本を持っていってしまって行方不明になるという問題が度々起きていました。

「それなら、俺が図書管理アプリ作ればいいのか」

そんな思いつきで勝手に作り始めた図書管理アプリ。
職員の方に軽い気持ちで見せたらビビるぐらい気に入っていただけて、気づけば学校を巻き込んだプロジェクトになっていました。

本セッションでは、趣味で始めたアプリ開発が学校の公式案件になるまでの道のりと、そこで待ち受けていた数々の試練。
そして、学生だからこそできた解決方法についてお話しします！