トーク

iOSは言語やフレームワークの進化が早く、技術的負債が溜まりやすい領域です。私が携わっている大規模サービスは約10年にわたり運用が続いており、その中で技術の進化に合わせて複数のアーキテクチャが共存しています。各アーキテクチャに適したライブラリやツールが導入されてきたことで、プロジェクト全体の構成が複雑化し、技術の全体像を把握するのが難しくなっていました。

こうした状況では、新しい技術の導入判断が難しく、技術選定が特定のメンバーの知見に依存してしまうことや、オンボーディング時の使用技術のキャッチアップに時間がかかるなど、複数の課題が浮き彫りになります。これらを解決するため、チームではThoughtWorksが提唱する「Technology Radar」を導入しています。

Technology Radarは、技術の採用や評価を4段階（Adopt / Trial / Assess / Hold）に分類し、意思決定を支援するフレームワークです。私たちはこのモデルをiOS開発に合わせてカスタマイズし、チームメンバー間でディスカッションを行い、現在プロジェクトに導入されている技術を網羅的に分類し可視化しています。

この取り組みにより、技術選定に一貫性が生まれ、レビューや設計の議論でも各技術の扱いが明確な前提のもとで議論できるようになりました。チーム内で“技術の地図”の共通認識があることで、意思決定のスピードと納得感が大きく向上したと感じています。

このトークでは、Technology Radarの基本的な概念から、iOS開発に合わせてカスタマイズしたフレームワーク、そしてチーム内での運用方法を紹介します。

Swiftの勉強を始めたばかりの頃は、自分のアイデアをアプリとして形にすること自体がとても楽しく感じられました。 しかし、学習や開発を重ねるうちに、エンジニアにとって重要なのは単なる実装に留まらず、いかに効率的かつ安全に実装できるかであるという考えを持つようになりました。

その中で「クラスと構造体を使い分ける際、メモリの観点ではどのような違いがあるのだろう？」という疑問が生まれ、やがてそれはより根本的なメモリ構造、つまりハードウェアレベルでのメモリの仕組みへの関心へと広がっていきました。 メモリにはコード領域・データ領域・ヒープ領域・スタック領域があり、それぞれの役割について図解しながら調べて学習を進めました。

この学習を通して、COW（Copy-On-Write）構造、クラスと構造体の選定基準、ARCやクロージャのキャプチャの仕組みなど、これまで何となく知っていたけれどうまく説明できなかった概念を、より明確に理解し、自分の言葉で説明できるようになりました。 今回のルーキーセッションでは、こうした学びと気づきを皆さんに共有したいと思います。

トーク内容

• コード・データ・ヒープ・スタックに関する概念の解説と図解
• クラス vs 構造体、値型 vs 参照型 ― 実際のメモリ使用の違いと選定基準
• Swiftにおける自動メモリ管理（ARC）とメモリリーク、クロージャのキャプチャ問題

チームで最も多くのバグを発見する私が、日常的に実践しているテストの観点を共有します。実装の隙を突くイレギュラーなテストでいかにしてアプリの品質を守るのか。その具体的な手法と、明日から実践できるマインドセットをお話します。

WebからiOS開発に転身した私が最初に直面したのは、「ドキュメントが抽象的で、読んでも実装のイメージが湧かない」という大きな壁でした。しばし実際に動作確認してみないと理解できないものが多々あり、スピードが求められる開発現場ではこの「試行錯誤の多さ」はボトルネックとなりました。なぜ、これほどまでに分かりにくさを感じるのか？ 本発表では、その原因をWeb開発者にはお馴染みのドキュメントMDN Web Docsとの「文化の違い」から考察し、筆者を救った「ドキュメント」についてお話します。

WWDC23でApple公式のローカライズ管理機能「String Catalogs」が発表されました。
しかし、初期バージョンでは、他のライブラリと比べて選択に迷う部分もあり、「他のローカライズライブラリの方が便利」「移行はまだ早いかも」と感じていた方も多いのではないでしょうか。

