トーク

Pythonで学習したMLモデルをオンデバイスで動かすには、Core ML形式への変換が不可欠です。

Pythonライブラリ coremltools は、TensorFlowやPyTorchなどのフレームワークから.mlmodelや.mlpackageへの変換を Converter で行い、さらに量子化、パレット化、プルーニングなどの圧縮機能を備え、モデルサイズや推論速度を改善してくれます。

本記事では、coremltoolsを使ってオンデバイス用のMLモデルを作成＆実行する過程を、以下の観点で実例を交えながらご紹介します。

• coremltools を用いた変換
• パレット化（LUT化）や量子化、プルーニングによるモデル圧縮手法とその効果
• .mlmodel・.mlpackage の読み書き、柔軟な入力形態設定、Xcodeでの検証活用など開発効率を高めるユーティリティ紹介

これらを通じて以下の知見を皆さんへお届けします。

• モデル圧縮によるファイルサイズの削減・推論高速化・電力効率の向上が即実感できる
• Neural EngineやGPU活用のパフォーマンス利点を具体的に理解できる

コードレビューは、チーム開発における品質担保と知見共有のために不可欠なプロセスです。しかし、「何を指摘すべきかわからない」「観点が人によってバラバラ」「レビューに時間がかかりすぎる」といった悩みは、多くのチームが抱える共通の課題ではないでしょうか。

本セッションでは、iOS開発の現場で実際に起きやすいコードレビューのつまずきやすいポイントを整理し、具体的なコードをもとに「どのような観点でコードを見ればよいのか」を実践的に学びます。たとえば、ViewとModelの関心の分離、命名、非同期処理での注意点、コードスタイルの一貫性、パフォーマンスやセキュリティに関する観点などの多角的な視点を紹介します。

また、「良いレビューコメントとは？」「手戻りを防ぐにはどうすればいいか？」といった、設計やコミュニケーションにも関わる問題についても触れ、レビューの“質”を高めるためのノウハウを提供します。

さらに後半では、効率的なレビューを支援する手段として、AIを活用したコードレビューの手法についても紹介します。GitHub CopilotなどのAIレビュー支援ツールを用いることで、開発者はより本質的な設計や意図の確認に集中する「人とAIの協調によるレビュー」の可能性についても紹介します。

このセッションを通じて、コードレビューの観点を整理し、チーム全体でレビューの質と効率を高めるための実践的なアプローチを学べます。このセッションが、明日からのコードレビューを飛躍させるヒントになるはずです。

セッション内容（予定）

• なぜコードレビューはうまくいかないのか
• コードレビューの7つの観点
• コードレビューでのコミュニケーション
• コードレビュー実践ワークショップ
• 技術育成のためのコードレビュー
• チームで更なる生産性を高める
• 生成AIを用いたコードレビューの最適化

Actor境界はSwift concurrencyにおいてデータ競合を防ぐための強力な概念ですが、実際のアプリ開発においてはこれが障壁となることがあります。Actor境界を跨ぐデータの受渡は通常非同期で行われますが、これを同期的に行わなければならないことがあります。例えばレガシーなスレッドベースのAPIを使う場合、引数として渡すコードブロックにおいて、そのActor context外のデータに同期的にアクセスすることが必要になることがあります。

このトークでは、AVFoundationを用いてサウンドを再生する例を題材にして、こうしたケースにおいてもActor境界を安全かつ同期的に跨ぐ方法について説明します。Custom actor executorや、OSAllocatedUnfairLockやMutexといったロックAPIを用いることで、unsafeキーワードを用いることなくActor境界外のプロパティにアクセスし、Swift 6でコンパイル可能な実装方法を紹介します。
Swift concurrencyとともに、どんなAPIも安全かつ効果的に利用できるようになりましょう。

モロッコの伝統衣装の美しさと多様性を、日本語でも気軽に体験できるアプリがあったら？
このLTでは、モロッコ文化とモダンなアプリ設計を融合したSwiftUIアプリの構想「KiyanKa」をご紹介します。
MVPでは、ユーザーが写真をアップロードすると、その色や模様からインスピレーションを得たドレスが提案される仕組みをAIで実現。文化的な発見を促す形です。
SwiftUIを使って多言語対応（日本語・アラビア語・フランス語）を実装しながら、AIを活用した小さな工夫で、文化的価値のあるアプリ体験を模索しています。
This talk is an invitation to think about apps not just as tools, but as bridges between cultures.

