トーク

XcodeCloudを快適に利用できていますでしょうか？

AppleはWWDC21にてCICDツールである "XcodeCloud" を発表しました。2021年登場から4年が経過し、他のCIツールに比べてコスト面の圧倒的優位性や導入の容易さ、署名周りの運用コストの低さなどから利用されることが多くなっています。
しかし、XcodeCloudは「マシンスペックの選択」ができないため、利用対象のアプリが巨大だとしても、より高価なマシンを選択することができず、1回の実行時間が普段の開発で利用するには耐えられないほど（40分〜）長くなってしまう問題があります。

本セッションでは、XcodeCloudを利用されている方や別のCIツールを利用している方を対象に、最小限の対応で現実的な実行時間（〜20分）に抑えるための改善についてお話します。具体的には最新のビルド改善方法やワークフローの最適化設定、差分テスト実行、パッケージ取得の効率化などの改善についてご紹介します。

以下の内容について紹介します。
・XcodeCloudの概要（実行環境、ワークフロー構築）
・XcodeCloudの改善 - 設定変更
・XcodeCloudの改善 - ワークフロー実行改善
・XcodeCloudの改善 - ビルド改善
・XcodeCloudの改善 - 差分テスト実行のための仕組み構築

現代のiOSアプリ開発ではSwiftUIの LinearGradient や MeshGradient 、CIFilterの linearGradientFilter などを使えば簡単にグラデーションを実現することができます。

多くの場合はこれらの強力なAPIを使うことで事足りるのですが、イラスト制作におけるグラデーション効果などにおいては、表現の幅を広げるためにより高機能なグラデーション描画を行いたいことがあります。

例えば、虹のような表現を行うためにグラデーションの制御点を複数用意したり、透明色からブラシ色に徐々にグラデーションするような表現が用いられたり、色の変化に緩急をつけるために補間関数を設定するようなケースがあります。

そのようなケースにおいて、既存コンポーネントでは実現することが難しいため、自分でシェーダーを記述して実現することになります。

このLTでは上記のような高度なグラデーションをAppleプラットフォーム向けのグラフィックスAPIであるMetalを利用して行った話と、その際にハマった透明色の扱いについて紹介します。

メソッドの命名は、処理の内容を語るものでなければならない──それは世の中に広く浸透し、誰もが当然のように従ってきた原則だった。
実際その教えは、長い間開発の秩序を保ち、プロジェクトの明瞭な設計へと導いてきた。

だがある時、この教えに一つの問いを投げかける者がいた。「ViewModelは、他の層と同じ命名規則では語りきれない存在ではないか。」と。
それは異端とされた。責務をわかりづらくし、統一性をなくし、抽象的で、実装を曖昧にするものだとされた。
それでも、複雑なUIと入り組んだ状態遷移の中で、その考え方は静かに、しかし確かに広がっていった。

これは、かつて正統派とされた命名に意を唱え、新たな視点を持ち込もうとした者たちの物語である。

本発表では、ViewModelの「UIとロジックの境界である」「Viewの抽象化である」という特性を踏まえ、そのメソッドの最適な命名について探っていきます。
また、一般的にメソッド名において是とされる「saveProfile」「fetchItems」のような処理内容中心の命名と比較し、UIイベントに即した「onSaveTapped」「onRetryRequested」といったイベント中心の命名が、どのような設計上の価値をもたらすかを検討します。

命名という小さな選択が、設計にどのような影響を与えるのか。
5分間で一緒に考えてみませんか？

みなさんSwift Package Managerで依存パッケージをブランチ指定している場合など、意図したバージョンが利用されずに困ったという経験はないでしょうか。

このような問題に直面した際、私たちはその根本原因が分からないまま、手探りでキャッシュを削除したり、Xcodeを再起動したりといった非効率な試行錯誤に多くの時間を費やしてしまいがちです。

特に、ライブラリのバージョンが古いまま残っているかどうかは、その挙動をしばらく観察しないと判明しないこともあり、問題解決までにかかる時間がさらに長引くケースも少なくありません。

本トークでは、Swift Package Managerのキャッシュの仕組みを深掘り、その適切な取り扱い方を理解することで「分からないから手当たり次第に試す」という状況から脱却できるようになることを目指します。

