トーク

現在、多くのアプリではABテストが広く使われていますが、次のステップとして個別最適化が求められています。
AとBを比較するだけでなく、ユーザーの行動パターンに基づいたセグメント分割を行い、ABテストでは拾えなかったユーザーにもアプローチすることでより高い効果を得ることができます。
私たちのアプリではユーザーごとに異なる最適な課金画面を提供することで、収益の最大化を目指しました。

このセッションでは、複数パターンの課金UI検証を通じて得た以下の内容についてお話しします。

• 複雑な検証をデグレさせることなく、高速に実現するための設計と、その実装手法
• 複数パターンの課金画面を安全に運用するための工夫とその課題
• 個別最適化の成果として、ユーザーの課金率にどのような影響を与えたか

このセッションを通して、皆さんのアプリでも効果的なUIの個別最適化を実現しましょう。

Swiftは型安全な言語です。
しかし、Swiftで書かれたものが全て型安全になるわけではありません。
Swiftで書かれたコードの中にも、より型安全なコード、あまり型安全ではないコード、のように「型安全の度合い」は異なってきます。
型安全性が低いと、安全でないキャストが必要だったり、不正な入力値がコンパイルエラーにならなかったりし、開発者は多くのことを考えコードを書く必要があります。
一方で型安全性が高いと、より多くのことをコンパイラに委ねることができ、開発者が考えるべきことは減ります。

このトークではNotificationCenterのラッパーを題材に型安全性を高める方法を取り上げます。
NotificationCenterはObjective-C由来のインターフェースを持つため、安全でないキャストが要求され、不正な値を渡してもコンパイラエラーにならず、型安全性はあまり高くないといえます。
そんなNotificationCenterのラッパーの作成を題材に、Swiftの言語機能であるジェネリクスやマクロを用いて、型安全性を高めていく技術について紹介します。
題材はNotificationCenterですが、皆さんがこれからデザインするインターフェースにも通じる考え方と技術を紹介します。

このトークを通して、皆さんが"より"型安全なコードを書けるようになることを目指します。

多くのプロジェクトでは何らかのライブラリを活用してアプリの機能開発や自動化等を行っていると思います。
「家族アルバム みてね」でも、現在約30個のライブラリを活用して日々開発を行っております。

しかし、ライブラリのおかげで効率化できている一方で、ライブラリ起因の負債も多々ありました。具体的には、「更新が止まっているライブラリに依存している」「古いバージョンのライブラリを使い続けている」などです。これらの負債によって、Xcodeのアップデートでビルドエラーが発生して予想外に時間を取られたり、ライブラリの新しい機能を使えないことで追加の開発が必要になるなど、作業のスピード感に影響が出てしまっていました。

本セッションでは、依存するライブラリ起因の負債を解消するまでの具体的なステップと、負債を生まないために導入した仕組み、実際に運用してみた成果をお話します。特に以下のポイントについて詳しく説明します。

• ライブラリ周りの負債の分類と対応方法
• ライブラリのアップデートにおける仕組みづくりとQA

「Tint Colorをデフォルトのまま使うと、初心者感がありチープに見えるから避ける」
ある日の自分はそう考えていました。しかし、Appleが推奨する色をこのような理由で軽率に変更するのは適切なのでしょうか？いいえ、デフォルトの設定には、それなりの理由が存在するはずです。実際、デザインの一貫性やユーザー体験の向上を考慮した結果として、デフォルトの青色が選ばれている可能性があります。

本トークは、青色が選ばれた背景を以下の観点から考察していきます。

・他OSとの比較から見える共通点
・初代iPhone OSから現在のiOSまでのデザイン変化
・iOSとMac OS のデザインの共通点と違い
・カラーディスプレイの登場による影響
・ハイパーリンクが青色である理由
・青色が持つ視覚的効果と心理的影響について

このトークを通じて、Appleのデザイン哲学や、その背後にある考え方を深く理解することができるようになります。デフォルトの青色を軽視せず、その価値を再評価することで、より洗練されたデザイン選択ができるようになるでしょう。

アプリが成熟してくると、プロユース向けに複雑なジェスチャーを実装することがしばしばあります。
本セッションでは、有名なアプリに組み込まれているユニークなジェスチャーを紹介し、その実装方法について考えます。
また、既存のアプリを壊さないように安全に実装するコツや、アクセシビリティを考慮した設計の重要性についても触れます。

• ジェスチャー例 (YouTube のシークジェスチャー や Googleマップの片手ズーム)
• ジェスチャーの実装を想像してみる
• 複数のジェスチャーを実装するときの勘所
• アクセシビリティを考慮した設計

Appleが提供する機械学習フレームワークであるCoreMLと、そのモデル生成に使用されるCreateMLを用いて、ユーザ個別に最適化された筋トレ自動計測アプリを開発しました。

