トーク

マップを活用した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)
• 実践例や失敗例の紹介

音楽とプログラミングはまったく違うもの。芸術と情報工学の間に、共通点などない。
……と思われている方も多いようです。
しかしながら、それは大きな誤解なのです。
なぜなら、音楽は数学だから！
「ド ド# レ レ# ミ ファ ファ# ソ ソ# ラ ラ# シ」、誰もが知っているこの音の並びを生み出したのは、古代ギリシャの数学者ピタゴラス、と言われています。

プログラマと音楽は相性が良いのです。
私自身も、平日はプログラマ、週末はアイドルなどへの楽曲提供をする作曲家です。

プログラミングはコード(code)を書き、作曲はコード(chord)を使います。

この「コード」を中心にプログラマなりの作曲を考えてみましょう。
コードネームから構成音を求めるプログラムを作ることができます。
コード進行にはパターンがあり、デザインパターンやライブラリのように利用することができます。
コード進行からメロディを導き出して作曲していくことができます。

本トークでは

1. 作曲とはなんなのか
2. コードの仕組み
3. コード進行はパターンである
4. コード進行を演奏するiOSアプリを作る
5. コード進行から曲を作る

についてお話しします。

iOSアプリで外部ストレージにデータをやり取りする際、UIDocumentPickerViewControllerを利用するのが一般的です。しかし、独自UIを構築したい、接続タイミングでカスタマイズしたい、といった要望に応える情報はほとんどありませんでした。

特にアプリ専用ストレージとの連携ではExternalAccessory.frameworkが候補となるものの、MFi登録が必要で敷居が高く、USB-C端末ではその必要がない場合もあります。
私自身もApple公式フォーラムで質問したり（ https://forums.developer.apple.com/forums/thread/758598 ）、Appleエンジニアの協力を得て、ようやくImageCaptureCore.frameworkというフレームワークを見つけることができました。

本セッションでは、AVExternalStorageDeviceDiscoverySessionやImageCaptureCore.frameworkなど、あまり知られていない公式フレームワークを活用し、「独自UIで外部ストレージを自在に扱う方法」を詳しく解説します。iOSで“思い通りのメディアファイル体験”を目指す方に、具体的な手法とTipsをお届けします。

Apple CryptoKit は、 Swift で利用可能な暗号化処理のフレームワークです。

Xcode 上ではインストール不要で利用できることや Swift 言語の特徴を活かしたインターフェース設計となっていることから、実用性だけでなく手を動かしながら暗号技術を学ぶのにも向いているのではないでしょうか。

ただ、暗号技術はデータの秘匿だけでなく、デジタル署名やメッセージ認証コードなど幅広い分野で利用されていることから、まずは特定の分野に絞って学習を始めるのがおすすめです。

本トークでは、 Apple CryptoKit の概要や特徴を紹介します。その上で、数ある暗号技術の中から署名付き AWS API リクエスト の生成処理を題材にメッセージ認証コードについて紹介します。

Apple CryptoKit の概要を知るだけでなく、暗号技術についてより身近に感じてもらえるようなトークを目指します。

アジェンダ

• Apple CryptoKit の特徴 〜 Swift らしい書き心地と信頼性
• Apple CryptoKit がサポートする暗号技術 〜 暗号化、ハッシュ化、メッセージ認証
• AWS API リクエスト 生成処理を Apple CryptoKit を使って実装してみる