このセッションでは、継続的デリバリーの理想と現実の狭間で、マンガアプリのリリースプロセスに刻まれた
「シュプール」(雪面に残る軌跡) のような、私たちの改善の歩みを実例とともにお伝えします

• Branch Policy
  • Git Flow から Trunk Based Development への移行の過程とそのメリット
  • Code Review と CI の連携を最適化するために実施した取り組み
  • Feature Flag の管理と運用方法の改善
• Versioning Strategy
  • 優先度変更による Version の混乱を乗り越え、わかりやすく迷わない、Calendar Versioning を採用した経緯
  • Release Note 作成の自動化と情報共有の方法
  • Slackbot を活用した差分出力の簡素化
• Release Cycle
  • Release Train を用いた安定的で計画的なリリース
  • 属人化を避けるためのリリースフローとその実施例
  • 予期せぬ事態でも慌てない Hotfix 対応の実践

個人開発アプリでの具体的な経験に基づき、高評価レビューを増やしつつ低評価レビューを効果的に回避するための実践的なApp Storeレビュー戦略について解説します。
潤沢な広告費を持たない個人開発者にとって、App Store Optimization (ASO) はアプリ成長の生命線であり、中でもユーザーレビューはApp Storeにおける検索順位やダウンロード数に絶大な影響を与えます。

本セッションでは、リリース後7ヶ月で10件程度だったレビューを、わずか4ヶ月で170件に増加させ、さらに平均評価を4.5から4.7へ上昇させた成功事例を元に、その秘訣を余すことなく共有します。

具体的には、適切なレビュー訴求のタイミング、ユーザーの感情に応じた分岐、そしてフォームを活用したフィードバック収集と迅速な対応フローを通じて、App Storeの低評価を回避し、平均評価を向上させる方法をデモを交えてご紹介します。

これは、App Storeでの検索順位上昇にも寄与し、自然流入を強化することで、長く愛されるアプリを作るための重要な戦略となります。

本セッションでは「あすけんiOSアプリ」における実践事例をもとに、テスト戦略をどう立て、どう現場に根づかせたのかを紹介します。
当社では、テスト運用が属人化していたり、テストが不足していたり、テスト書くこと自体が目的になってしまっていました。
ただ、ユニットテスト、UIテスト、E2E、さらにはスクリーンショットテストとCI/CDの連携など、全部網羅的にやることは現実的ではないです。
そのため、今の自分たちにとって、本当に必要なテストだけを選び取り、属人化を減らしてチーム全体で理解・運用しやすいテスト戦略を目指しました。
昨今の生成AIとの協働も考慮しつつ、テストの設計や現場で工夫したことなど、運用を見直すヒントを提供します。
例えば、AIを活用して、ユニットテストのコードを生成する取り組みなどをやりました。

ただし、試行錯誤は続いているのでうまくいっていない部分も語っていきたいと思います。 「テストはあるけど、なんとなく不安」「CIが形骸化している」「リリースのたびにUI崩れが怖い」
そんな現場にとって、戦略的にテストを設計・運用する事例や考え方を提供する内容になっています。

アジェンダ

1. 背景と課題
2. テスト戦略の再設計
3. テスト運用方法や手法
   • テスト設計
   • スクリーンショットテスト
   • CI/CDなど
4. 生成AIとの協働
   • テスト設計・運用におけるAIの活用例
5. 継続的な試行錯誤と課題

皆さんはIn-App Purchases(以下IAP)を提供するサービスに関わっていますでしょうか？
IAPによってサービスは継続的に収益を得ることができ、StoreKit 2によって以前よりも簡単に実装が可能です。

