プロポーザル

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

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

Swift Concurrencyにおいても、非同期処理を同期制御したいケースがあります。たとえば非同期に複数のリクエストが同時に走るが、実行すべき処理は一度きりでよいという状況です。しかし、Swift ConcurrencyにはDispatchSemaphoreに相当する同期制御機能が用意されておらず、このような要件を満たすにはちょっとした工夫が求められます。

このトークではアクセストークンの更新処理をユースケースに取り上げて、複数の非同期リクエストが同時に更新を要求しても初回の更新処理だけAPIを呼び出し、またそのレスポンスを後続の処理に再利用して使い回す方法を解説します。具体的にはwithCheckedContinuationを用いて非同期処理を同期制御する手法と、Actorを活用して取得したレスポンスを安全に共有・管理する手法を組み合わせることで、無駄なAPI呼び出しの抑制や共有データの競合を回避の実現が可能です。

このトークを通じて、実務でそのまま応用できるSwift Concurrencyの効果的な使い方を習得しましょう。

リリース前のE2Eテストを、実サービスに適用可能なレベルで運用するには、ツールを導入するだけでは不十分です。
SwiftUI・UIKit・WebView が混在するiOSアプリにAppiumを用いたE2Eテストを導入・維持する中で直面したさまざまな課題と、それをどう解決してきたかを本セッションでご紹介します。

まず、accessibilityIdentifierの管理が煩雑になった問題です。
画面ごとにidentifierの付け方がバラバラで、統一された基準がないためにテスト実装時に混乱が生じていました。
この問題をプロジェクト内でどのように整理し、テストしやすい構造に落とし込んでいったのかをお話しします。

最後に、複雑なUIフローに起因するflakyテストの問題です。
日付選択 → オプション選択 → 決済画面への遷移 → WebViewでのメッセージ受信など、状態変化が多いフローにおいて、テストの安定性を確保するために取った構造的アプローチを紹介します。

3つ目は、E2Eテストをリリースフローに安定して組み込むための課題です
テスト実装 → 実行 → 結果確認 → QA → リリース、という一連のプロセスをどのように定着させたのか、実際のチーム運用をもとに共有します。

テスト自動化ツールを導入したものの、信頼性のあるテスト体制を作れずに悩んでいる方や、複雑なUI構成の中でテスト運用に課題を感じている方にとって、少しでもヒントとなれば幸いです。

WebPは、画像に対する高品質な可逆圧縮と非可逆圧縮を実現する、モダンな画像形式です。
WebP画像形式は同品質のPNG画像より約23〜26%小さく、非可逆圧縮の場合はJPEG画像より25〜34%小さくできるため人気の画像形式です。

iOS 14から標準でWebP画像の読み込みがサポートされ、UIImageで直接WebP画像を扱えるようになりました。

では、今から新しくWebP画像を扱うライブラリを作るということは無意味でしょうか？いいえ、そんなことはありません。自分で作るという行為は動作の原理や仕組みを学ぶことに非常に優れた手法です。

学習だけでなく実用の面でも、自作の場合は特定のユースケースに処理を最適化してパフォーマンスを発揮したり、標準のライブラリで発生する問題を回避できます。特にiOS 18では標準の方法では特定のケースでパフォーマンスが大きく悪化する問題があることがわかっています。

この講演ではWebPファイルフォーマットの基本仕様と構造、Swiftで構造を解析する方法、画像を圧縮する技術の原理と仕組みをステップバイステップで実際のコードを用いて解説します。

WebPのコーデックを実装することは「画像圧縮の理論」「ビット操作の職人技」「高速化・安全化の実務」を一気に学べる実践的な場です。特にSwiftで実装する場合は安全なメモリ管理と低レベルの最適化の両立というノウハウまで得られます。

普段のプログラミングとは一味違う、低レイヤーの実装を楽しんでみませんか？

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