トーク

マップを活用したiOSアプリは、建物や道路といった屋外の情報を扱うことが多いですが、建物にズームしたときに、その建物内のフロアマップが表示されるような機能を兼ね備えたアプリも存在します。

みなさんは、ショッピングセンターや空港といった施設内の位置情報を定義できるフォーマットをご存知でしょうか？Appleは、Indoor Mapping Data Format (IMDF) というフォーマットを提唱しています。これを使うと、フロア内の部屋の領域だけではなく、消化器や机といった屋内にある備品の位置情報も定義することができます。

IMDFで定義した屋内フロアマップは、MapKitを使って表示することができます。IMDFで定義した屋内マップを地図上に表現することで、屋内の場所をわかりやすく表示したり、施設内の情報を表示する機能なども提供できます。

このセッションでは、Appleが提唱している建物内の位置情報を定義できる IMDF についての仕様や定義の仕方について紹介をします。また、このフォーマットに則って実際に建物内の位置情報を定義して、MapKitを使って屋内のフロアマップ実装例について紹介します。

話すこと:

• Indoor Mapping Data Format の概要
  • 位置情報を定義できるJSON「GeoJSON」とはなにか？
  • 各フォーマットでどのような情報を定義するべきなのか
  • Indoor Map Data Formatの制約について
• MapKitで屋内フロアマップの表示をする実装例
  • MKGeoJSONDecoderによるGeoJSONのデコード
  • 屋内フロアマップを地図の上に表示
  • フロアマップ内で位置を選択して施設内の情報を表示する機能

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

このトークで話すこと

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

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

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

スクリーンショットや画面収録、画面共有などによって、ユーザーの機密情報が意図せず漏洩するリスクは、モバイルアプリにおける重要な課題です。特に、パスワードやクレジットカード番号、決済バーコード、有料コンテンツなど「画面には表示したいが、スクリーンショットには映したくない情報」のニーズは年々高まっています。

本トークでは、SwiftUIアプリにおいてこれらの情報を保護するための、セキュアなViewの構築法を紹介します。対象コンテンツの表示にUIKitを経由せず、SwiftUIのみで完結する実装により、状態管理やアニメーションとの整合性を保ちつつ、安全性と保守性を両立するSwiftUIらしいアプローチ方法を具体例と共に解説します。

トーク内容
⚪︎実際の利用事例
⚪︎スクリーンショットからの保護の必要性と課題
⚪︎従来取られたきたアプローチ
⚫︎どういった仕組みで実現されているのか
⚫︎SwiftUIでどう対応するか
⚪︎これを応用したUIの構築

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

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

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

トーク内容

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

近年、行政や金融など高いセキュリティ基準が求められるサービスと連携するモバイルアプリでは、サーバーサイドだけでなくクライアント（iOSアプリ）側でも厳格なセキュリティ対策が求められるようになっています。私たちのプロジェクトでも、外部サービスとの連携に際して、国際的に認知されたモバイルアプリセキュリティ標準であるOWASP MASVS（Mobile Application Security Verification Standard）v2.0.0に準拠する必要がありました。

本トークでは、「なぜ今、iOSアプリにおいてクライアント側のセキュリティ対策が必要なのか？」という背景を出発点に、MASVSの概要やMASプロジェクト全体の構成、そしてMASVS対応において実際に行った対策を具体的に紹介します。また、標準やベストプラクティスに対してどこまで実装で落とし込むべきかという現実的な判断や、運用・開発体制に与えた影響、対応を通じて得られた気づきもあわせて共有します。

クライアント側のセキュリティ対策という難題に挑んだ実例として、これから同様の取り組みを検討する方や、セキュリティ設計に関心のあるiOSエンジニアの皆さんにとって、有益な知見を持ち帰っていただくことができます。

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と向き合えることを目指します。

QRコードには様々な仕様が存在していることをご存知ですか？
例えば、QRコードを構成するセルの数を「バージョン」と呼び、バージョン1から40までの規格が定義されています。

iOSでQRコードを生成するとき、一般的にCIFilterのCIQRCodeGeneratorを利用します。
しかし、このCIQRCodeGeneratorで指定できるパラメータは、QRコードに含めるデータと誤り訂正レベルの2つだけに限られています。
世の中のQRコード読み取り端末によっては、特定のQRコード仕様のものしか読み取れないことがあります。では、どのようにしてQRコードの様々な仕様を実現したら良いでしょうか？

本トークでは、QRコードの仕様を紐解くことで、iOSで自由自在に仕様を満たしたQRコードを生成する魔術を伝授します。