具体的には以下のようなトピックを取り扱います。

• Swift Package Managerがキャッシュしている項目について
• Package.swiftのManifest解釈プロセスについて
• 依存解決のされ方とキャッシュの適切な飛ばし方について

去年の私は、「@Environment(.keyPath)実践入門」というパンフレット記事を書きました。8ページにも及ぶボリュームでしたが、おかげさまで非常に好評をいただき、今年はその続編として、「@Environment(.keyPath)をフル活用したアーキテクチャ作り」のパンフレット記事を執筆する運びになりました。

しかし私の@Environment(.keyPath)への愛は、やはり文字だけでは伝えきれず、私が実際にどのように書いてきたか、この仕組みによってどんなメリットが得られるのか、そして思わぬ落とし穴！？まで、私がここ2年近く@Environment(.keyPath)と付き合ってきて得た全ての知見を、皆さんに共有したいと思います！

この発表は以下の内容を含める予定です：

• @Environment(.keyPath)とはどんなものか、一般的なDIや、@Environment(Object.self)とどう違うか
• @Environment（.keyPath)の基礎的な使い方
• カスタムな@Environment(.keyPath)の作り方
• @Environment(.keyPath)のちょっと高度な使い方
• @Environment(.keyPath)の特殊な値注入の仕方
• @Environment(.keyPath)の意外な落とし穴
• @Environment(.keyPath)をフル活用したアーキテクチャの作り方
  などなど！

この発表は、SwiftUIの初心者から上級者まで楽しんでいただける内容に仕上げる予定です。そしてこの発表を聞いて、一人でも@Environment(.keyPath)に興味を持ち、開発で今まで以上に活用してみてくれた方が増えたら、私にとってこれ以上に嬉しいことはないでしょう！

多くのユーザーはアプリを使用する際に「直感的に操作できること」を期待しています。１ユーザーとしてさまざまなアプリを触っていると、「こう思っていたのになんでこうなるんだ？」という違和感を覚えることがあると思います。
おそらくその違和感はアプリの設計の段階で、UI/UXの考慮が抜けてしまっていることが原因で生じているものだと考えられます。
もちろん、技術的な制約や実装上の理由から、理想的なUI/UXを実現するのが難しい場合もあります。
ですが、ユーザーは自分の期待通りにアプリが動作することを期待しています。想定と違うとユーザーは困惑してしまい、求めていた情報に辿りつかなかったり、嫌悪感を抱いて離脱してしまう、そんなことにつながってしまう可能性もあります。
たった一つのボタンの動きやアニメーションだけでせっかくのUIも台無しになる可能性さえあります。

こうした背景から、どのようなUI/UXの抜けがあってユーザーに違和感があるのか、それをどうしたら改善できるのかを考えたいと思いました。

このトークでは、どのようなUI/UXの欠落がユーザーに違和感を与えるのかを具体的に分析し、それをどのように改善できるのかを考察します。具体的には、以下のポイントを中心にお話しする予定です。

・失敗例（実例ではなくサンプルをお示しします）
・失敗をどのように改善できるかについての提案

つまりのところ言いたいこと：UIがいいだけじゃダメですか？→ダメです

Swift 6と共にComplete Concurrency Checkingが導入され、1年が経ちました。これまで曖昧にしておくことができたSwift Concurrencyも、きちんと理解して正しく適用する必要性が高まっています。

Swift Concurrencyの関連仕様は多岐にわたり、Swift EvolutionのProposalも膨大です。それらのすべてを正確に把握するのは非常に困難です。しかし、Swift Concurrencyのコアとなる考え方はシンプルです。それさえ押さえてしまえばSwift ConcurrencyとComplete Concurrency Checkingについての見通しがよくなり、その挙動を体系的に理解しやすくなります。

本トークでは、Swift Concurrencyの根幹を成すものとして、Isolation Domain・Isolation Boundary・Sendableとは何か、それらを利用してコンパイラがどのようにデータ競合を防ぐのか（Complete Concurrency Checking）を解説します。

