Swift で日時・数値・名前などの情報を String との間で変換（フォーマット）してくれる仕組みのひとつである「FormatStyle」は、2021年の Swift 5.5（iOS 15.0 等）から使えるようになりました。

これまでのフォーマットでは Objective-C ベースの DateFormatter・NumberFormatter といったものを使ってきました。これを Swift のプログラムから使おうとするとき、高度なカスタマイズについて学習する必要があったり、型安全性などのコンパイラの支援が足りなかったり、また Formatter 自身のキャッシュについて考慮する必要もあったりと問題も抱えていました。

新しい「FormatStyle」は Swift ベースで構築されており、それらの問題へアプローチされパフォーマンスが良いとされています。また、フォーマットしたい形式を SwiftUI の View の Modifier のようにチェーン式で記述してカスタマイズするインターフェイスを備えています。

一方で、従来の Formatter とは使い方が異なるため、これまでと同じフォーマットを FormatStyle を使うように移行する際に、混乱しているようすも見受けられます。

登場から4年経った今、FormatStyle へ移行するのにぴったりな時期が訪れました。このトークでは、Swift でのフォーマットについてこれから勉強される方や、従来の Formatter からの移行を検討している方、移行に困っている方などを対象に、FormatStyle の使い方、カスタマイズの仕方、作り方について述べます。さらに、従来の Formatter との比較や、移行の際の考え方・勘所のノウハウ、そして FormatStyle の内部実装についても解説します。

「ふつうのアプリ」とは何でしょうか。
ソーシャルネットワークMastodonのアプリを作る過程で、この問いと深く向き合うことになりました。

Mastodonは少し特殊なSNSです。サーバーの概念や公開範囲の複雑さ、サーバーごとの固有機能など、それらの仕様は直感的なものではありません。
実際にアプリをリリースしてみると、ユーザーが求めていたのはMastodonの機能を完璧に扱えるアプリなのではなく、直感的に使える「ふつう」のSNSアプリなのでした。
TwitterやInstagramのような既存のSNSで慣れ親しんだUIパターンを期待していたのです。

ここから学んだのは「ふつう」を実現することの難しさです。開発者にとって当たり前の操作でも、一般ユーザーにとっては全く理解できない可能性があります。
開発者やデザイナーは独創的なUIを作りたがりますが、ユーザーは慣れ親しんだパターンを求めています。重要なのは、新しい概念を既存のメンタルモデルに合わせることです。
これらは、もちろんMastodonのアプリに限った話ではありません。

このトークでは、アプリのUIデザインを考察した上で発見した「ふつう」の見つけ方、既存UIパターンの評価方法、そしてそれらを妥協せずに実装するための実践的なテクニックを紹介します。

本文の提案:

アプリ開発で、バックエンドAPIの準備が整っていないために、モックサーバ構築に多くの時間を費やした経験はありませんか。
本セッションでは、iPhoneを活用して軽量なHTTPサーバを動作させ、開発中のアプリが必要とするAPIを迅速に提供する手法を紹介します。
この手法は、複数クライアントを捌く本格的なサーバではなく、1対1で開発中のアプリとペアリングするシンプルな構成であり、手軽に導入できる点が特徴です。

従来のモックサーバ構築では、APIスキーマの定義、レスポンスデータの準備、サーバ環境の構築など、多くの工程が必要でした。
しかし、iPhoneサーバアプリを使用することで、これらの課題を効率的に解決できます。

このセッションで話すこと:

• iPhone上での軽量HTTPサーバの実装方法
• モックAPIの効率的な構築方法
• 実装デモの紹介

対象者:

• iOSアプリ開発者（初級〜中級）
• バックエンド開発を待つことなく効率的に開発したいエンジニア
• モックサーバ構築の手間を省きたいチーム

モバイルアプリ開発において、データの同期や共有が必要な要件に直面したとき、皆さんはどのようなデータ管理サービスを選択しますか？
おそらく次のような意見をよく耳にするでしょう。

「FirebaseのRealtime Databaseがベター！データ同期も簡単だし、他サービスとの連携も楽々！」
「柔軟性を考えるなら、サーバーもデータベースも自前で構築すべき」
「とにかくUserDefaultsに無理やりぶち込んでしまえ！（いや、流石にそれは厳しい……）」