IAPを公開するためにはapp、メタデータなどを用意し審査に出す必要がありますが、色々と注意点・問題点が存在します。
・配信国が1つも設定されていないとrejectされます。
・IAPは審査通過した後自動で公開されるため、配信日時をコントロールすることが不可能です。公開日より前に審査だけ通したくても意図せずApp Storeに提供予定の機能が公開されることになります。

・公開されたIAPは配信国を0にすることでApp Storeより削除できますが、Account Holderしか配信国を削除することができず、権限を持つ人の状況次第で対応が遅れる懸念があります。
など…

では、これらの事象に対して我々は何ができるのでしょうか。

このLTではIAPを申請するために必要なこと・注意点を共有します。
またWWDC25の現地labでこれらの課題に対して質問してきた内容を実際に用いた資料も併せて共有します。

果たして解決策は得られたのか？皆さんに多くの最新情報を共有できたら幸いです。

ゴール:

・IAPの申請に準備が必要な情報や申請作業内容がわかる
・申請時に起こりうる問題とそのワークアラウンドを得られる

・本件についてのlabの回答内容を共有できている

アジェンダ:
・IAP申請に必要な準備
・申請後、実際に起こった問題・ワークアラウンドの紹介
・WWDCのlabで聞いてみた&回答について

対象者：

・IAPをリリース予定のエンジニア・非エンジニア
・IAPについてあまり詳しくないが興味がある方

・labの様子や回答内容が知りたい方

iOSアプリのUI構築において、SwiftUIは宣言的な記法と豊富な拡張性により注目を集め、今や多くのプロダクトで採用されています。こうしたSwiftの思想は、今やWeb開発の領域にも波及しています。その一例が、Swift製の静的サイトジェネレータ「Ignite」です。

本稿では、Igniteが提供する3つの中核的なAPIグループ「InlineElement」「HTML」「Modifier」に注目し、どのようにしてSwiftらしいWebページ構築を実現しているかを解説します。

• InlineElement はテキストや画像など、HTMLタグに相当する単一要素を抽象化したプロトコル
• HTML は複数の要素を組み合わせた再利用可能なコンポーネントを表現するための仕組みであり、ユーザー定義コンポーネントの構築にも使われる
• Modifier は色や文字サイズなどの装飾を宣言的に追加するためのAPI群で、SwiftUIと同様、要素に対してチェーン的に適用することが可能

これら3つの設計は、HTMLそのものをSwiftで模倣することが目的ではなく、「型安全なDSLとして、Webを構築する」という明確な思想に基づいています。慣れ親しんだSwiftの型と文法で「ウェブサイトを創る」という体験。SwiftならではのWeb開発のあり方を、Igniteを通して紐解いていきます。

いつでもどこでもキャンプができたらいいな。そう思ったことはありませんか？
visionOSアプリで、現実では難しい「理想のキャンプ体験」を仮想空間で実現することができます。

本LTでは、Reality Composer Proを用いてvisionOSアプリに「春夏秋冬」の季節感を演出するパーティクルを作成・実装する方法をご紹介します。
春には桜の花びら、夏にはホタルの舞、秋には紅葉の舞い散り、冬にはしんしんと降る雪。それぞれ異なる自然の動きを再現するために、表現や動きの調整に多くの工夫が必要でした。そんな自然の表現が、visionOSでどのように再現できるのかをハッカソンのチームで開発したキャンプアプリの実例を交えて話します。

LTで話すこと：

• Reality Composer Proとは
• 春夏秋冬の異なるパーティクルの作成方法
• visionOSアプリでのパーティクルの活用実例

筆者はIT企業でiOSアプリ開発をする傍ら、国立弓削商船高等専門学校（以下、弓削商船高専）の情報工学科教員としてプロダクトやシステム開発に関する講義を行なっています。

弓削商船高専のような国立高専では卒業生が身につけるべき知識や能力の到達目標として「モデルコアカリキュラム（以下、MCC）」が定められています。
特に情報系分野では、プログラミング/アルゴリズム/コンピュータの仕組みといった知識・技能に加え、それらを統合して課題解決にあたる「創造性・デザイン能力」の育成が重要視されています。

筆者はSwiftとAppleエコシステムは現代の「ものづくり」のプロセスと非常に親和性が高く、以下のような理由からMCCが目指す能力を育む上で多くの利点を持つと考えています。