その上で、Actorがどのような仕組みで動作するのか、ActorとIsolation Domainの関係、Global Actor（特にMainActor）およびTaskについて解説し、Swift Concurrencyについての理解を深めます。

さらに、その説明の延長線上として、WWDC25の様々なセッションでも取り上げられたSwift Concurrency関連の新機能SE-0461・SE-0466について解説し、Swift 6.2のSwift Concurrencyにおけるそれらの役割を示します。

最後に、iOSアプリでそれらをどのように組み合わせて活用するのか、一例を示します。

多くのプロジェクトでCIは、テストや静的解析を通じて品質を保証する重要な役割を果たしています。
一方で、CIの待ち時間はプルリクエストをマージするまでの時間に大きな影響を与えています。

「家族アルバム みてね」のiOSアプリでは、各プルリクエストでユニットテストと静的解析を実行していますが、その待ち時間が最大で約50分に達し、開発スピードを阻害する要因になっていました。
特にiOSに関わるメンバーが10人から20人へと倍増したことで、全メンバーがこの待ち時間の影響を受け、ボトルネックとなる場面が頻発していました。
コードレビューによる修正が多くなると影響を受けるのはもちろんのこと、hotfix等の緊急対応が必要な場面で特にもどかしさを感じていました。

これらの課題を解決するために、CIで2つの並列化手法を実践し、待ち時間を約20分まで短縮することに成功しました。

• CIのJobの並列化
  • マルチモジュール化によって得られた並列化の恩恵
  • CIとローカルでのTestPlanの使い分け
• ユニットテストの各テストケースの並列化
  • Swift Testingの活用とXCTestからの移行
  • 並列化で発生したFlaky Testの問題と解決

本セッションでは、導入までのステップ、導入時の課題、得られた効果について詳しくご紹介します。

生成AIの目覚ましい進化により、LLM（大規模言語モデル）を活用した開発が急激な勢いで発展しています。
モバイル領域の開発も例外ではなく、LLMを活用して開発を効率化していくことが求められてきているかと思います。

本セッションでは、LLM活用して iOS/Android 両OS アプリの効率的な開発手法についてお話いたします。
具体的には、以下を深堀ってお話しいたします。

• Cline, Cursor, Claude, Codex, Gemini など複数のAIコーディングアシスタントを活用したアプリ開発
• AI活用したモバイルアプリ開発を効率化するために、「iOS/Android モノレポ化戦略」について
• モノレポ化によって、得ることができた Mobile 開発の効率化
  • iOS ↔ Android 相互にコード変換
  • AIコーディングアシスタントを用いた iOS/Android 同時並列開発について
• 今後、想定しているAI活用戦略

先日 担当しているアプリの譲渡をしたのですよ。

で、よくあるアプリ譲渡の手順で、事前準備もしっかりとして、つつがなく 譲渡が完了！
….と、思っていたのですが、「あれ、このAPIを使うには、Appleに許可がいるの？」という思わぬ事態に遭遇！

具体的には、PassKit の requestAutomaticPassPresentationSuppression(responseHandler:) を使っているのですが、これは特別なEntitlementをAppleに申請しないと利用できないAPIだったので、譲渡後に改めて申請をしました。

この経験をきっかけに、Appleに申請・許可が必要なAPI について調べてみたところ、他にも「申請必須API」があることが分かりました。

このライトニングなトークでは、Appleにメールを送信してから、APIが利用できるようになるまでのプロセスと、その他の許可が必要なAPIについてお話しします。

いざ許可が必要なAPIを利用する際に焦りたくない方におすすめです。

Kotlin Multiplatform（KMP）を使うことでかんたんにクロスプラットフォーム開発をすることができます。
最近ではAndroid開発でよく使われている便利なライブラリもKMPに対応し、より一層KMPの開発体験が向上しています。
例えば、ローカルでデータを永続化するためのライブラリ「Room」もKMPに対応しました。

Roomを使って開発をする場合はすべてのコードを共通化できるのではなく、プラットフォームによって実装が違う箇所があり、その場合はactual / expect 修飾子を使って実装します。
プラットフォーム別に動くコードは簡単に書くことができたのですが、テストコードを書こうとすると詰まる箇所があり苦労しました。

