トーク

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

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

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

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

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

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

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

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

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

魅力的な体験や没入感のあるアプリを作るためには、写真や動画などのメディアコンテンツを効果的に表示することが欠かせません。
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およびデジタル庁の要求に応じた厳格な開発プロセスと対応策

今年初めに、私はカメラアプリ 「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 だけでできないこと
• 性能を良くするために頑張ったこと

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

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

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

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

【話すこと】

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

どこからでも触れられるシングルトンは、スレッド安全性を保証しないまま肥大化しがちです。結果として実行時のクラッシュや不具合の温床になり、保守コストを引き上げます。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を使えばよいか」「どう活用すれば開発効率を上げられるか」といった観点で、実践的な知見を共有します。

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

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

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

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

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

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

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

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

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

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

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

想定する対象者

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

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

このトークで話すこと

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

• MetricKitの概要と選定理由
• MetricKitを使ったパフォーマンスの見える化
  • メトリクスの収集プロセス
  • メトリクスの分析手法と整理方法
• メトリクスの分析から見えたボトルネックとなっていたCoreDataの処理
• 実際に行った改善アプローチとその効果
  • CoreDataの処理の最適化
  • 計算量を意識した実装
  • 結果：処理時間を大幅短縮し、ユーザー満足度も向上
• コードのパフォーマンスを測定する方法

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

​Swiftは安全性と効率性を両立する言語ですが、従来の画像処理APIであるvImage_BufferはObjective-C時代から存在しており、ポインタ操作やメモリ管理の難しさ、型の安全性に課題がありました。これらの問題を解消するために登場したのがvImage.PixelBufferです。

​本セッションでは、vImage_BufferからvImage.PixelBufferへ移行した実体験をもとに、以下の観点から、Swift時代のモダンな画像処理の設計と実践を解説します：

・ vImage.PixelBufferとvImage_Bufferの使用感とAPI設計の違い
・ 型安全性・自動メモリ管理による利点と、移行時に直面したギャップ
・ 安全性とパフォーマンスのバランス：PixelBufferを活用した効率的な画像処理パイプラインの構築
​・ vImage.PixelBuffer導入・リファクタリングの実践Tipsと注意点

​対象は、Swiftで画像処理を行っているiOSアプリ開発者や、vImage.PixelBufferの導入を検討しているエンジニアです。Cの壁を越えて、Swiftらしい表現で画像処理をより安全に、より簡潔に扱うための道筋を共有します。

私が現在開発に携わっている iOS アプリでは、 iOS Deployment Target が 15 に上がったことを機に、今年から本格的に SwiftUI の導入を開始しました。

現状、機能・UI 共にシンプルな画面への対応が中心ということもあり、 MVVM パターンに近い設計方針で実装が進められています。しかし、複雑な画面でも設計が適用可能かどうかなど、今後へ向けた課題も抱えています。

また、 SwiftUI はバージョンが上がるごとに機能追加が行われていますが、一方で iOS Deployment Target によって使用可能な機能に制限が生じることから、プロダクトのサポート方針を考慮し、長期的なメンテナンス性維持の観点から SwiftUI の導入を進める必要があります。

本トークでは、 画面の複雑度 と iOS Deployment Target (本トークは 15 以上を対象とします) という 2 つの変数を元に、ケーススタディや実際のアプリの事例を交えて最適な設計方針について検討した結果をご紹介します。

アジェンダ

• iOS Deployment Target から見た SwiftUI
• 画面の複雑度から見た SwiftUI
• 画面実装ケーススタディ 〜 iOS Deployment Target 15 から 18 まで
• 画面実装ケーススタディ 〜 単機能な画面から複数の API 呼び出しを伴う画面まで

本セッションは、位置情報アプリを開発しているエンジニア、あるいは位置情報データの効率的な扱いに関心のあるエンジニアを対象とし、アプリ開発の現場で直面する課題をもとに、位置情報の取り扱いに必要なデータ構造やアルゴリズムの実践知識を紹介します。

位置情報アプリでは、ユーザーの位置をもとに地図上に線や領域を描画したり、特定の場所が移動禁止エリア内にあるかを判定する機能が求められます。しかし、これらの処理は地図データの量が膨大であること、位置情報が連続的かつリアルタイムで変化することから、パフォーマンスやデータ効率の観点で多くの課題に直面します。