• 学生が日常的に使うiPhoneやiPadで動作するアプリケーション開発は、学習への強い動機付けとなる
• SwiftUIとXcodeのプレビュー機能はコードの変更が即座にUIに反映されるため、手を動かしながら試行錯誤することを多く体験できる
  • MCCで求められている「エンジニアリングデザイン能力」 の育成に適している

本セッションではこのMCCの理念である「ものづくり」を通じた社会実装教育を、SwiftとAppleエコシステムを使って実現するためのアプローチを考察します。

• 直感的なSwiftによるプログラミング基礎教育
• SwiftUIのパフォーマンス改善といった実践的課題から学ぶアルゴリズムとデータ構造
• LLVMを基盤とするSwiftの特性を活かしたコンパイラへの理解

本セッションを通して高専教育のカリキュラムや授業構成に関する問題点や新たな可能性を見つけ、未来のiOSアプリエンジニアを育てるためのより実践的なカリキュラムや授業の作成に繋げたいと思います。

「バイブコーディングでAIにコードを書かせたけど、本当に動くの？」そんな不安を解消する、AI駆動の自動開発・自動検証システムを構築しました。本セッションでは、Claude CodeなどのAIコーディングアシスタントが生成したモバイルアプリのコードを、AIが自動的に動作確認する仕組みを紹介します。

具体的には以下のような内容をカバーします：

• AIによるコード生成後の自動動作確認フローの構築
• 生成されたUIコンポーネントの自動スクリーンショット検証
• AIが書いたコードに対する自動E2Eテストの生成と実行
• 問題検出時のAIへのフィードバックループの実装

「AIがコードを書き、AIが検証し、AIが修正する」完全自律型の開発サイクルはどこまで実現可能なのか？実際の開発事例とデモを通じて、AIによる自動コーディングの品質保証という新たな課題への挑戦をお見せします。

「このfullNameプロパティ、安心して呼んで大丈夫かな...？」
Swiftでコードを書く中で、Computed Propertyと関数の境界線に、ふと迷った経験はないでしょうか？
そして、その些細な迷いが、時として「期待とのギャップ」を生み、コードのパフォーマンスや可読性に影響を与えることがあります。

このトークでは、「なんとなく」で使い分けられがちなこの問題について、改めて基本から見つめ直します。

「フルネームの取得はComputed Propertyと 関数のどちらを使うべき？」という身近な疑問から出発し、なぜそれがパフォーマンス問題に関わるのか、そしてAppleはどのような設計思想を持っているのかを、実際のプロジェクトでよくあるケーススタディを通して、Computed PropertyとMethodの選択基準を皆さんと共有できればと思います。
このセッションが、皆さんの日々のコーディングにおける迷いを少しでも減らし、ご自身の意図をより明確にコードへ反映させるための一助となれば幸いです。

生成AIの進化により、Stable Diffusionをはじめとする画像生成技術が急速に注目を集めています。その流れを受けて、iOSアプリでも画像生成・加工の技術を取り入れたいというニーズが高まりつつあります。
iOSアプリで画像処理を実装しようとした場合、Core Image、Metal、CoreML、サーバサイド処理、さらには生成AI関連のAPIなど、選べる技術は多岐にわたります。

便利な選択肢が増える一方で、「結局どれを使えばいいのか分からない」「画像処理は難しそう」と感じて手が止まってしまう方も多いのではないでしょうか。

本トークでは、画像処理技術を利用してiOSアプリで独自の画像アニメーションを構築した経験をもとに、各技術の特徴と使いどころを整理します。
トークでは、独自アニメーションを実装するための要件を起点に、各要素技術（Core Image / Metal / CoreML / サーバサイド処理 / 生成AI関連のAPI）を使いながらアニメーションを構築していく過程を、実践的な形式で紹介します。
単に技術を羅列するのではなく、アニメーションの実際の動作を見せながら、「どのような場面でその技術を選ぶべきか」といった選定の観点を中心に、各要素技術を比較・検討していきます。