一般的な流れでは、データセットとXcode付属のCreateML（GUIツール）を使用してモデルを作成し、CoreMLを用いてiOSアプリに導入することが一般的です。

しかし、以下の方法を用いることで、アプリ内でモデルの新規学習や追加学習を完結させることが可能です。

• 新規学習: 一部のモデルは、アプリ内でCreateMLから直接学習可能です。
• 追加学習: Updatableなモデルは、アプリ内でCoreMLのMLUpdateTaskを使用して追加学習が可能です。

これらの方法は、特に”ユーザ依存性の高いコンテンツ”の開発に有効です。今回は、Updatableなモデルを使用して、端末のセンサーデータを基にユーザ定義の筋トレメニューの実行回数を自動計測するアプリを開発しました。

このテーマは開発だけでなく、研究的な要素も含んでいます。以下の内容についてお話しします。

• アプリ内部でのCoreMLモデルの追加学習の手法
• センサーデータ（時系列データ）を用いたモデルにおける判定精度向上の研究
  • 学生時代に近しい研究をしていた際のノウハウ

皆さんはカメラアプリを実装したことがありますか？
iOS標準の操作感を持つカメラを簡単に実装するなら、UIImagePickerControllerが便利です。
一方で、シンプルに撮影する機能だけで良い場合や、カスタマイズが必要な場合、AVFoundationを選択することが多いでしょう。

SPIDERPLUSでは、UIImagePickerControllerで実現できない要件があり、AVFoundationを使用してiOS標準風の操作感を持つカメラを自作しました。
本トークでは、AVFoundationでiOS標準風の操作感を持つカメラを実現するまでの過程について詳しくお話しします。

<トピック>

• iOS標準風の操作感がなぜ重要か？
• UIImagePickerControllerで実現できなかったこと
• iOS標準風に感じる操作感の具体的な機能とは？
• AVFoundationを使ってiOS標準風の操作感を実装する方法

現代のiOSアプリ開発において、Web APIとの連携は避けて通れない重要な要素です。本トークでは、HTTPの標準を上手に利用する方法を中心に、効率的で信頼性の高いWebバックエンドとの通信方法を探ります。また、RESTfulなアプローチだけでなく、GraphQLなどの新しい技術を活用したデータ取得の方法についても解説します。

主なトピックは以下の通りです：

・HTTPの基本と効果的な利用法
・RESTful APIの設計と実装のベストプラクティス
・iOSアプリでのエラーハンドリングとリトライ戦略
・GraphQLの基本概念とiOSアプリでの導入事例
・バックエンドに優しいアーキテクチャ

このトークは、iOSアプリ開発者がWebバックエンドとの連携をより円滑にし、アプリの信頼性とパフォーマンスを向上させるための具体的なアドバイスと実践的な知識を提供します。初心者から中級者まで幅広いレベルの開発者に役立つ内容となっています。

モバイルアプリ開発では、たとえ新しいバージョンをリリースしてもいきなり全ユーザーが最新バージョンのアプリを利用するようになるわけではありません。旧バージョンを利用し続ける人も一定数いるため、我々は新旧バージョンにおけるデータの互換性や将来想定される仕様変更に対する拡張性を意識しながら設計していく必要があります。

例えば、アプリに永続化したデータの構造を新バージョンで変更する場合やサーバーから取得するレスポンスのフィールドに新しい要素を追加する場合、さらには旧バージョンで不具合が生じたときに新バージョンへの更新を促したい場合など、新旧バージョンと向き合わなければならないケースというものは多岐に渡ります。

すべてに対して丁寧に対応していくことも可能ですが、考慮しなければならないパターンが多く、ある程度折り合いをつけながら落とし所を探っていくことも重要です。

本トークでは、この新旧バージョンと向き合って開発していく上での戦略的な設計方針から、具体的に求められる戦術的な実装パターンまでを、体系的にお話しします。

iOSでチーム開発をしていると、iMacやMacBookを数年おきに買い替えることが多いかと思います。
その際、使用しなくなったがまだ動作するMacマシンの使い道に困っている方はいませんか？

このトークでは、古くなったiMacの具体的な有効活用方法についてご紹介します。

弊社での活用事例としては、以下の方法があります。

1. CI/CDマシンとしての活用
   古いiMacをCI/CD専用のマシンとして利用することで、新しい機材を購入するコストを削減できます。具体的な導入手順や設定方法についてもご説明します。

2. QAチームでの不具合検証マシンとしての活用
   QAチームが不具合を迅速に検証できる環境を提供するため、古いiMacを再利用します。これにより、迅速な問題解決が可能となり、顧客満足度の向上にも寄与しました。