私自身もこうした選択肢で悩む一人でしたが、最近になって「Supabase」というBaaS（Backend as a Service）を知りました。
Supabaseは、Firebaseと異なりオープンソースであるため、カスタマイズ性や拡張性が非常に高いです。またSQLベースでデータの複雑な処理が可能なことや、料金体系が明瞭でコストの予測がしやすいという魅力もあります。

そこで本セッションでは、Supabaseを活用して実際に簡単なアプリを作成しながら、その使いやすさや特徴を皆さんと共有します。
Supabaseを使ってみることで、皆さんの個人開発ライフに新しい選択肢を加えてみませんか？
一緒にSupabaseの世界へ一歩踏み出しましょう！

SwiftUIが利用可能となって6年が経過し、今では500個以上のAPIが存在します。iOS 13でのリリース以降、毎年開催されるWWDCで新しいAPIが追加され続けています。それにも関わらず、私はiOS 13からiOS 15で利用可能となった基本的なAPIに留まり、新機能への追従ができていませんでした。

この現状を打破するため、「SwiftUI未使用API100本ノック」と称し、自分が使ったことがないAPIをひたすら学習・検証する活動を行いました。それにより、従来の複雑な実装がより簡潔に、そしてレンダリングに優しい書き方に変えられることを学びました。本トークでは、100本ノックで発見した便利なAPIを実際のコードに適用した事例を紹介します。GeometryReaderの代わりに containerRelativeFrame(_:alignment:) を使う方法や、 onGeometryChange(for:of:action:) による効率的な値の監視など、実践的な改善パターンをお見せします。

このトークのゴールは、より効率的でメンテナンスしやすいSwiftUIコードを書くための具体的な方法を学んで持って帰っていただき、日々の開発に役立てていただくことです。

対象聴衆は以下の方です。

• iOS 16からiOS 18までのSwiftUIのAPIを使いこなせていないと感じている方
• 既存のプロジェクトでコード改善を考えている方
• SwiftUIコードの可読性向上を目指している方
• GeometryReaderを多用している方

Apple Vision Proが登場し、私達はついに空間コンピューティングへのチケットを手にしました。
3次元の形状を、ディスプレイに投影された平面的なものではなく空間的に体感できるようになったのです。

RealityKitのMeshResourceでは、直方体(Box)、平面(Plane)、球(Sphere)、円錐(Cone)、円柱(Cylinder)、そして文字(Text)といった基本的な形状を簡単に作成できます。
また、Reality Composer Proではカプセル(Capsule)も配置できます。

しかし、これら以外の3次元形状を作成したい場合、どのようにすれば良いのでしょう？
もちろんメッシュの頂点を指定すれば好きな形状が作成できますが、大量の頂点をコード上で逐一指定するのはあまり現実的な方法ではありません。

そこで、パラメトリック曲面と呼ばれる概念を取り入れます。
この手法はすべての頂点を指定する変わりに、2次元のパラメータを指定することで曲面上の座標を表現し、メッシュの頂点を計算させる方法です。

例えば代表的なものとして、多くのベクターイメージ編集ソフトなどでお馴染みの「ベジエ曲線」を拡張した「ベジエ曲面」があります。
これはベジエ曲線と同様に、制御点を動かすことで曲面の形状を直感的に定義することが可能です。

本セッションでは一般的なパラメトリック曲面の解説とベジエ曲面の解説を行い、曲面を直感的に変更できるところをお見せします。
また、ベジエ曲面の性質や限界、実装上の注意点などについてお話します。

学習管理アプリStudyplusでは、「スマホを隔離して集中して勉強したいけど、勉強の記録もしたい」というユーザーの声が多数寄せられていました。これらの声に対してStudyplusでは、FlutterアプリとApple Watchを連携して、Apple Watchでも記録がつけられるようにすることでユーザーの要望に応えることができました。
この対応にはFlutter、iOS、Apple Watchの3つの環境をまたいだ実装が必要となり、それぞれの連携方法を理解することが重要になります。
本セッションでは、Studyplusでの実際の対応事例をもとに、設計から実装、そして得られた価値まで包括的に解説します。

具体的な内容