本セッションでは、こうした課題を解決するための具体的な技術として、以下の内容を解説します。
• Google Mapsで使われている「Encoded Polyline algorithm」：ポリラインやポリゴンを効率的に表現し、データ転送量を削減する方法
• Point in Polygonアルゴリズム：特定の位置がポリゴン内に含まれるかどうかを判定する仕組み
• 位置をポリゴン外に押し出すための最短距離計算アルゴリズム：ポリゴンの外にある「最近傍点」を求めるための幾何計算手法
• 凸包アルゴリズム：簡易的に複数のポリゴンを合成する手法

これらの技術は、単なる理論ではなく、アプリ開発の現場で実際に役立つ知識として紹介します。ポリゴン内判定の最適化や地図上でのオーバーレイ描画の工夫など、具体的な課題解決の実例を交えながら、技術の必要性と効果をわかりやすく伝えます。

聴講後には、位置情報アプリのデータ構造・アルゴリズムの実践的な知識が身につきます。

.bold() や .foregroundColor() などの一般的なModifierと、
iOS15以降に導入されたAttributedStringを用いた柔軟で強力な部分装飾。

SwiftUIでテキストを装飾するこの2つのアプローチは、
見た目こそ似ているものの、その仕組みや設計思想は大きく異なります。

• 差分更新のメカニズム
• アニメーションの動作特性
• パフォーマンスの特性
• 複雑なハイライトを含む表現力

など、見た目だけでは気づけない現場でハマりがちな落とし穴を徹底的にひも解きます。

このトークでは、SwiftUIのレンダリング仕様をもとに、
ModifierとAttributedStringの得意・不得意を余すことなく比較し、
実装サンプルやデモを交えてわかりやすく紹介します。

「同じUIを作るならどちらが最適か？」を迷わず選べる軸をお持ち帰りください。
普段なんとなく選んでいる人こそ、きっと新しい発見があるはずです。
初心者から中級者まで楽しめる、SwiftUIテキスト表現の探究にお付き合いください！

内容：

• SwiftUIにおける文字列装飾の基礎
• Text Modifierの仕様と強み・弱み
• AttributedStringの仕様と強み・弱み
• 同じ見た目を2通りで構築する比較デモ
• 差分更新・パフォーマンス・アニメーションの挙動の比較
• 適切な選択をするための判断基準

ある日、ユーザーから「画面をスワイプしてもカルーセルビューが動かない」との報告が届きました。

調査の結果、Xcode 16への開発環境とiOS 18への端末のアップデートを契機に、SwiftUIのジェスチャー優先順位に仕様変更があり、親ビューであるScrollViewとその子ビューであるカルーセルビューのジェスチャーが競合し、結果としてカルーセルビュー側のDragGestureが正しく検知されなくなっていたことが判明しました。

本セッションでは、ユーザー体験に大きな影響を与えうる、SwiftUIフレームワークのジェスチャーの仕様変更によって、どのようなViewの構成で問題が発生したのかを再現しつつ、発見から解決までの過程を丁寧に解説します。さらに、今後も仕様変更に耐えられるUI設計のヒントを共有します。

• iOS 18からSwiftUIのジェスチャー優先順位にどんな変更が加えられたのか？
• ジェスチャー競合によって引き起こされた問題とその解決の道のり
  • ScrollView vs .highPriorityGesture() の相互作用
  • DragGesture(minimumDistance:) による競合の回避とその副作用
  • UIGestureRecognizerRepresentableによる本質的な競合解消
• まとめ：再発を防ぐ設計と、変化に強いUIをどう作るか

Model Context Protocol（MCP）は、自然言語によるユーザーのプロンプトから、AIがツールを呼び出す際のリクエストを構造化し、外部サービスやアプリと連携できるようにするためのプロトコルです。

最近では、さまざまなアプリや開発ツールでもこの仕組みが使われるようになりつつあり、Swiftエンジニアにとっても無視できない存在になってきました。

本トークでは、
「MCPって聞いたことはあるけどよく分からない…」
「MCP Serverって何ができるんだろう…」
そのような方でも、SwiftでMCP Serverを構築する第一歩を踏み出せるように、わかりやすく、実践的にご紹介します。

