トーク

Xcodeは好都合に未完成
だから美しいんだ
---「珍獣 / ウホイクション」の歌詞より抜粋

Xcodeは、最低というには魅力的過ぎる。
---ウレンタの言葉

私たちがiOSアプリを開発するときに必要不可欠なツール、Xcode。

「SwiftUIのプレビューが動かない」「リネームに失敗する」「嘘の警告やエラーを表示する」などの挙動により、何かと批判されがちです。

しかしApple公式が提供しているIDEです。当然素晴らしいに決まっています。

本トークでは、Xcodeの問題に目を瞑り、便利なtipsを紹介します。

●話すこと
・Xcodeで便利な機能やショートカットキーの紹介

●話さないこと
・Xcodeの問題点
・基本的な機能の紹介

俺は今、完成されたXcodeが見たいってことです。

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

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

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

このトークでは、UICollectionViewLayoutに実装されているAPIで、シンプルなタイル表示を拡張する方法をお話しします。

トーク内容

• iOSのPhotoアプリにおける注目すべき体験と、それらを再現する方針
• UICollectionViewで複雑なモザイクレイアウトを構築
• 複数のLayoutを、 UICollectionViewTransitionLayout を用いてインタラクティブに切り替える方法
  • タイル表示の切り替えのアニメーション実装
  • デフォルトのアニメーションとカスタム実装の解説
• UICollectionViewLayoutAttributes を操作してスクロールに応じた挙動を作成する
  • Cell / SupplementaryViewの LayoutAttributesを画面内の位置に応じて変更するなど

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

本セッションでは、「Verify With Wallet API」を使って実装した本人確認機能についてご紹介します。メルペイではこれまでeKYCを活用した本人確認機能を提供し、特にマイナンバーカード読み取りを用いたリアルタイム認証では最短1分で完了する仕組みを実現してきました。しかし、署名用電子証明書のパスワードを忘れるなどの課題により、認証プロセスを完了できないお客さまも少なくありませんでした。2025年6月にAppleとデジタル庁が連携し、iPhoneのApple Walletにマイナンバーカードを登録できるようになったことで、Face IDを使った生体認証によりパスワード入力なしで本人確認が可能となり、さらに簡潔でスムーズな体験を実現しました。
本機能の開発は、日本国内ではもちろん、アメリカ以外の国として初めての事例であり、Appleとデジタル庁が2025年6月24日にリリースした最新機能を活用しています。

主なセッション内容:

• Apple Walletへのマイナンバーカード対応がもたらす本人確認の簡略化とその仕組みや実装
• 開発において直面したAppleの未公開APIの活用方法
• Appleおよびデジタル庁の要求に応じた厳格な開発プロセスと対応策

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であなたの最適な身体作りプランを知り、筋トレの停滞を打破していきましょう！

今年初めに、私はカメラアプリ 「SLIT_STUDIO」 を開発し、リリースしました。このアプリは、スリット・スキャンという旧来の VFX 技術を再現したものです。スリット・スキャンを簡単に解釈するとスリット（線）で風景を撮影し、それによって得られた画像を重ね合わせて二次元の画像を生成する VFX 技術です。

アプリを初めてインストールするユーザーにスリット・スキャンの原理を理解してもらうために、オンボーディング画面を用意しました。その最初に、インタラクティブな起動画面を設置しました。この起動画面では、ユーザーが直感的にスリット・スキャンの原理を体験できるようにしています。

オンボーディング全体はこちらの動画をご覧ください：https://drive.google.com/file/d/1i8GSxg5EYyz07-iMH-tz7KtSd0tPpZZv/view?usp=sharing

最初の起動画面では、画面を長押しすると、スキャンラインが下から上に移動して、指を離すと元に戻ります。スキャンラインの下には、この起動画面をスリット・スキャンに通した結果を表示します。SwiftUI と Metal Shader を使用して作成しました。