今年のWWDC25でString Catalogsの新機能が発表され、Xcode 26から利用可能になりました。
特に「Generated Symbols」機能により、TextやStringをシンボル指定できるようになり、利便性が大きく向上しています。
R.swiftやSwiftGenで実現できていた機能も登場し、いよいよ移行を検討するタイミングかも?

このトークでは、新しくなったString Catalogsの注目機能を紹介し、R.swiftやSwiftGenなど他のローカライズライブラリと比較しながら、その利点についてお話しします。

魅力的な体験や没入感のあるアプリを作るためには、写真や動画などのメディアコンテンツを効果的に表示することが欠かせません。
iOS標準のPhotoアプリでは、優れたレイアウトとジェスチャーに対応したインタラクションで写真・動画のコンテンツを心地よく閲覧できます。

Rettyでは、ユーザーさんが投稿した写真を「iOSのPhotoアプリのような体験で振り返られる」というコンセプトでメモリーズという機能を開発しました。
その際、UICollectionViewのCompositionalLayoutやTransitionLayoutを総動員して、モザイクレイアウトやレイアウトの切り替えなど、写真を振り返るリッチな体験を実装しました。

このLTでは、新機能の開発の流れを、ユーザー体験の作り込みや、それにまつわる技術的な観点でお話しします。

トーク内容:

• iOSのPhotoアプリにおける注目すべき体験
• メモリーズ機能で写真振り返り機能を実装した際の技術構成と実装の流れの紹介
• 没入感のある体験のためにUICollectionViewのカスタムLayoutやTransitionを作り込んだ箇所の紹介

参考:
メモリーズ機能: https://corp.retty.me/news/article/?id=8ahxxd_ukqf

Swift Package Manager（SPM）は、もはやiOS開発に欠かせないツールです。しかし、皆さんは Package.swift ファイルの中身をじっくり読んだり、自分でゼロから書いたりしたことがありますか？Xcode任せで、「とりあえず動けばOK」と思っていませんか？
このLTでは、まずSPMを使い始めたばかりの初心者の方に向けて、Package.swift の基本的な構造、各項目の役割、そしてシンプルなパッケージの作り方を分かりやすく解説します。そして、中〜上級者の方には、「え、そんなこともできるの！？」と膝を打つような、「カスタムビルドツールプラグイン」という応用テクニックをご紹介します。
この機能を使えば、Package.swift を起点にコード生成やリンティングといったビルドプロセスを自動化できます。普段意識しない Package.swift の奥深さに触れることで、SPMをより深く理解し、あなたの開発ワークフローをさらに効率化するヒントが得られるはずです。

「ゲームの攻略アプリやファンアプリを作りたいけど、著作権ってどうなってるの？」 個人でアプリ開発をしていると、誰もが一度はぶつかるこの疑問。特に既存の有名ゲームのキャラクターや世界観を使用することについて、漠然とした不安を抱えている方も多いのではないでしょうか。 本LTでは、実際に個人開発者が知っておくべき著作権の基本的な考え方や、実際にどこまでが許されて、どこからが侵害になるのかを、過去の事例や企業のガイドラインも交えて解説します。 法的な専門用語を避け、あくまで「個人開発者の目線」で、アプリ開発で著作権トラブルを回避するためのヒントをお伝えします。

筋トレを始めてすぐは効果を実感できますが、数ヶ月経つと目に見える成果が停滞し、モチベーションが低下しがちです。
私自身も筋トレを3ヶ月ほどやってきましたが、最近は成長の停滞を感じます。
そんな状況を打破すべく、Apple WatchやiPhoneで測定した体脂肪率、筋肉量、消費カロリーなどのヘルスケアデータをHealthKitを用いて「見える化」し、栄養素や運動量の数値の変化でどれだけの筋肉の成長が期待できるのかを検証していきます。
普段なんとなく計測しているApple Watchの運動量測定データを活用すれば、筋トレに効果的ではないかと考えたことが始まりです。
世の中には数多の筋トレ記録アプリがリリースされていますが、栄養素と運動量等のデータにフォーカスしたものは見つけられませんでした。
本発表では、HealthKitから得られるデータの紹介、取得したデータを活用した最適な栄養素の摂取量測定、実際にアプリを使用して得られた体脂肪率の減少や筋肉量の増加といった検証結果を紹介します。
HealthKitであなたの最適な身体作りプランを知り、筋トレの停滞を打破していきましょう！