これにより、会社全体のコスト削減やリソースの有効活用が実現できました。

本トークを通じて、古くなったMacマシンの再活用のヒントを提供できればと期待しています。

Go on a deep dive into the commands of the Low Level Debugger

Understand from the ground level how Xcode uses LLDB under the hood:

Compile, Run, Attach, Detach, Breakpoint, Backtrace and more all from the Xcode console or Terminal command line.

Learn how to run expressions while paused in execution, reading variables in scope and printing the contents of registers

Swift5.9からif式/switch式が使えるようになりました。
これまでのif文/switch文とは何が違うのでしょうか？どんな嬉しいことがあるのでしょうか？swift-evolutionのプロポーザル SE-0380 を読むと、答えが書いてあります。

さて、ここで気になることがあります。そもそも、式とは何でしょうか？文とは何でしょうか？それぞれ何が違うのでしょうか？

このトークでは、Swift5.9からのif式/switch式に触れたあと、Swiftのドキュメントを読みSwiftにおける式と文の概要を理解します。次に、式と文それぞれを中心にプログラムを構成した場合の違いを比較・分析することによって、それぞれに適した使い所を考察します。

• Swift5.9からのif式/switch式
• 式、文、評価
• Swiftの4種類の式
• Swiftの3種類の文
• 式を中心にプログラムを構成する
• 文を中心にプログラムを構成する
• 式と文を比較し、それぞれの使い所を考える

本トークでは、ADPのユーザに割り当てる「役割」と権限に焦点を当てます。

ADPには、Admin / App Manager / Developer など7種類の「役割」がありますが、適切な割り当て方については余り論じられてきませんでした。

Appleは「役割」に紐づく権限仕様を公開していますが、どう割り当てるべきかのガイドラインはありません。そのためか、「できることが一番多い Admin で招待して貰っている」「依頼されるまま App Manager で招待している」といったように、何となく割り当てる運用が多い印象です。

しかし、過大な権限はリスクを増大させます。例えば、カスタムApp開発で社外メンバーに App Manager を割り当てると情報漏洩のリスクが高まります。また、委託先に Admin や Finance を割り当てると全アプリの情報を見せてしまうことになります。ADPに招待されるデベロッパー視点でも、必要以上に強力な権限は持ちたくないでしょう。

このトークでは、そうしたリスクを避けつつ、開発プロジェクトの円滑な進行を妨げないADPの権限設計について解説します。企業規模や開発体制に合わせたお勧めの「役割」割り当てモデルもご紹介します。

Predicateは、与えられた入力値に対して真/偽のテストを行うために使用される論理条件です。Core Data(もちろんSwiftDataも)、Spotlight、iCloud File Search、HealthKit、EventKitなどを使ったことがあるなら、きっとPredicateに馴染みがあるでしょう。

これまではNSPredicateが活躍してきましたが、時間が経つにつれ、NSPredicateを使う際に、特にSwiftエコシステムを中心とする場合、時代遅れと感じる点が増えてきました。こういった点を改善するため、昨年FoundationにSwift Predicateが新たに加わりました。さらに、マクロの導入により、#Predicateを使って新しいPredicateを構築できるようになりました。

NSPredicateと比較して、Swift Predicateには以下のような利点があります：

• 型安全
• Swift型に利用可能
• @Sendableに準拠
• 比較的シンプルな構文
• 自動補完（文字列への過度な依存がなくなる）
• Codableとのシームレスな連携

このトークでは、これらの利点をもとに、実際の例と活用方法を話していきます。また、まだ絶賛開発中のものであるため、その制限や将来に向けた展望についても触れます〜

Swift Concurrency が登場して以来、私が所属するプロジェクトはasync/awaitの便利さに惹かれ、積極的に非同期処理を取り入れていました。
しかし、データ競合なんてものは考えずに利用していたため、Strict Concurrency Checking対応を進めようとすると大量の警告文が立ちはだかります。
修正範囲は、データ競合が起こりうる箇所全てです。古いコードも容赦なく警告されます。

これは、全て直すべきでしょうか？

答えは様々だと思いますが、私たちのプロジェクトではサービス案件への影響を考慮して、今すぐ直さなくても良いと判断しました。

本トークでは、データ競合を許容したStrict Concurrency Checking対応について、私が取り組んだ事案をもとにお話しします。
完璧を求めないStrict Concurrency Checking対応として参考になればと思います。

主な内容は以下の通りです。

• データ競合を完璧に防ぐ必要がないと判断した理由
• データ競合を許容したStrict Concurrency Checking対応
• サービス開発に影響を出させないStrict Concurrency Checking対応案