• ユーザーの要望の分析や提供したい価値の決定
• どの機能をApple Watchに切り出すかの仕様決定
• Flutter・iOS・watchOS間の実装設計と技術選択
  • WCSessionを使ったiOS・watchOS間のデータ通信・監視
  • Method Channel、Pigeonパッケージを使ったクロスプラットフォーム連携
  • Apple Watchの制約を考慮したUI/UX設計
• 対応によってユーザーに提供できた価値

Apple Watch対応を通じて実際のサービス開発で得られた知見を余すことなく共有し、すぐに活用できる実践的な内容をお届けします。

対象者

• Apple Watch対応を検討中のアプリ開発者
• iOS・watchOSアプリ開発者
• クロスプラットフォーム開発でのネイティブ実装を学びたい開発者

visionOSの登場により、従来のARKitでは難しかった高精度で安定した空間アンカリングが実現可能になりました。インテリア配置アプリ、教育・トレーニング、設計支援など、様々な分野でデジタルオブジェクトを物理空間に正確に配置し続ける需要が高まっており、「一度配置したらずっとそこにある」という体験の重要性が注目されています。
この体験を実現する技術がvisionOSのWorldAnchorです。WorldAnchorを活用することで、ユーザーが一度配置したオブジェクトを物理空間に「永続化」し、まるで現実世界に存在するかのような「ずっとそこにある」体験を実現できます。

本セッションでは、実際に開発したデモアプリの事例をもとに、WorldAnchorの実装から期待されるユースケースまで、実践的な観点で解説します。WorldAnchorの活用方法を知りたい開発者の参考になるような内容を目指します。

具体的な内容

• WorldAnchorとは何か？
• 基本的な実装方法（作成・保存・復元の流れ）
• 実際のデモアプリで見る「永続化」の体験
• 今後期待される新しいユースケースの展望

このセッションを通じて、WorldAnchorの可能性を理解し、「物理世界とデジタル世界が融合した新しい体験」を自分のアプリで実現するための具体的なイメージを持っていただけます。

対象者

• visionOS開発に興味があるiOS開発者
• Spatial Computingの具体的な活用方法を知りたい方

2023年にApple Vision ProとともにvisionOSが登場し、iOSエンジニアにとって空間コンピューティングという3Dコンテンツを交えた開発がより身近なものになりました。

SwiftUIやRealityKitといった馴染みのある技術を活用できる一方で、3Dモデリングに関する用語や概念に戸惑いを覚える方も多いのではないでしょうか。

中でも「マテリアル」は、オブジェクトの見た目や質感を左右する重要な要素でありながら、iOSアプリ開発ではあまり馴染みのない概念です。

RealityKitには用途に応じた多様なマテリアルが存在し、それぞれに特性があります。しかし、「どれを選べばよいかわからない」「そもそも何が違うのか」と感じる場面も少なくありません。

本セッションは、RealityKitのマテリアルを網羅的に解説し、どのユースケースでどのようなものが用いることができるかの全体像を把握できるものとなっています。

以下のような観点から解説を行います。

• マテリアルとは？ ：
  光沢、粗さ、透明度など「色」だけでは語れない見た目の要素を分解して解説。
• RealityKitで使える全マテリアルAPIの解説と実例：
  SimpleMaterialでの基本表現、PhysicallyBasedMaterialによるリアルな質感、VideoMaterialでの動画埋め込みなど、現在RealityKitで提供されているAPI全ての特徴とユースケースを紹介。

本セッションを通じて、visionOSで利用可能なRealityKitのマテリアル全体をユースケースと合わせて理解し、空間コンピューティングならではの新しい体験づくりのヒントを得ていただければ幸いです。

UIテスト時にUI要素を特定するための識別子であるAccessibility Identifierですが、SwiftUIのViewにAccessibility Identifierを指定するには各Viewに accessibilityIdentifier Modifierを適用する必要があり、テストケースの増加に伴いModifierの適用が面倒になってくるという課題があります。

Swift 6.0から「SE-0415: Function Body Macros」という、既存の関数の中身を書き換えることができるSwiftマクロが導入されました。本トークでは、Function Body Macrosを使ってSwiftUIのViewにaccessibilityIdentifier Modifierを自動で付与する方法と、実装時に遭遇した落とし穴とその回避策についてご紹介します。