本セッションでは、Roomを使って開発する際にプラットフォーム別にactual / expectをどのように実装していくかと、そのコードに対してのテストの実装方法について、具体的なコード例を交えながら紹介します。

私が所属する大学の研究室では, 音声解析の結果や録音した音声からグラフを作成する機会が多くあります. しかし, 研究室全体で利用している既存の音声編集ソフトウェアのグラフ表示機能には, 「複数の音響データを同一のグラフに重ねて表示できない」, 「データ間の詳細な差分を比較できない」などといった問題があり指導教員がこの点に不満を抱いていました.

そこで普段からiOSアプリの開発をしている私は, AVFoundationで音声ファイルを読み込み, 音声信号が時間とともにどのような周波数成分を持っているかをAccelerate FrameworkのAPIを用いて高速フーリエ変換 (FFT: Fast Fourier Transform)を行うことで解析し, その結果をSwift Chartsを用いてスペクトログラムを描画するようなシンプルなアプリケーションを作成しました.

このアプリを使用することで, 複数の音声ファイルの音声スペクトルを重ね合わせて表示したり, 差分を表示したりすることが可能になり, より直感的な音声特性の分析を実現しました. これにより音響データの比較検討が効率化されたとともに, ゼミの発表資料などで成果の視覚的な説明ができるようになりました.

このトークでは

• AVFoundation, Accelerateを用いた音声ファイルに対しての高速フーリエ変換とスペクトルの解析
• Swift Chartsによるスペクトログラムのカスタマイズや描画
• ドラッグアンドドロップによる音声ファイルの選択とスペクトログラムのクリップボードへの保存

について, 高速フーリエ変換の基礎や作成したアプリケーションの実装に触れつつお話します.

macOS では InputMethodKit を活用することで、自作の日本語入力システムを開発できます。本トークでは、日本語入力機能を備えた Input Method の構築を目標に、
・InputMethodKit の基礎と使い方
・開発をスムーズに進めるコツ
・日本語入力機能を実装する際に役立つライブラリの紹介
を順に解説します。これをお聞きいただければ、誰でもデスクトップ向け日本語入力システムを DIY できるはずです。

私は iOS 向けに開発した日本語入力キーボードアプリ 「azooKey」 を macOS へ移植し、過去 1 年にわたり開発・運用を続けてきました。
GPUを用いた強力な変換機能を作ったり、端末外のAPIにアクセスすることによってLLMなどを活用することも、機能的制限の緩いmacOS環境なら容易に実現可能です。
本トークではこうした自作Input Methodの魅力を紹介します。

一方、macOS特有の制約も様々に存在します。変換候補ウィンドウの表示、容易にいかないデバッグなど、さまざまな難しさがあります。こうした地雷を避けつつ使い勝手の良いInput Methodを開発するための知見も紹介します。

※2023年のiOSDCではiOS向けのキーボードアプリの開発についても話しました。こちらもぜひご覧ください。
https://fortee.jp/iosdc-japan-2023/proposal/87be3428-5381-4aa3-8127-cfd714663429

「目的地に行ったらスマホ制限解除」というアプリを作っていた時の話です。

開発は順調でした。近所のジムで何度テストしても完璧に動作。「位置判定範囲200mで実装完了！」そう思っていました。

ところが、友人からの一通のメッセージで事態は急変します。
「代々木公園の中にいるのに判定されない！バグってない？」

まさか、そんなはずは...。慌てて現地に向かい検証すると、確かに公園内部で全く反応しません。一方で、同じコードを使ったジムでは相変わらず正常動作。

いったい何が違うのか？
・GPS精度の問題？→同じ精度設定
・デバイスの問題？→同じiPhone
・通信環境？→どちらも良好
・コードの問題？→全く同じ実装

同じ位置判定機能なのに、なぜ場所によって動いたり動かなかったりするのか？

調査を進めるうち、ある重要な事実に気づきました。そして最終的に辿り着いた解決策は、なんとAIに「ある質問」を投げかけることでした。

この奇妙な現象の正体とは？
そして「ある質問」とは一体何だったのか？

同じような位置判定機能を実装している方、実は知らずに同じ罠にハマっているかもしれません。実際コードとデバッグの軌跡をお見せしながら、この謎解きの全貌をお話しします！