　長年運用されてきたアプリケーションのデバッグメニューは、開発を円滑に進める上で不可欠な存在です。しかし、弊社のプロダクトに組み込まれたデバッグメニューは、開発当初から10年近く利用され続け、機能追加に伴う肥大化や、モダンな開発手法との乖離といった技術的負債に直面していました。特に、古い実装が原因でSwiftUIへの対応が困難となり、さらにはCocoaPodsからSPMへの移行が思うように進まないといった具体的な課題を抱えていました。

　本セッションでは、このレガシーなデバッグメニューをSwiftUIで全面的に刷新したプロジェクトの全貌をお話しします。リニューアルに至った背景から、その進め方、そして具体的な技術選定に至るまでを詳細に解説します。

具体的には、以下のようなテーマに焦点を当てて解説します。

• 旧デバッグメニューの課題と、それらを解決するための新しいデバッグメニューの設計思想。
• ネットワークログの収集にPulseを、一般的なログ出力にswift-logを導入した経緯とその効果、具体的な活用方法。
• 開発効率を劇的に向上させる新デバッグメニューに実装した便利機能の数々とその紹介 。
• そして、CocoaPodsからSPMへの移行に挑戦したものの断念せざるを得なかった苦い経験や、使えなくなってしまったUIデバッグツールへの対応 など、実務で直面した困難とそこから得られた教訓についても包み隠さず共有します。

このセッションを通じて、聴講者の皆様には、大規模な既存コードベースのモダナイズにおける具体的なアプローチ、最新のデバッグツールの導入と活用方法、そして現場で役立つ設計の知見を持ち帰っていただけます。技術的課題に直面している方、開発効率の向上を目指す方にとって、実践的なヒントと明日からの開発に活かせる学びを提供することをお約束します。

1. Rosetta 2とは
   • Rosetta 2について詳しく紹介します。
   • Rosetta 2に依存し続けることで将来的にどのような課題が生じるかを説明します。
2. 2つのCPU
   • Intel CPUとApple Siliconの特徴を比較し、それぞれの利点と制約を詳しく紹介します。
3. Rosetta 2なしで生きるために
   • Rosetta 2に依存しない開発手法の紹介。
   • Apple Siliconの特性を最大限に活用するための最適化手法を紹介します。

―「最近アプリがもっさりしてきた」「なんだか動作がもたつく」―
こうしたパフォーマンスに関するフィードバックを一度は受け取ったことがあるのではないでしょうか。
しかし、この「もっさり」は一体なにが原因で、どれくらい遅いのか？定性的な印象だけでは、改善の手がかりがつかめません。
弊社が開発しているアプリでも、特に利用頻度の高いユーザーから「もっさりする」といった声が寄せられていました。
そんな見えない「もっさり」の正体を明らかにし、改善につなげるためにMetricKitを活用しました。

このトークで話すこと

本トークでは、ユーザーの「アプリがもっさりする」という定性的な問題を、MetricKitを使って定量的に分析し、改善した方法を紹介します。

• MetricKitを使ったパフォーマンスの見える化
• メトリクスの分析から見えたボトルネックとなっていたCoreDataの処理
• 実際に行った改善アプローチとその効果
• コードのパフォーマンスを測定する方法

あなたのアプリにも、ユーザーがまだ言葉にしていない「もっさり」が潜んでいるかもしれません。
パフォーマンス改善の第一歩は、現在の状態を正しく測ること。つまり、「定量化」です。
本トークを通じて、ユーザーの体感を数字で捉え、改善へつなげる方法を知ることができます。
ユーザーから「アプリが軽くなった！」という喜びの声を聞く方法を一緒に学びましょう！