Accessibility Identifierを自動付与することで、accessibilityIdentifier Modifierを各Viewに適用する煩わしさから解放されましょう！

話すこと:

• Function Body Macrosの概要
• Accessibility IdentifierをSwiftUIのViewに自動付与するFunction Body Macrosの実装方法
• マクロ実装時に遭遇した落とし穴とその回避策
• 作成したマクロをアプリ側に導入し、UIテストで自動付与されたAccessibility Identifierを使う

マップを活用した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のデコード
  • 屋内フロアマップを地図の上に表示
  • フロアマップ内で位置を選択して施設内の情報を表示する機能

紙のマップは古くから多くの人々に利用されてきました。そして、スマートフォンの登場によりいつでもどこでもマップを確認できるようになっています。

マップに関する機能は、MapKitなど開発者向けのフレームワークとして公開されています。このフレームワークを用いて、マップを活用したアプリケーションが数多く登場しています。特にモビリティ関連のアプリケーションでは、マップによる位置情報の表示が中心的な機能となっており、今や欠かせない存在となっています。

マップを活用したアプリケーションを実装するには、マップの表示技術や緯度経度といった座標に関する知識が不可欠です。このようなマップに関する基礎知識が不足している状態でアプリを実装すると、誤った位置に場所を表示したり、地図上に情報を表示するまでに時間がかかったりするなど、ユーザー体験を損なう原因となります。しかし、これらの知識は開発者用のドキュメントにはあまり記載されておらず、基礎知識がない状態で実装してしまう場合が多いです。

このセッションでは、マップを扱う上で必要な知識を共有しながら、MapKitを使ってマップを活用したスマホアプリの実装例を紹介します。

このセッションで話すこと:

• マップを扱う上で必要な基礎知識
  • どのようにアプリは地図を表示しているのか
  • 座標・緯度経度とはなにか
  • マップで場所を表現するのに必要な要素
  • マップの表示領域と位置情報を表示する量について
• MapKitでアノテーションなどの独自の位置情報を表現して表示する
• MapKitを使った場所検索やルート検索機能の実装

現代のモバイルアプリ開発において、ネットワーク通信は不可欠な要素となっています。
そして、ネットワーク通信機能を実装する時に合わせて必要になるのが、エラーハンドリングの実装です。

よくあるエラーハンドリングのパターンの1つに挙げられるのが、アラート表示です。
アラートはiOSアプリでよく利用されるコンポーネントであり、データの取得などに失敗してもエラーの発生を簡単にユーザーに通知することができます。
また、デザイン等で考慮することが少なく、表示の実装も簡単であるため、特に小規模なアプリではエラーハンドリングとしてよく採用されがちです。

しかし、皆さんはアラート表示の落とし穴に気づいていますか？
アラートは同時に1つしか画面に表示することができないため、複数のAPIで同時にエラーが発生した場合に、アラートが重なってしまいます。
アプリで同時に複数のAPIと通信することは珍しくなく、また仕様追加によって当初想定されていない部分で複数のAPIを実行する仕様になることもよくあります。

エラーハンドリングは一度実装するとアプリ全体で共通エラーハンドリングとして扱われることが多いです。
そのため、アプリ開発の初期から長期運用を目指した設計を行うことが非常に大切になります。

このトークでは、以下の内容についてお話しします。

• エラーハンドリングをアラート表示で行うことについての問題点
• 場面に応じたAPI通信エラーの表示パターンの紹介
• エラーハンドリングのパターンに合わせた、API通信中のローディングの表示パターンの紹介

近年は長期運用されているモバイルアプリが多いという背景もあり、エンジニアがエラーハンドリングについての設計や共通部分の実装を行う機会は少なくなっているように感じます。
だからこそ、この機会に改めてエラーハンドリングについて考え直してみましょう！

私は元々Androidエンジニアとしてキャリアをスタートし、現在はiOSエンジニアとして開発に携わっています。両プラットフォームを経験したからこそ、Xcodeの常識がAndroid Studioでは通用せず、逆にAndroid経験者としての当たり前がiOS開発では壁になる、という両方の戸惑いを実体験として持っています。このトークでは、そんな自身の経験を元にiOSエンジニアがAndroid Studioを前にした時の「これ、どうやるの？」という疑問を解消し、スムーズにAndroidの世界へ入門できるよう、Xcodeとの比較を交えながら実践的な使い方を解説します。