SwiftUI には、Color Effect, Distortion Effect, Layer Effect の3つの Shader API があります。 この画面で3つすべてを使用しました。
このトークでは、画面のデザインからAPIの選択、実装に至るまで、この起動画面を制作した流れを詳しく話します。アプリでの Shader の応用に関する参考になる情報を提供できれば幸いです。

重要ポイント：

• 3つの Shader API の使いわけ
• SwiftUI だけでできないこと
• 性能を良くするために頑張ったこと

　長年運用されてきたアプリケーションのデバッグメニューは、開発を円滑に進める上で不可欠な存在です。しかし、弊社のプロダクトに組み込まれたデバッグメニューは、開発当初から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の処理
• 実際に行った改善アプローチとその効果
• コードのパフォーマンスを測定する方法

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

Swiftファイルがコンパイルされるのと同じように、プロジェクト内のアセットカタログ（.xcassets）もビルド時にコンパイルされます。Swiftのコード量が増えるとコンパイル時間が伸びるのと同じように、アセット数が増えるとコンパイル時間も無視できなくなります。

例えば、数百のアセットを持つプロジェクトでは、クリーンビルド時のアセットコンパイルだけで数分以上かることがあります。

このコンパイルを担当するのが、Xcodeに同梱されている actool というツールです。ビルドフェーズでactoolが実行され、Assets.carを生成しています。

本トークでは、actoolを活用して事前にアセットをまとめてコンパイルし、生成したAssets.carをプロジェクトに組み込むことで、Xcodeビルド時のアセットコンパイルを実質的にゼロ秒にする方法を紹介します。

【話すこと】

• actoolとは何か、どこにあるか
• アセットコンパイルの仕組み
• 事前コンパイル済みAssets.carを生成してプロジェクトに組み込む手順
• アセット名のハードコーディング回避策
• XCFrameworkとの比較と使い分け

先日、生成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の世界に安全にお連れするためのご参考になれば嬉しいです。

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

しかしながら、シングルトンはその特性上、通常のクラスよりも修正による影響範囲が広くなってしまうので、Sendable / actor / @MainActor の方針選択が一筋縄ではいきません。さらに UI 層・ネットワーク層の処理・状態管理など巨大な責務を一身に抱えたいわゆる"神シングルトン"が存在している場合、MainActor と非 MainActor のコードが混在する等、方針選択をより複雑化します。問題の簡単化のため、リファクタリングでシングルトンを適切な単位に分解することは一つの手ですが、重要機能を担っている場合や改修コストをかけれない場合、現実的な選択肢として選びづらいことも多いかと思います。

本トークでは、シングルトンを実際に Swift 6 へ対応させた経験をもとに、シングルトンをシングルトンのまま安全にSwift6に対応させる上での工夫、知見を共有します。具体的には以下をお話しします
・シングルトンをSwift6対応させるための基本的な方針
・神シングルトンにありがちな状況と対応方針

皆さんのプロジェクトに眠るシングルトン達をSwift6の世界に安全にお連れするためのご参考になれば嬉しいです。

みなさん、ユニットテストを書いていますか？
今回は、私たちの会社でどのようにしてユニットテスト文化を社内に根付かせたか、そのプロセスと成果についてお話しします。

まず初めに、ユニットテストの重要性について簡単に触れ、なぜ私たちがこの取り組みを始めたのかを説明します。次に、具体的なステップとして、教育プログラムの実施や、社内でのベストプラクティスの共有方法について紹介します。また、チームメンバーの意識改革を促すための工夫や、実際に直面した課題とその解決策についてもお話しする予定です。

最後に、この取り組みの結果として得られた社内の変化や、プロジェクトの品質向上にどのように寄与したかについて詳しく説明します。皆さんの組織でもユニットテスト文化を根付かせるためのヒントを得られるセッションにしたいと考えています。

ぜひ、私たちの経験を通じて、ユニットテストの重要性とその効果について理解を深めていただければ幸いです。

Swift Macrosを日常の開発で活用できていますか？