SwiftUIとJetpack Composeは、共に2019年に発表された宣言的UIフレームワークです。これらはViewの構成方法や状態管理、副作用の表現など、多岐にわたる差異を持ちながらも "宣言的UI" という同じパラダイムを共有しています。

私たちが開発する『家計簿プリカ B/43』はAndroid版が当初からフルJetpack Composeアプリである一方、iOS版は2021年のリリース時点で全画面がUIKitベースであったという背景を持ちます。iOS版においてSwiftUIへの移行を進める中で、Android版での経験や知見が生かされる場面も多くありました。例えば、Jetpack ComposeにおけるNavigation componentの存在は、iOS 16におけるNavigationStackの登場以前から ”画面実装と遷移の分離の必要性” を示唆してくれました。

本セッションでは「2つの宣言的UIフレームワークの活用を通じた知見の環流」をテーマに、私たちがJetpack Composeから得られた学びをSwiftUIにおいてどう活かしたのか、以下の観点に絞って紹介していきます。

・State hoistingの考え方とプレビューの効率的な活用
・画面実装と遷移の分離の必要性
・複雑性の高いUI要素の実装における思考法

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」は、12言語で63の地域に配信されており、海外ユーザーが約8割を占めています。

グローバルユーザーに愛されるサービスになるためには、ローカライゼーションが非常に重要な課題です。
ローカライゼーションには翻訳だけでなく、各地域のフォーマットに沿った情報の表示やUIのデザインも含まれます。
このセッションでは、Swiftでの実装にフォーカスを当てた多言語対応の方法を詳しく紹介します。

紹介トピック

• 翻訳管理プラットフォーム「Lokalise」とiOSアプリへの連携の仕組み
• SwiftGenを使ったテキストリソースの安全な参照方法
• 日付・時刻のフォーマットの実装
• 数字・順位のフォーマットの実装
• UI実装の工夫と品質担保の方法

このセッションが、世界中のユーザーにシームレスにアプリを届けたい方のお役に立てれば幸いです！

問題提起:
アプリのローカライズは、多言語対応を実現するために必要不可欠なステップですが、対応するには多大なコストが伴います。
数十種類の言語に手動で対応することになれば、小さなアプリでも翻訳作業に数時間から数日、大型のアプリであればさらに膨大な労力がかかります。

解決策の提案:

1. Xcode 15で新たに導入されたxcstrings
2. Google TranslationやDeepLなどの翻訳用API
3. 翻訳自動化スクリプト
   この３つを活用して、アプリのローカライズプロセスを完全に自動化する方法について紹介します。

トークの概要:

1. 手動でローカライズを行うことによって発生するリアルなコストを説明
2. xcstringsの仕組み、従来のLocalizable.stringsとの比較
3. 自動化スクリプトの概要説明
4. プロジェクトに翻訳自動化ライブラリを組み込む方法の説明
5. 自動翻訳のライブデモ

SwiftUIが登場してから数年経ちました。リリース当初より機能がかなり充実してきているので、SwiftUIの導入を検討するプロダクトも多くなってきたのではないでしょうか？
今回、自社のプロダクトでUIKitを用いていたプロジェクトにSwiftUIを導入したので、その経緯と導入に際して困ったこと等をお話しできればと思います。

・ UIKitの実装で解決したい問題点
・ 導入にあたって考えたこと
・ 移行の段階について
・ アーキテクチャ
・ チームメンバーの移行に対する温度感
・ データの持ち方
・ 導入にあたって困ったこと
・ OSバージョンによるSwiftUIの機能差異
・ これから目指すこと

このセッションを通じて、既存プロダクトでSwiftUIの導入を検討している方へ情報を共有できればと思います！

プロダクトにおいて、共通デザインが定義されていないために、頻繁に利用されるボタンなどのUIを画面ごとに独自に作成していませんか？

メタバースプラットフォームclusterではiOS、Android、Web、macOS、Windows、Questといった複数のプラットフォームで展開しています。
サービスの成長と共に新しいデザインも増えてくる中、画面ごとに微妙に異なったボタンなどのUIデザインが散見されるようになりました。その結果、エンジニアが独断で共通化したコンポーネントを実装したり、各画面で同じような実装することも増えていました。

この問題を解決するため、各プラットフォーム共通のUIを「UI Component」という概念で統一してバラつきのあったコンポーネントをデザイナーとエンジニアで協力しながら整備していきました。
デザインシステム上で統一されたコンポーネントが定義されることで、デザイナーは管理や指定がしやすくなり、エンジニアも実装が容易になり、デザイントークンに対する認識齟齬も防げるようになりました。

このセッションでは、私たちが行った以下の取り組みについて紹介します。

• 共通コンポーネントをどう整備していったか
• 整備したコンポーネントを浸透させる
• あえて共通化しなかったUI