画像処理に興味はあるけど、何から手をつければいいか分からない。そんな方に向けて、iOSで使える技術やアプローチを実例とともに紹介します。
実は私自身も画像処理の専門家ではありません。でも、様々な技術を試す中で「意外と面白い」「ポイントさえ押さえれば自分でも作れる」と感じました。
本トークを通じて、画像処理は「難しそう」ではなく「ちょっとやってみたい」と思えるような、そんなきっかけを届けられたら嬉しいです。

クラシルリワードでは、レシートの撮影・送信機能を提供しており、レシートを送信してもらうことでユーザーに還元を行っています。この機能では、Vision Framework を利用した領域やテキストの検出を行なっており、サーバーでのレシートの解析に大きく貢献しています。しかし、これらの処理を加えたことにより、撮影ごとにかかる時間が増加してしまうことになります。ユーザー体験を考慮して、撮影から送信までパフォーマンス改善を行っていたところ初回の実行だけ異常に時間がかかっていることがわかりました。このトークでは、この課題に対する対応策となぜこのようなことが起こっていたのかの考察をご紹介します。このトークを通じて、同様の課題に直面している開発者の皆様がスムーズに問題を解決するための手がかりを得られることを期待しています。

このセッションでは、ビルド高速化のノウハウをまだ持っていないAppleプラットフォーム開発者向けに、具体的にどのようにビルド速度を改善できるのかを解説します。

アプリ開発中は、実装やCI/CD等で沢山ビルドすると思います。
ビルドの時間が遅いと、単純に開発者にとってストレスになるだけでなく、開発のテンポが悪くなり実装内容に見合わない大きなコストがかかることになります。
WWDCのセッションビデオや公式ドキュメントより、Xcodeのビルドシステムの仕組みを見てみると、ソースコードの量やマシンスペック以外にも様々な原因でビルド速度のボトルネックになる要因があることがわかりました。
皆さんの関わっている、プロジェクトのビルド設定やソースコード自体がビルド速度のボトルネックになっていることが、あるかもしれません。

本トークでは数あるビルド時間が伸びてしまう原因のうち、解消したときに短縮できるビルド時間が大きいと思われるものを3つに厳選して、重要なチェックポイントと修正方法をそれぞれ解説します。
具体的には、次の内容に関連した原因についてお話しします。

• 並列ビルドの最適化ができていない
• 依存ライブラリのコンパイル時間が長い
• コンパイル時の型推論時間が長い

例えば、Xcodeでは並列に複数のビルドタスクを進めることができますが、プロジェクトの依存関係によっては並列で処理できない部分が発生することがあります。
このような問題をどのようにして発見し、どうやって改善するのかそれぞれ詳しく説明します。
サンプルコードや、実際のプロジェクトで取得したビルド時間のベンチマークを比較して、実際どれぐらい早くなるのか、も見ていきます。

業務、プライベート問わず、普段の開発でビルド時間に悩まされている開発者にとって、是非聴いていただきたい内容です！

WWDC25に現地参加して驚いたのは、非常に多くの人が「Ray-Ban Metaグラス」をごく自然に日常使いしていたことです。まるでスマートウォッチのように、屋内外を問わず装着されており、現地では“次は眼鏡型が来るのでは？”という空気感も強く感じられました。


WWDC後には、MetaとOakleyのコラボによる「Meta HSTN」が正式に発表され、さらに「次はPradaと組むのでは」といった噂も流れています。これらの動きは、WWDC現地での肌感を裏付けるものだと感じました。一方で、これらの製品は日本国内では正規販売されておらず、日本の開発者にとってはまだ“遠い存在”にも見えるかもしれません。

しかし実際には、XREALシリーズをはじめ、日本国内でも購入可能な眼鏡型デバイスは着実に増えており、家電量販店でも普通に見かけるようになっています。これらの製品は、ディスプレイの有無や投影方式（空中映像型、視野投影型など）によっていくつかに分類でき、それぞれ用途や体験にも違いがあります。