音声でアプリの入力が完結したらとても便利だと思いませんか？

音声入力の代表格である Siri は2011年に iPhone に登場して以来年々進化を遂げ、「声で操作する」という動作は当たり前のものになりました。
音声入力をアプリに組み込む方法としては Speech framework があり、日本語もサポートされており、音声をそのままテキストに変換ができます。
しかしアプリの入力は、テキストだけではありません。
トグルやピッカーなど、テキスト以外のアプリ入力としては Speech framework 柔軟性に欠けていました。

ところが、WWDC25 で発表されたオンデバイスLLM Foundation Modelsを使うと状況が一変します。
@Generableマクロを使うことでプロンプトから任意のSwift型のデータを出力できるようになったのです。
つまり Speech frameworkで音声入力をしてテキストに変換し、Foundation Modelsのプロンプトとして渡せば、アプリの入力を音声で完結できるようになりました。

このトークではSpeech frameworkとFoundation Modelsでアプリの入力を簡便にする方法を発表します。
Todoアプリを例に実装例やオンデバイスLLMでの効果的な利用方法をお話します。

「目次」
・Foundation Modelsとは？対応機種や制限は？
・Speech frameworkと組み合わせる実装例
・効率の良いプロンプト作成方法
・実際のユーザーの評価とフィードバック

あなたのアプリもキーボード中心の UX を“声だけの入力”へアップグレードしてみませんか？

皆さんのアプリでは、分析ログを正確かつ漏れなく収集できていますか？
私たちのサービスでも多くのログを送信していますが、かつては実装漏れやデグレによる送り漏れが頻発し、効果測定ができず仮説検証に大きな支障が出ていました。
とはいえ、少人数チームかつiOS・Androidの両対応、さらに限られた予算の中で、導入できる手段には制約がありました。

そこで私たちは、「ログ送信箇所にテストコードを追加する」方針をとることにしました。
この実践により、徐々に実装漏れがなくなり、デグレによるログ欠損も減少しました。

テストコードといえば通常はビジネスロジックに対して書くものという認識があるかもしれません。
「なぜそこにテストを？」と思われるかもしれませんが、設計を工夫すればログ送信にも十分活用でき、ビジネス上の価値も高いと感じています。

本トークでは、ログ送信に対してテストを書くことの効果や実例、そして設計上の工夫についてご紹介します。
ログ品質の担保に課題を感じている方に、実践的なヒントをお届けいたします。

iOS/iPadOSアプリを作る上で、開発者としての基本姿勢はAppleの標準APIを使ってUIを実現することです。
Appleが用意した高レイヤーのAPIを使うことで、簡単にリッチなUIを実現できます。

しかし、そういったAPIは高レイヤーがゆえに、時には小回りがきかないことも事実です。
そのような場合に、UIViewからフルスクラッチでカスタムUIを作ることが選択肢になります。
Appleが提供するAPIにはない表現を実現することができ、みなさんのアプリの世界観にピッタリなカスタムUIを提供できます。

ただ、カスタムUIを実際に作るとなると、標準APIがカバーしてくれていた多くのことを自前でカバーする必要が出てきますが、そのコストは過小評価されがちです。
アニメーション、ジェスチャー、インタラクション、パフォーマンス、入力デバイス、アクセシビリティ...
開発者はこれら全てに対して、Appleが用意した標準のUIと並んでも違和感がないレベルまで実装し、メンテナンスし続ける「覚悟」が求められます。

このトークでは実際に自分が作ったカスタムUI、作らなかったカスタムUIを題材に、以下の流れで話をします。

• どういう場合にカスタムUIを作るべきか、作らないべきか
• カスタムUIを実装する時、どのような点に注意すればいいのか
• 実装されたカスタムUIに対して何を確認したらいいのか
• カスタムUIを導入する際の覚悟

このトークを通じて、みなさんがiOS/iPadOSアプリ開発者として、適切にカスタムUIと向き合えることを目指します。

みなさんの開発チームにiOSエンジニアは何人在籍していますか？
中には少数のエンジニアで開発・運用しているケースもあるかと思います。