• CIQRCodeGeneratorの挙動を利用したQRバージョンの操作
• 誤り訂正を利用した疑似フレームQRコードの生成
• 分割QRコードの生成

このトークを通して、iOSにおけるQRコードマスターを目指そう！

2020年にリリースされたApp Clipは、今年の秋に6年目を迎えることになります。
以前よりは少し知名度が上がったとはいえ、WWDC25では2年連続でセッションがなく、未だに存在の薄さが否めないApp Clip。

「アプリの一部をコンパクトにしたもの」
「完全版のアプリの一部として管理」
このような性質上、決して"主役"にはなれないものの、アプリの体験を裏から補強するそのポテンシャルは、はたしてどれだけの人やビジネスを動かしたのでしょうか。

このトークでは、App Clipが生まれてから今日に至るまでの5年に至る歴史を紹介していきます。
App Clip 自体のアップデートや、国内外での各業界（飲食、小売、交通、ゲーム等）における実用例を振り返りつつ、その進化と残された課題について見ていきます。

App Clipを待つのは夜明けか、それとも日没か。
5年経った今だからこそ見えるその可能性に迫っていきませんか。

本セッションでは、Live Activityに現在駅と次駅を表示するiPhoneアプリを一緒に作りながら、乗客がアプリを開く必要のない体験を実現します。その道中でCore Location、Core Motion、ActivityKit、SQLiteなどのフレームワークを使います。

1. データ収集
   まず、実際のGPSデータを収集する専用iPhoneアプリを実装します。

2. アルゴリズムのブラッシュアップ
   収集したデータを用いてリアルタイムに予測を行う純粋アルゴリズムを開発します。検証のために、シミュレーションデータを再生できるmacOSアプリを用意します。

3. バックグラウンド対応アプリの開発
   本番のアプリではCore Locationの「signficant change location service」を利用して自動的に起動し、バックグラウンド位置取得でアルゴリズムにデータを供給し続けます。

4. 自動的に開始・終了するLive Activityの実装
   プッシュ通知サーバを使い、バックグラウンドからLive Activityを開始・終了させます。これにより、乗車の開始と終了に合わせてLive Activityが自動的に表示・非表示を切り替わり、ユーザはアプリを開く必要がありません。

Xcode Previewsは2019年のXcode 11でSwiftUIと共に導入されました。リアルタイムでUIのプレビューを確認できる機能で、開発者のUI構築を効率化します。Xcode 15では #Preview マクロによってプレビュー定義の簡素化と、UIKitのView/ViewControllerのプレビューがサポートされました。またXcode 16ではstatic framework内でのプレビューもサポートされるなど、年々進化しています。

私たちが開発しているアプリにおいても、Xcode Previewsの導入によるUI構築の高速化、開発者体験と開発生産性の向上を目指して、部分的に試行されていました。そのアプリは非常に大規模なマルチモジュール構成で、アプリの起動速度を速くするためにdynamic frameworkではなくstatic frameworkを使用しているため、そのままではプレビューを使えませんでした。一時的にdynamic linkに設定変更してプレビューを使う試みもありましたが、しばらくするとビルドできなくなっていることもしばしば。

先述のXcode 16でのstatic frameworkサポートにより、アプリの起動速度の高速化とXcode Previewsの両立ができるようになりました。しかし実際に検証を始めてみると、特定の条件下でプレビューがクラッシュするなど、導入は一筋縄では行きませんでした。本トークではそうした実際の課題と解決策をケースごとに解説し、どのように実用化に至ったのかを紹介します。またXcode Previews活用の現状と今後の展望についてもお話しします。

ツールやビジュアライザなど大量データを扱うアプリでは、ユーザー操作によるメモリ不足でアプリの応答性が下がったり、Jetsamイベントによる強制終了が起こり、最悪の場合ユーザーデータの損失に繋がる可能性があります。クラッシュしてしまう前に防いだり、ユーザーに気付いてもらうためにはどうすると良いでしょうか。このトークでは、iOS・iPadOSのメモリやメモリワーニングの仕組みや、メモリ不足による強制終了を防ぐ知見について以下のような内容で紹介します。

• Jetsamイベントとは
• メモリワーニングによるメモリ不足の検知
• iPadOSのEntitlement(Increased Memory Limit, Extended Virtual Addressing)
• 実践例や失敗例の紹介

私たちが日常でよく目にするバーコード。その裏には、見た目ではわからない微妙な規格の違いが潜んでいることをご存知ですか？

本 LT では、 STORES レジアプリの開発中に直面した「Vision フレームワークが 12 桁のバーコードを 13 桁として認識してしまう」という現象をきっかけに掘り下げた、バーコードの規格と Vision フレームワークの仕様について紹介します！