先日、生成AIのAPIを利用してユーザーがAIとチャットできるアプリをリリースしたところ、ユーザーがリクエストするプロンプトが激しすぎて1ヶ月でAPIレベルで垢BANされました。

生成AIを利用したアプリ開発では、利用規約で定められた禁止事項（違法行為助長、ヘイトスピーチ、誤情報拡散など）に抵触すると、APIレベルで利用制限や停止を受けるリスクがあります。多くの開発者が「運用開始時は問題なかったものの、禁止ワードや表現の見逃しで制限→サービス停止」という課題に直面しているのではないでしょうか？

本セッションでは、実際にGemini APIを中心に、禁止事項に引っかからないようにする対策から、Googleから警告が来た時の対処方法まで紹介します。

どこからでも触れるシングルトンは、スレッド安全性を保証しないまま肥大化しがちです。結果として実行時のクラッシュや不具合の温床になり、保守コストを引き上げます。Swift6では strict concurrency checkingがデフォルトで有効化され、Sendable 準拠や @MainActor／actor の宣言によって静的にデータ競合を防げます。シングルトンもここに乗せれば「安全な共有状態」へ生まれ変われます。

しかし、 巨大な責務を抱えアプリ全体の至る所から利用されてしまっているいわゆる"神シングルトン" は、Actor 化しようにも MainActor と非 MainActor のコードが混在し、さらには大量の状態管理を行なっているなど、Swift6への対応を複雑化させます。シングルトンを解体して適切な単位にリファクタリングすることはSwift6への対応においても、コードの保守性においても理想ですが、神シングルトンは影響範囲が広く、重要な機能を担っていることも多いため、現実的な選択肢としてリファクタリングを選択できないことも多いかと思います。

本トークでは、そんな神シングルトンを神シングルトンのまま実際に Swift 6 へ対応させた経験をもとに、対応する上でありがちな状況、工夫、知見を共有します。
皆さんのプロジェクトに眠る神たちをSwift6の世界に安全にお連れするためのご参考になれば嬉しいです。

Swiftで非同期処理といえば、かつてはClosure一択。ですが、複雑なネストや可読性の低さに悩んだ経験はありませんか？
本LTでは、若手エンジニアである私が「Closure地獄」から抜け出すきっかけとなった個人開発でのasync/await体験をもとに、チーム内での技術導入に挑戦した実話をお話しします。
私は学習の一環でFirebaseとSwiftUIを使ったチャットアプリを開発していました。そこではじめてSwiftのasync/awaitを本格的に使い、kotlinライクなtry-catch構文処理の見通しやすさ、エラーハンドリングの明快さに衝撃を受けました。
「これ、業務でも絶対に使える」
そう確信し、上司やチームの理解を得るために比較資料を作成し、サンプルコードを用意して小さなPull Requestから導入を開始しました。反対意見や不安の声もありましたが、自分で課題を見つけ、自分で提案し、自分でコードを書いて示すことで、徐々に受け入れられていきました。
今では、チームの新しいコードには自然にasync/awaitが使われるようになり、非同期処理の可読性が大きく改善されました。
この経験を通じて実感したのは、「仕事は与えられるものだけじゃない。自分で作ることもできる」ということです。
若手でも、技術の力でチームを変えられる。その一歩を踏み出す勇気を、このLTで少しでもお伝えできたら嬉しいです。

iOSDC と同い年の OS が Apple のプラットフォームにはあります。
それが watchOS です。
watchOS は、Apple Watch と一緒にリリースされ、そのわずか6週間後の WWDC 2015 において最初に公式プレビューされました。
それ以降、iOS、 macOS などの OS とともに毎年アップデートが行われ、多くのユーザー、開発者に愛されてきました。