「KMPプロジェクトで共通ロジックを触りたい」「ちょっとAndroid側の実装を確認したい」などiOSエンジニアでもAndroidプロジェクトを確認したいことがあると思います。しかし、いざ勇気を出してプロジェクトを開いてみたものの…

・「そもそもプロジェクトってどう開くの？ .xcodeproj にあたるファイルはどこ？」
・「デバッグ実行したいけど、Scheme みたいなビルド設定はどこで切り替えるんだっけ？」
・「ライブラリの依存関係は？ Package.swift のようなファイルはどれ？」

といった Xcode の常識が通じない壁にぶつかり、単に挙動を確認したいだけなのに、環境構築や操作方法の調査で時間を溶かしてしまった…という経験はないでしょうか？
本トークでは、基本操作に加えファイル検索や呼び出し階層の確認などのショートカット、Xcode・AndroidStudio特有の便利機能について、私の実体験を交えながら一つずつ話していきます。

概要

GitHub Copilot, Cursor, Devin, Claude Code ... 次々と登場する AI ツール。 「結局どれを使えばいいの?」という疑問があると思います。
アプリ開発業務でいくつかの AI サービスを使ってきた経験から、それぞれの AI サービスの「得意技」と「苦手分野」を解説。
さらに、それぞれの特性を活かした「ハイブリッドAI開発」の実践方法をお伝えします。

話す内容

• 各 AI ツールの特徴と強み
  • GitHub Copilot: インラインコード補完
  • Cursor: コンテキスト理解に優れたエディタ一体型
  • Devin: 自律的なタスク実行が可能なAIエンジニア
  • Claude Code: 大規模リファクタリングと設計支援
• シーン別 AI ツール使い分け術
  • 新機能実装時のペアプログラミング
  • レガシーコードのリファクタリング
  • テストコード生成とカバレッジ向上
  • コードレビューでの活用
• 併用することで見えてきた開発効率化の限界と可能性

対象者

• AI ツールの導入を検討している開発者
• 複数の生成 AI ツールの使い分けに悩んでいる方
• チームでの生成 AI 活用を推進したいリーダー

iOSアプリ開発におけるCI/CDの遅さに悩んだことがある方は多いでしょう。ビルドに10分以上かかる、キャッシュのダウンロードが遅い、そんな経験をお持ちではありませんか？私たちのチームもこれらの課題に直面し、試行錯誤を経てたどり着いたのが「Namespace.so」という高速CI実行基盤です。
Namespace.so を導入することで、ビルドやテスト時間を約2〜3倍短縮し、従来20分弱かかっていた実行時間を8分弱にまで改善することができました。本セッションでは、その導入プロセスと得られた成果、さらに実際に活用してわかったベストプラクティスや注意点をお話しします。

■ セッションの構成

• CIが遅くなる理由とボトルネックの整理（キャッシュの重さ、ランナー性能、依存関係の再インストールなど）
• Namespace.so の紹介、とそのSaaSにおける速度改善の要点
• 実際の導入方法とその効果（導入前後の所要時間比較、導入時の工夫と課題）

■ 対象者

• CIの速度を改善したい方
• CIのコストを削減したい方
• CIについて興味のある方

■ 得られる知見

• Namespace.soのキャッシュ戦略とmacOSランナー活用法（Apple Siliconによる高速起動など）
• CI/CD高速化がもたらす具体的なメリットと導入のインパクト（2〜3倍の時間短縮など）
• チームに浸透させる運用設計やプロファイル構成のベストプラクティス、即実践できるTips

このセッションを通じて、CI/CD改善に関する実践的なアイデアと手段を提供し、すぐに自チームで活用できることを目指します。

概要

「プライベートリポジトリの SDK、アプリの CI でビルドが通らない...」そんな経験はありませんか?

本セッションでは、OpenID Connect 認証 SDK の開発を通じて得たプライベートリポジトリ配布の完全自動化手法を紹介します。Swift Package Manager でのバージョン管理、GitHub Actions による自動リリース、そしてアプリ側 CI での依存解決まで、実際に動くコードと設定ファイルを交えながら、明日から活用できる実践的なノウハウを提供します。