具体的には以下のような内容を扱います：

1. MCP Serverとは
   • MCPとはどのような役割を持つプロトコルなのか、どのように利用されているのかわかりやすく説明します。
2. Swiftを用いてMCP Serverを構築する
   • MCP公式SDKを使用したMCP Serverの構築、IoTデバイスの操作、AIとの連携について解説します。
3. Swiftで構築したMCP Serverから実際にデバイスを操作してみる
   • 入力したプロンプトがどのようにMCP Serverを通じて処理され、デバイスが動作するのかを実演します。
4. 実際に構築して明らかになったこと
   • MCP Serverを実際に構築してみてわかった課題と今後の展望について共有します。

「AIと連携できる仕組み」をSwiftで体験しながら、MCPの世界に楽しく入門してみませんか？

visionOSやAndroid XRなど、私たち開発者にも「空間をどう見せるか」が問われる時代がやってきました。
このセッションでは、オープンソースの3D編集ツール「Blender」を使って、開発者が知っておくと便利な次の5つを紹介します。

• 3Dオブジェクトの作成
• アニメーション
• ノーマルマップとマテリアル
• プラットフォーム毎の書き出しと互換性
• バージョン管理

特に、ノーマルマップやマテリアル設定による軽量かつリッチな表現手法、glTF/USDZ形式での出力ポイント、そしてBlender Git Addonを用いたバージョン管理術など、「触ってみたいけどとっつきにくい…」と感じている方にこそ届けたい実践的な知見をお届けします。

SwiftUIが主流の昨今ですが、UIKitベースのレガシーコードと向き合っている方もまだまだいるのではないでしょうか。長い歴史を持つコードベースでは、複雑に絡み合った責務、肥大化したメソッド、長大なViewControllerなど様々な問題のあるコードに直面することがあります。このようなコードに出会った時、アーキテクチャの刷新や技術スタックの移行も重要ですが、まずは「読めるコード」にすることから始めるアプローチがあります。

「読めるコード」にするためには、ファイルの行数を減らし、関連する処理をまとめ、重複や不要なコードを削除するといった地道な改善が必要です。
このトークでは、実際のプロダクトコードで行った2つのViewControllerのリファクタリング事例を通じて、このような地道な改善を、比較的安全に段階的に実施していく方法を共有します。

また、「読めるコード」への改善は、AIを利用した開発においても重要な意味を持ちます。人間にとって読みやすいコードであることにより、AIもまたコードを理解し、適切な提案をすることができます。コンテキストウインドウの浪費も抑える事ができます。AIの恩恵を最大限に活かすためのリファクタリングについても考察します。

話すこと

• 「読めるコード」への段階的な改善手法
• 実際のプロダクトコードでの事例紹介
• コードの可読性がもたらすAIを利用した開発への効果

話さないこと

• 特定のアーキテクチャパターンへの移行
• UIKitからSwiftUIへの移行手法
• 理想論や銀の弾丸的な解決策

とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。

多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。

本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
また、「小さなPR」を実践すると先行PR・後続PRが連なっていきます。それぞれのPR同士の文脈を繋げる実践的なTipsも紹介します。

このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。

2025年秋にリリース予定の「macOS Tahoe 26」が、Intel製CPUを搭載したMacへ提供される最後のOSであることをAppleが発表しました。CPUアーキテクチャの異なるApple Siliconへの移行という偉業を成し遂げたApple。その技術的背景を、いま一度振り返ってみる価値があるのではないでしょうか。

本トークでは、Appleが歩んできたCPUアーキテクチャの変遷を振り返りつつ、x86からArm（Apple Silicon）へと至る道のりを解説します。そして、実際にApple Silicon搭載Mac上で動作するアセンブリコード（計算と文字出力）を題材に、命令セット・システムコール・レジスタといった低レイヤの要素をやさしく紹介します。

アセンブリは一見アプリ開発に無縁に思えるかもしれませんが、実はクラッシュログ解析やパフォーマンス調整、Rosetta 2の仕組み理解など、日常の開発と意外なところでつながっています。iOSエンジニアが“いまこそ”学び直す意義のある低レイヤ世界を、一緒に覗いてみませんか？