この現象により、 12 桁のバーコードで登録されている商品をスキャンしても、ヒットしないという問題が発生しました。
Apple の公式ドキュメントでは明示されていない現象で、「なんでや！」と言いたいところですが、バーコードの規格をよく見ると、Vision フレームワークはその規格の性質を利用して、認識していたことがわかりました。
(Google の API はちゃんと認識できるんだけどな…)

本 LT では、以下の内容について話します。

• UPC-A (12 桁) と EAN-13 (13 桁) バーコードの仕様
• Vision フレームワークの認識ロジック
• 正確なバーコードかどうかを判定するロジック
• 回避方法と実装テクニック

1 桁の違いがオペレーションを止めてしまう、現実世界とアプリを繋ぐアプリならではの知見を共有します！
皆さんもバーコードマスターになりましょう！

Swift Package Manager 5.6から登場した Build Tool Plugin。
ビルド時にコードやリソースを生成できる強力な機能として、登場から3年が経ち、多くのプロジェクトで利用が進んでいます。

そんな Build Tool Plugin、便利さの裏で「あること」を見落としていませんか？

Derived Data に出力される成果物。
それがどこまでアプリに影響を与えるか、普段どこまで意識してビルドしていますか？

今回の発表では、Build Tool Plugin を通して気づいた“とある落とし穴”と、それにまつわる 実体験からの学びを共有します。
思わず「ヒヤッ」としたその出来事、Derived Dataの奥底から灼熱の有明にお届けします。

「名前書くの、正直めんどくさい…」

きっかけは、そんな僕自身の心の声でした。
僕の学校の図書館は紙で本の貸し借りが管理されているアナログ方式。
図書の管理表に学籍番号や本のタイトルを書くのが面倒で、紙に何も書かずに本を持っていってしまって行方不明になるという問題が度々起きていました。

「それなら、俺が図書管理アプリ作ればいいのか」

そんな思いつきで勝手に作り始めた図書管理アプリ。
職員の方に軽い気持ちで見せたらビビるぐらい気に入っていただけて、気づけば学校を巻き込んだプロジェクトになっていました。

本セッションでは、趣味で始めたアプリ開発が学校の公式案件になるまでの道のりと、そこで待ち受けていた数々の試練。
そして、学生だからこそできた解決方法についてお話しします！

はじめてSNSアプリを作るとき、多くの開発者が直面する最大の壁。それがApp Storeの審査(App Review)です。

SNSアプリをApp Storeにリリースするには、他ジャンルのアプリ以上に厳しいApp Reviewの壁が立ちはだかります。
特に、ユーザー生成コンテンツ（UGC）を扱うアプリは、ユーザー保護の観点から求められる機能は多岐にわたり、設計段階から審査基準を意識していないと、何度もリジェクトされてしまうことも珍しくありません。

このLTでは、個人で開発したSNSアプリが何度もリジェクトされながらも、最終的にApp Storeに掲載されるまでの実体験をベースに、以下のような具体的なノウハウを共有します。

LTで話すこと：

• 実際にAppleにリジェクトされた理由と、それにどう対応したか
• App Reviewガイドラインに則った設計・実装で気をつけるべきポイント
• ガイドラインには明記されていないが、対応すべきこと

「はじめてのSNSアプリ開発」でつまずかないための実践的な知見を、リアルな失敗談とともにお伝えします。
今後、UGCを扱うアプリを作成する方の、少しでも力になれたら幸いです。

iOSアプリの配布方法というと「AppStoreで公開」か「社内配布（MDMやTestFlight）」の二択だと思っていませんか？ 実はAppleは、企業や団体向けに「Custom App（カスタムApp）」という第三の配布形態を提供しています。 この配布方法は、App Storeを利用しながら、あらかじめ指定した対象者のみにアプリを安全に届けることができる仕組みです。 業務アプリやパートナー限定アプリなどに非常に適していますが、認知度はまだ高くありません。

本セッションでは、AppStoreの配布方法の進化を振り返りつつ、Appleが提供する「パブリック」、「社内配布」、「プライベート（Custom App）」という3つの主要な配布手段の違いや選定基準、審査プロセス上の違い、組織的な利点や制約をわかりやすく整理します。 私が実際に全国約400店舗に向けた業務アプリの配布をCustom Appを用いて行ったので、それにまつわる経緯や運用方法を交えつつお話しできたらと考えています。

「社内用アプリだけどAppStore配信もしたい」「審査が不安」「配布先を限りたい」──そんな悩みを持つiOSエンジニアやIT管理者にとって、“Custom App”は強力な武器になります。あまり語られることのないこの配布手法の実際を、現場の視点でお届けします。