さらに、AI ツール (Cursor) を活用した効率的な SDK 開発フローや、DocC による自動ドキュメント生成など、モダンな開発手法も紹介。社内 SDK の開発・配布・メンテナンスに関わる全ての悩みを解決します。

話すこと

• 「プライベートリポジトリあるある」から始める課題整理
• リリースフローの自動化
• プライベートリポジトリ認証の設定方法
• アプリ側 CI の実装パターン
• TestFlight はどうする?
• AI ツールを活用した効率的な SDK 開発フローとガードレール

話さないこと

• OpenID Connect の詳細な仕様説明

対象者

• 社内向け iOS ライブラリを開発している方や、これから開発を始めたい方
• セキュアな認証ライブラリの実装に興味がある方

みなさん一度は実践するであろう自作コンパイラ。触ったことがない人に取っては何をすればいいのか、何をしているのか理解されていないと思います。
現在、オープンソースで多くのコンパイラのコードはあり、仕組み自体理解することはおそらく可能でしょう。
時には自分の手でコンパイラを作ってみることも重要だと私は思います。しかも好きなプログラミング言語で。
一度その仕組みを理解し、自身の手に触れてみることは、プログラミング言語やコンピューターサイエンスへの理解を格段に深める貴重な経験となります。

このセッションでは、Swift言語を用いてC言語のサブセットをコンパイルするミニマルなコンパイラーを自作した経験から得られた知見を共有します。
実装を通して直面した課題と解決策、そしてコンパイラの各フェーズが実際にどのように動作するのかを、実践的な視点でお伝えします。
また、Swiftの表現力を活かしたコンパイラ開発の魅力も感じていただければ幸いです。

セッション内容:

1. コンパイラとは何なのか
2. 字句解析 ？
3. 構文解析 ？？
4. 抽象構文木 ？？？
5. コード生成 ！？
6. デバッグ ！！

Apple Intelligence の登場により、App Intent はアプリの機能を外部に公開する重要な基盤となります。しかし、「どのような機能を App Intent として提供すべきか？」という問いに多くのデベロッパーが直面しているのではないでしょうか。

本セッションでは、この課題に対し、Interactive Widget を「App Intent 活用の足掛け」と捉え、アプリを開くことなくウィジェット上で処理を完結させるための具体的な実装方法を解説します。
多くのwidgetでは必要な情報を表示するため活用されたり、アプリへのショートカット導線が提供されているケースが大半です。
Interactiveなwidgetがあれば、ユーザーはアプリ本体を起動せずにタスクを完遂でき、よりシームレスな体験を提供できます。

本セッションではAppIntent の基本的な仕組みや概要には深く触れませんが、Interactive Widget を通じて AppIntent を実践的に活用することで、将来的な Apple Intelligence 対応にも繋がる知見を得られるでしょう。Widgetだけですべてが完結する、新しいユーザー体験の構築に挑戦してみませんか？

このセッションで話すこと

• Widgetでユーザーインタラクションを実現するには？
• Widgetから呼び出すための AppIntent の設計と実装
• Widgetからアプリ本体の機能を呼び出すためには？
• Widget特有のAppIntentの制約とその対応策
• ControlWidgetへの応用

「暑い日にスマートフォンを使っていて、アプリの動作が遅くなった…」そんな経験、ありませんか？
特に屋外で利用されるアプリにとって、端末の温度はユーザー体験を大きく左右する重要な要素です。スマートフォンが熱を持つと、アプリのパフォーマンスが著しく低下したり、一部の機能が制限されたりすることがあります。このような影響を把握しておくことは、快適なサービス提供のために非常に重要です。

本トークでは、Foundationフレームワークに含まれる ProcessInfo.ThermalState API に注目します。このAPIを使うことで、デバイスの熱状態を4段階で把握することが可能です。
今回は実際に屋外で使われるモビリティアプリにおいて、ThermalState が季節や時間帯、アプリの状態などによってどのように変化するのかなど、実測データとともに詳しくご紹介します。
さらに、熱状態に応じてアプリが取ることができる対策についても解説します。

スマートフォンを「熱中症」から守り、夏でもクールで快適なユーザー体験をお届けしましょう！