本稿では、そうした眼鏡型デバイスの系譜と技術的な分類を整理したうえで、「今、何が使えるのか」「どこまで来ているのか」、そして「この先どこへ向かいそうか」について紹介・考察します。Vision Proのような“没入型”とは異なる方向にある“軽量で日常的な空間コンピューティング”の可能性に、いま改めて注目してみませんか？

アプリ開発において、UIの品質担保は誰しもが一度はぶつかる課題だと思います。
解決策として、E2Eテストやスナップショットテスト、実機テストが挙げられます。
その中でも、swift-snapshot-testingを使ったビジュアルリグレッションテスト(以降VRTと呼ぶ)に焦点を当てていきます。
※VRTとは、変更前と変更後のコードで対象画面のスナップショットを比較することで、UIのデグレを検知するテストです。

「UIテストは運用コストが高い」と、諦めた経験のある人はいませんか？
導入初期は運用できていたものの、少しずつ放置されていき、運用されなくなってしまった経験はありませんか？

本トークでは、そんな運用コストの課題を
CursorやClaude Code Github Actionsを使って解決した方法をお話しします。
また、以下のテーマに触れながら進めていくので、検証から運用まで具体的にイメージすることが出来ます。

• 技術選定の内容と理由
• ChatGPTが提案するコードのセキュリティの問題
• CIの実行時間の課題
• カバレッジ計測の自動化
• テスタブルなUI設計
• Cursor, Claude Code Github Actionsの活用方法

導入後の現在も、品質や設計・自動化面で改善を続けており、
それらを余すことなくお伝えできればと思います。

「VRT導入時、どのようなことを考慮したら良いかよくわからない」
「VRTの導入を検討しているが、実際にチームで運用し続けられるか悩んでいる」
「運用が止まってしまっている」
そんな方々に参考になるセッションとなれば幸いです。

開発者にとって、使いやすいSDKドキュメントはプロジェクトの成功に不可欠です。にもかかわらず、ドキュメントの整備や運用には多くのハードルがあり、「後回しになりがち」「仕様と乖離しやすい」「更新が面倒」といった課題を抱える現場も多いのではないでしょうか。

本セッションでは、Xcode に標準搭載されている DocC と GitHub Pages を活用し、開発コストを抑えつつ、ユーザーにとって“使える”ドキュメントを自動生成・公開する方法を、実例とともに丁寧に解説します。

以下のような構成で、ドキュメント構築の一連の流れを紹介します：

• /// コメントから始める DocC ドキュメンテーションの基本
• xcodebuild docbuild による .doccarchive 生成とその仕組み
• xcrun docc process-archive transform-for-static-hosting を使った静的ホスティング対応
• GitHub Actions を用いた CI/CD 自動化による公開フローの構築
• Parameters・Returns・Note・Important などを活かしたリッチな Markdown 記法
• ユーザー視点で見やすく、保守しやすい構造設計のポイント

これらは、実際に私たちが開発・提供している SDK に DocC を導入し、社内外に向けたドキュメント公開を運用した経験に基づいています。導入時にハマった落とし穴や、記述の最適化ポイントもあわせて共有します。

自社SDKやライブラリをより使いやすく、メンテナンスしやすいものにしたい開発者に向けた、実践的なDocC活用術です。

本トークでは、iOS SDK を Swift Package Manager（SPM）+ XCFramework によって構成・配布する設計と、その実運用で得た知見を紹介します。

実際に筆者が提供する SDKを題材に、次の観点から掘り下げます：

• 複数モジュール構成（Core / App / Tracking など）の分離と依存関係の整理
• ライブラリの再利用性を高めるためのディレクトリ構成と Swift Package の切り方
• XCFramework による iOS / Simulator 対応
• BuildTools モジュールを使った SwiftLint / SwiftFormat の一括適用
• 内部で持つUIライブラリにおけるアセット管理のはまりどころ
• 「使う側」にとって安全・簡単に導入できる Package の設計原則

「SDK を作る」こと自体が目的ではなく、「チームで再利用できて、組織として持続可能な仕組みを作る」ことがテーマです。

ライブラリ開発初心者はもちろん、「現場で自作 SDK のメンテ地獄に陥ったことがある人」や「SPM の限界を見極めたい人」にとって、ヒント満載の内容となっています。