みなさん、3日前に着た服装を覚えていますか？僕は覚えていません。
せっかく毎日服を選んで着ているのに、その記憶が残らないのは少し勿体ないと思いませんか？

この課題を解決するため、私はCoreMLを活用して全身写真からその日に着用したコーデのアイテムを自動で抽出し、まるで手元にクローゼットを持つような体験ができるアプリ”IRODORI”を開発しました。
このアプリは、DeepFashion2というファッションに特化したMLモデルを選定し、アイテム抽出をデバイス上で完結させています。そのため、外部サービスにユーザーの全身画像を送信することなく、安全に利用可能です。
また、一枚の画像から自動でアイテムを抽出できるため、手動での面倒な作業が不要となり、簡単にコーデやアイテムを管理できる点も魅力です。

トークでは、実例をもとにCoreMLを使いオンデバイス完結のiOSアプリを実装する上で試行錯誤した点をお伝えします。
・モバイルファーストなMLモデルの選定基準
・MLモデル(DeepFashion2) をCoreMLで使えるように変換する実装
・MLモデルを動かす上でのUI/UXの工夫

本トークがオンデバイスでMLモデルを動かすiOSアプリ開発の敷居を下げ、アイデアを思いつくきっかけになれたら嬉しいです。
今後加速すると予想されるオンデバイス×MLモデルでのiOSアプリ開発に備えましょう！

Vibe Cooking は、"ノリで料理する" がコンセプトのアプリです。このアプリでは、レシピ手順の読み上げや音声操作によるレシピ手順の移動で、調理中のハンズフリー操作を実現していました。

2024 年 9 月、Apple は、頷きまたは首振りのヘッドジェスチャを使用して Siri に応答する機能を発表しました。これは、新しいインタラクションの形であり、"ノリで料理する" がコンセプトである以上、ヘッドジェスチャによるインタラクションを実装しなければならないという使命感に駆られました。

このトークでは、AirPods を使ったヘッドジェスチャ検知の実装方法と、それが音声によるインタラクションとどのように異なるのか、Vibe Cooking の UX にどのような影響を与えたのかについてお話しします。

このトークでお話しすること

• CoreMotion を使った ヘッドジェスチャ検知の実装: 頷きや首振りのヘッドジェスチャをどのように検知し、アプリに組み込んだのかを解説します。
• ヘッドジェスチャによる UX の変化: ヘッドジェスチャが Vibe Cooking の UX にどのような影響を与えたのか、音声操作と比較しながら紹介します。

SwiftUIを使った機能開発が主流となり、複雑な動作も十分実装することができるようになりました。
iOS16以降ではmodifierが充実しており、大抵の機能はSwiftUIのみで実装可能です。
またWebSocketによる双方向リアルタイム通信もiOS13より標準でサポートされ、以前より導入しやすくなっています。

技術的には「簡単にできそう」に見えたリアルタイムチャット機能の実装でしたが、実際にプロダクションレベルで動くものを作ると想像以上に複雑でした。

このLTでは、実装過程で遭遇した「チャットUIのスクロール位置制御の困難さ」と「WebSocket通信のエラーハンドリングの複雑さ」について、実際のコード例を交えて紹介します。

SwiftUIでチャット機能を実装予定の方や、WebSocketを使ったリアルタイム通信を検討中の方に実践的な知見をお届けします。

去年 WKWebView 関連の開発をするとき、どうしても解決できない問題を発見しました。

当時作った issue： https://bugs.webkit.org/show_bug.cgi?id=274818 （クリックがランダムで反応しなくなる問題。）

それを頑張って調べて、WebKit のバグだと確認し、WebKit の Bugzilla に提出しました。
WebKit の開発者から、それはすでに別の PR で解決されていると言われ、でも再現できませんでした。

色々試した結果、それは WebKit のテスト用スクリプトに問題があると判明しました。
このスクリプトは、ローカルでコンパイルした WebKit を既存のアプリに取り込んで実行するスクリプトです。
実行する際、必要な環境変数の設定に失敗して、アプリは古い WebKit のままで実行されます。
このバグは将来 WebKit の修正に取り組む皆に影響するので、私は新しい Issue を作って、PR を出して、マージされました。

https://bugs.webkit.org/show_bug.cgi?id=275207
（SIP環境でDYLD_FRAMEWORK_PATHが設定できない問題）
https://github.com/WebKit/WebKit/pull/29578

この LT は、この問題発見から PR を出した流れとその中の面白いところを話します。