少人数体制では、チームにかかるリリース作業の負荷が大きくなりやすく、どうしてもリリース間隔が空いてしまい、頻度が低下しがちです。
しかしリリース頻度の減少は、ユーザーからのフィードバックを得る機会 = 仮説検証を通じたサービスの成長・改善機会の減少にもつながるため、可能な限り避けたいものです。

私が開発・運営に携わっているグルメサービス「Retty」のアプリチームは、iOSエンジニア2名を含む全3名という小規模チームながら原則「毎週リリース」を実現し、直近1年間のiOSアプリのリリース回数はのべ50回に達しました。

この継続的かつ高頻度なリリースによって、仮説検証や機能の軌道修正を機動的に行うことができ、ビジネス視点でも大きなメリットを得られていると実感しています。
もちろん、これは気合で成し遂げているわけではなく、開発メンバーの負荷を最小限に抑えながら「楽々」達成できるよう、さまざまな工夫とテクニックを活用しています。

本トークでは、毎週リリース実現のため、我々が実践してきた開発・運用手法や工夫についてわかりやすくご紹介します。
また高頻度リリースを実践するうえでの注意点や、直面した課題・失敗事例についてもお話しいたします。

「たくさんリリースして、たくさん学んで、たくさん成長する」
そんなアプリ開発・運用を目指す方にとって、きっと参考になる内容です。ぜひ本発表をご覧ください。

トーク内容

• 毎週リリースのメリット
• Retty iOSアプリでのリリース実績
• ブランチ・リリース戦略
• アプリ・API設計の工夫
• 自動化・CI/CDの活用
• リリースフローの最適化
• 毎週リリースでの注意点・失敗事例

iOSアプリ開発において、状態監視の実装方法は時代と共に多様化しています。従来のDelegateやKVOから、単純なクロージャ、Combine、AsyncSequence、そしてSwiftUIのObservationに至るまで、現在では開発者には数多くの選択肢が与えられています。

しかし、きちんと仕組みを理解せず「最新技術だから」「手軽に書けそうだから」といった理由で技術選定を行うと、思わぬ罠を踏み、結果としてプロジェクトに不適切な実装を生むことにもなりかねません。加えて、既存の手法を用いる場合でも、Swift Concurrencyへの対応という現代的な課題は避けて通れません。

本発表では、各状態監視手法の特徴や長所・短所を整理し、どのような場面でどの技術を選択すべきか、その実践的な指針を提案します。皆さんが日々の開発で自信を持って技術選定できるよう、その一助となれば幸いです。

ユーザーが投稿した写真を公開情報として提供するサービスでは、映り込みによるプライバシーの問題への対処が必要となることがあります。
私が開発運営に携わるグルメサービスRettyでも、店の雰囲気を伝える手段として飲食店の店内で撮影された写真を収集していますが、店員や他のお客さんが映った写真が投稿されてしまうことが大きな課題でした。
写真を適切に加工することでこの問題は回避可能ですが、外部アプリでの加工はアプリ間の移動が煩雑であり、さらに手動で人の顔に加工を施す作業負荷も高いため、これが店内写真の投稿率を下げる要因となっていました。

そこでRettyでは、アプリ内で加工が完結できるよう新たに「顔ぼかし」機能の提供を開始しました。
これは被写体を判別し、顔の部分だけにぼかしを入れる機能で、本機能によってユーザーは気兼ねなく内観写真を投稿することができるようになりました。
本機能の実装にはVisionFrameworkを用いており、オンデバイス判定による高速かつ高精度な顔判別と加工を行っています。
Apple標準のAPIのみを使用しているため、専門知識も不要でシンプルながらも必要十分な設計で実現することができました。

本トークではRettyでの「顔ぼかし」の企画からリリースに至るまでの流れをお話しながら、技術選定、設計、対処した課題についてご紹介します。
VisionFrameworkの活用事例として、みなさんのサービス開発にも役立てていただける内容となっています。

トーク内容

• Rettyの写真投稿と内観写真における課題
• VisionFrameworkについて
• ぼかし機能の設計と仕様
• リリースまでに発生した課題と対策
• 企画からリリースまでの総括