このセッションでは、10歳を迎えた watchOS の歴史を5分に凝縮し、ユーザー体験の向上や開発者向け機能の拡充といった具体的な進化のポイントについて説明します。
我が子の成長を見るように、暖かく見守っていただければ幸いです。

SwiftUIでUIを実現したいが表現力が足りない。そんなときに便利なのがUIViewRepresentableやUIViewControllerRepresentableです。
しかし、そのRepresentableシリーズの使い方はちゃんとマスターしているでしょうか？
Representableシリーズには、Appleのドキュメントを読むだけではわからない、いくつかの『罠』が存在します。なんなら、AppleのサンプルコードですらハマっているCoordinatorのアンチパターンまで存在するのです。
このセッションでは、そうしたドキュメントを読むだけではわからないアンチパターンに焦点を当て、堅牢なコンポーネントを作るための指針をお教えします。

Swift 6の足音が聞こえる今、私たちのコードは大きな変化に直面します。特にConcurrencyチェックは「警告」から「エラー」へとその厳格さを増し、私たち開発者にはより正確なコードが求められるようになります。この変化に備え、私たちが日頃から頼りがちな@MainActorの使い方、一度本気で見直しませんか？

「UIに関わるかもしれないし、とりあえずクラス全体に付けておけば安全だろう…」

その、善意からくる@MainActorが、実はUIのカクつきやパフォーマンス低下を招く「静かなる技術的負債」になっているかもしれません。ネットワーク通信やJSON解析といった、本来バックグラウンドでやるべき重い処理までメインスレッドを占有してしまうアンチパターンは、今こそ断ち切るべきです。

このトークでは、そんな「@MainActorの汚部屋」状態を具体的なコードで示し、どこに付け、そしてどこに付けてはいけないのかを明確に切り分けます。パフォーマンスとコードの見通しの良さを両立させるための、明日からすぐに実践できる「@MainActor大掃除テクニック」を、5分という短い時間に凝縮してお届けします。

合言葉は「@MainActorは、UIスレッドへの最後の出口だけ」。

このトークを聴き終えた時、あなたはきっとご自身のコードから不要な@MainActorを一掃し、気持ちよくSwift 6を迎え入れる準備を始めたくなるはずです。

「このAIツールを使えば、チームの開発はもっと効率的になるはず！」

そんな純粋な期待を胸に、新卒エンジニアとしてAIツールの導入に挑戦しました。
しかし、その先に待ち受けていたのは、技術的なメリットだけでは乗り越えられない、ツール選定、予算、社内申請、そして導入効果への説明責任といった、いくつもの「見えていなかった壁」でした。

特に当時のiOS開発においては、メインのIDEであるXcodeにAIが統合されておらず、拡張機能も不安定でした。そのため、他の開発環境と比較して、AIツールのサポートが不足していました。また、VSCodeを普段の開発でメインに使うのもチームメンバーに抵抗なく受け入れてはもらえない状況でした。
さらに多くの企業にも当てはまるように、AIツールの導入に関する予算が限られており、検証のための時間も捻出しづらいのが現実です。

本トークでは、そのような状況の中、新卒エンジニアの私が所属チームにGitHub CopilotやCursorをはじめとする生成AIツールを導入する過程で経験した、リアルな失敗談を共有します。
そして、その経験から得た「ツール選定前にチームの課題を明確にすることの重要性」や「導入効果を具体的に示すためのアプローチ」といった、新卒エンジニアが失敗を通して改めて伝えたい教訓についてお話します。

デザイナーからFigmaファイルを受け取って実装する際、コンポーネントの細かい値を確認したり、デザインシステムとの整合性を保つのに時間がかかることがよくあります。

Figmaから公式にリリースされたDev Mode MCPサーバーを使うことで、CursorやClaude CodeからFigmaのデザイン情報を直接取得し、SwiftUIコードの生成を効率化できるようになりました。
公式MCPサーバーならではの正確なメタデータ取得により、より信頼性の高いコード生成が可能です。
このLTでは、実際にiOSプロジェクトで試した活用例をご紹介します。