Swift 5.9から導入されたマクロ機能は、Swiftコードをコンパイル時に生成できる仕組みで、定型的なコードの生成や、静的解析によるバリデーションが可能になります。
最近では、Swift公式からSwift Syntaxのビルド済みバイナリが提供されるようになり、これまで導入のハードルとなっていたビルド時間の問題も軽減され、より気軽にマクロを活用できる環境が整ってきました。

Apple自身も #Preview や @Observable、#expect（swift-testing）など、マクロを積極的に活用しており、実際のプロジェクトでも目にする機会が増えてきています。
また、サードパーティ製のOSSにおいても、Swift Macrosを活用したライブラリが次々と登場しています。例えば、イニシャライザの生成、プロトコル準拠の生成、文字列リテラルの静的検証など、ユースケースは多岐にわたります。

本トークでは、こうしたOSSにおける実際の利用事例をもとに、Swift Macrosがどのような課題を解決しているのかを分析し、活用パターンを体系的に分類します。そして、「自分のプロジェクトでどんなMacroを使えばよいか」「どう活用すれば開発効率を上げられるか」といった観点で、実践的な知見を共有します。

本トークを通して、皆さんがプロジェクトに最適なマクロを選択・活用できるようになることを目指します。

AI Agentの進化によって、「Design to Code」への期待値が大きく高まっています。

その動きを受けて、Figmaで作成されたデザインを元に、GitHub Copilot Agentを活用してSwiftUIコードを自動生成する取り組みを行いました。
精度向上のためにコンテキスト整備（ディレクトリ構造、コード規約、TCAの実装パターンなど）やプロンプト最適化（実装計画や注意事項の指示追加など）を試みましたが、リスト表示の消失やアイコンがそのまま残るなど、UIの再現度が著しく下がってしまい、期待通りにAgentが動いてくれないこともしばしばでした。

これらの課題をどのように解決し、どのような結果が得られたのか、AI Agentを使いこなすために得られたヒントをお話しします。

• The Composable Architecture（TCA）を用いた SwiftUI のコード生成は可能か
• デザイン再現性を高めるための GitHub Copilot Agent 使いこなし術
• Figmaデザインデータの作り方と生成コードの品質は相関するのか

本セッションでは、Flutterで開発されている出前館アプリにおいて、継続的かつ安定的なリリースを実現するために導入した「リリーストレイン」の運用設計と、運用初期に直面した課題・工夫について実践的な知見をお届けします。
さらに、App Store / Google Play への申請時に発生したイレギュラーケース（審査の長期停止、日本国外からのアクセス制限によるリジェクト、プライバシーポリシー指摘など）にどのように対応したのか、その事例を共有します。

開発現場でリリース業務に携わるなか、多くの関係者が関わるアプリのリリースや、ストア審査の不確実性に対して、再現性のあるプロセスを設計・維持することの難しさを日々感じています。
現場での実践を通じて得た知見を共有することで、同じ課題を持つアプリ開発チームに役立てていただけたら幸いです。

1. 出前館アプリの開発体制とリリースの課題

   • Flutter製の大規模アプリとしての特徴
   • リリースの不安定さ・調整コスト

2. リリーストレイン導入の経緯と設計

   • なぜリリーストレインを選んだのか
   • 月2回のリリーススケジュールと周辺業務の整備

3. リリーストレイン運用の工夫と課題

   • 開発チーム・QA間の連携改善
   • 運用安定化までに乗り越えた壁とその対応

4. ストア申請時のイレギュラーケースとその対応

   • App Storeの審査が長時間止まった事例
   • 国内限定サービスが審査に与えた影響
   • Google Playでのライブラリ由来のプライバシーポリシー指摘対応

想定する対象者

• モバイルアプリのリリースを担当しているFlutter/iOS/Androidエンジニア
• 複数の関係者と連携しながら、継続的なアプリ運用を行っているPM・EM・技術リーダー