トーク

インライン展開は、iOSアプリのパフォーマンスを向上させるための重要な最適化技術です。
このトークでは、インライン展開が実際にどのように行われているのかを、アーティファクトや中間言語を通じて詳しく解析します。

また、実際に運用されているコードを用いて、インライン展開の効果とその背後にあるメカニズムを具体的に解説します。
あまり親しみがない機能かもしれません。このトークを通じてインライン展開の基本的な理解と実践的な知識を得て、ご自身のアプリに組み込むきっかけとなれば幸いです。

Predicate は true/false を返す論理条件です。
コレクションのフィルタ、検索に利用されます。SwiftDataのフィルタにも利用されています。

このPredicate論理条件の中身は &&, ||, =, <= など見慣れた論理式や、 allSatisfy() のようなシーケンスオペレーションが使えるため、ただの true/false を返すメソッドやクロージャのように思えてしまいます。
しかし、これをメソッドだと思って扱っていると思わぬ形でランタイムエラーに遭遇します。

このトークでは、PredicateマクロでPredicateの論理条件を書く時にはまった罠、注意点をお話しします。

[はじめに]
UIKitで作られた画面や既存機能をSwiftUI化する際に、
GeometryReaderや描画パフォーマンス、イベントの伝搬・連携、状態管理などで困った経験はありませんか？
この問題と正面からぶつかり、誰でも再現可能なシンプルなI/Fでコンポーネント化した経験を踏まえたお話をさせてください。
※Introspectなどのライブラリは未使用

[背景]
10年続く弊社プロダクトでは、InterfaceBuilderを使ったフリックカードの構成が限界を迎えていました。
「施策に追従するための実装コスト」や「AIを使った最適化」のハードルはエベレスト級で、
若手の多い弊チームでは尚更難易度が高いものとなっていました。

[主題]
このトークセッションでは、主に次の2点についてお話しします。
①設計について

• UIKitからSwiftUIへのリプレイス
• SwiftUIの思想に合わせたシンプルなI/F設計
• 複雑なインタラクション管理
  これを踏まえて「若手でも再現可能な状態」にするために、どのように実装したのか

②SwiftUIについて

• 描画パフォーマンスが落ちないように工夫したこと
• 親Viewと子Viewのイベント連携

などなど..数ヶ月以上に渡る壮絶なバトルについて、色濃くお話しできたらと思います。
よろしくお願いいたします！

アプリを取り巻く要件の中にはUIデザイン、機能仕様、リリース要件などさまざまなものがあります。この中でもリリース要件は選択肢が少ないため、自由度がかなり低いと言えます。

そんなリリース要件の中で、限定されたユーザーにだけアプリを配布し、利用できる仕組みが必要な場合があります。そんな要件を受けたときに、どのような選択肢があるでしょうか？
Firebase App Distribution、TestFlight、Apple Business Manager など、さまざまな手法がありますが、私の所属するチームでは、その中でも Unlisted App Distribution を採用しました。

このセッションでは、数ある手法の中からUnlisted App Distributionを選択するに至った経緯と、他の配信方法との比較検討の結果についてお話しします。また、Unlisted App Distributionを選択した際に気をつけるべき点についても詳しく説明します。

みなさん、認証機能のエラーハンドリングはどのように行っていますか？
近年のアプリの認証機能は、自社のサーバーだけでなく、Firebase Authorizationなどの認証系SaaSを活用していたり、Apple、Google、LINEといったSNSアカウントを利用した外部システムと連携したものがほとんどだと思います。

それに伴い、私たちがハンドリングしなければならないエラーの種類はどんどん増えており、

• ユーザーに適切なエラーダイアログを出すことが困難
• エンジニアの不具合の原因特定の難易度が高い

といった課題があります。

本トークでは、タップルが認証機能を刷新する中でおよそ140ものエラーを分類し向き合った経験をもとに、
上の句、下の句を扱う百人一首のように

• 「エラーコード」に対してどんな「エラーダイアログ」を出すべきか
• 「ユーザーからの問い合わせ」に対してどんな「回答」をすべきか

を “問題解決までのスピード” に着目してお話しします。

本トークを通じて、いままで雰囲気で扱っていたエラー分類への解像度が上がることで、
皆さんのサービスでユーザーが自己解決できる認証エラーが増え、認証の突破率やユーザーの獲得数が増加すること、そして今まで時間を使っていた不具合調査の時間が短縮されることを目指します。

手塩にかけて育てたミュージックライブラリがぶっ壊れた経験はありますか？私はあります。

5年前、OSX Catalinaの登場時にiTunesが廃止され機能ごとにアプリが分かれました。
その後、新しいミュージックアプリでは様々な問題が起こりました。

• アルバムアートワークが消えた
• 読み仮名のコピーができない
• ジャンルが勝手に書き換わる

(※全部筆者が経験したことです)

万単位にのぼる楽曲を1個1個精査して正しい状態に復旧するのは当然ながら非現実的です。
更にミュージックアプリの使い勝手の悪さも相まって泣き寝入りを余儀なくされました。

ですが、そこに救世主が現れました。そう、 ScriptingBridge です。
しかし ScriptingBridge はObjective-CがベースなのでSwiftで扱うには一工夫が必要です。

本セッションでは、macで他アプリケーションと連携するための仕組みである ScriptingBridge をSwiftのみで扱う方法と、それを使ってミュージックライブラリから楽曲情報を取得・編集する方法を紹介します。

また、壊れた楽曲情報を半自動で復旧する為のガワとしてNowPlayingアプリを実装した話をします。

SwiftUIが登場してからおよそ5年が経ちましたが、複雑なレイアウトを表現する場面では、依然としてUICollectionViewが力強い味方です。

特に、Compositional LayoutとDiffable DataSourceの導入により、App Storeのような複雑なレイアウトも簡潔に、かつ容易に実装することが可能になりました。
セクションの順番さえ決まっていれば、その特定のセクションに対してアイテムのグルーピング方法を適切に指定するだけで、複雑なレイアウトを表現することができます。

しかし、セクションが不定の場合はどうでしょうか？たとえば、セクションによっては大きな単体のCellを表示したり、複数のCellを横方向に並べてスクロールさせたいが、その順序がサーバーサイドの都合により変化するような場合です。
UICollectionViewCompositionalLayoutでは、セクションに対して直接表現方法を指定するため、順序が不定では実現が難しいかと思われがちです。
しかし、セクションのenumに一工夫することで、このような動的なレイアウト生成も実現することができました。

本セッションでは、このように「受け取るデータの種類によってCellを自由に出し分ける必要がある場面」での、我々の成功パターンについてお話しします。

iOSアプリで動画を作成したことはありますか？
難しそうに思える画像生成や動画生成も順を追って理解していくことで意外とできるようになるものです

このトークではクライアント側での動画生成を試してみた経緯とそこで学んだ実際の動画の演出などについてお話しします。

• なぜクライアント側で動画生成することになったのか？
• AVAssetWriterによる動画生成の流れ
• 動画で使われてる効果（移動・回転・拡大縮小・ドロップシャドウ・ブラー・フェードイン・アウト）の実装

このトークを通じて、AVAssetWriterを使った簡単な動画生成の流れとCore Graphicsを使ったレンダリングの基本を学ぶことができます。

一般的なユースケースであればSwiftLintやSwiftFormatなどにコントリビュートするのが良いと思われるが、プロジェクト固有のルールやガイドラインとしてこうしたい、こう揃えておきたいというケースもあるはずです。このトークではそんな時に固有のLinterやFormatterをどう実現するのが良いかを追っていきます。

iPhone / iPad Proに搭載されているLiDARセンサを利用したリアルタイムスキャンにより、お家の間取り図を簡単に作成できるRoomPlanはもう触ってみましたか？
LiDARを利用した3Dスキャンは、すでに様々なデベロッパーよりApp Storeで提供されていますが、
WWDC2022においてAppleが提案した新しいSwiftAPIであるRoomPlanは、膨大な情報量を保持するスキャン結果から、非常にシンプルに壁、床、そして家具を再構築できます。

このセッションでは

• RoomPlan APIことはじめ
• RoomPlan の簡単な仕組み
• RoomPlan で作成した3Dオブジェクトの活用

を中心にiOSを彩るAR環境の一端をお話していきます。

類似の3Dオブジェクトの構築技術であるフォトグラメトリを利用したObject Captureとの比較や、LiDARセンサより得られるデータの取得、開発の中で困った点や、Reality ConverterやReality Composerとの連携について共有していきます。

Apple Vision ProおよびvisionOSが登場して早一年が経ちました。
毎日SwiftUIを触っているであろうiOSエンジニアの皆さんにとって、visionOS向けのUI開発で陥りがちなポイントを紹介します。

visionOSは皆さんが慣れ親しんだSwiftUIフレームワークを使用してUI開発が可能であり、基本的にはiOSやiPad OSアプリケーションの開発と大きな違いはありません。
しかし、visionOS向けに新しく追加されたUIコンポーネントであるOrnamentや、普段使わないWindowsやVolumesの概念などはまだ知らない方も多いでしょう。

そこで本セッションでは、visionOS向けのアプリケーションを開発する際に気を付けるべきポイントを以下のトピックに分けて詳しく紹介します。

・ Window向けUI構築で意識する点
　Windowの特性と、それに応じたUIの配置やデザインのポイントを解説します。

・ Ornamentについて
　Ornamentコンポーネントの使い方や、利用シーンについて具体例を交えて紹介します。

・ visionOSでは必須のHoverEffectについて
　HoverEffectの重要性と、適切な使用方法について実例を交えながら説明します。

Swift Concurrency が初めて発表されてから約3年が経過しました。特に非同期処理の実装においては Swift Concurrency を選択することが一般的になってきました。

Swift Concurrency 登場以前から開発されているアプリの場合、非同期処理や UI 更新のためのデータバインディング目的で RxSwift を使うケースが多く、歴史の長いコードベースほど RxSwift への依存が大きくなっています。このため、機能開発と並行して徐々に Swift Concurrency へ置き換えていく、といったケースも多いのではないでしょうか。

本トークでは、既存の RxSwift で実装された箇所との共存を図りながら Swift Concurrency へ置き換えていく過程で気をつけるべき点や苦労した点について私の経験を交えてご紹介します。来るべき Swift 6 に備えて今からできる対応についてもご紹介します。

本トークでご紹介する主な内容は次のとおりです。

• RxSwift で実装された処理と Swift Concurrency で実装された処理との繋ぎこみ
• テストコードの修正で遭遇した問題
• 漸進的な移行を実現するために Protocol を活用する
• Sendable チェックとの戦い

AppleのVision Frameworkは、機械学習とコンピュータビジョンの強力なツールです。このプロポーザルでは、今ではなくてはならない存在となり、日々お世話になっているVison Freameworkの進化の軌跡をたどり、現在の機能と利用事例を探り、将来の可能性について考察します。

2017年にWWDCで初めて発表されたVision Frameworkは、iOSデバイス上での画像認識と分析を簡単にすることを目的としています。このフレームワークは、顔検出、テキスト検出、オブジェクト追跡など、多岐にわたる機能を提供し、アプリ開発者がユーザー体験を向上させるための新しい道を開きました。

Vision Frameworkは、リアルタイムでの画像処理を可能とし、Core MLとの統合により、カスタム機械学習モデルを活用して、より高度な画像分析を実現しています。

このプロポーザルでは、その歴史を振り返り、現在の実用性を評価し、さらにWWDC2024で発表されるであろう新技術についても触れ、フレームワークを最大限に活用するための具体的な方法を紹介します。

みなさんは日常的にショートカットアプリを活用していますか？
私は楽をするためにショートカットを駆使して、さまざまな自動化を行っています。

ショートカットアプリにあなたのアプリを連携させるためには、App Intentsを利用する必要があります。
App Intentsを活用することで、ショートカットアプリだけでなく、SpotlightやSiriからの提案などの場所にも、あなたのアプリが表示されるようになり、アプリの起動導線が増加します。
さらに、Interactive Widgetsやアクションボタン等からアプリの機能が呼び出せることで、未対応の他のアプリと差別化でき、ユーザーにとって欠かせないアプリになるかもしれません。

このトークでは、App Intentsを最大限に活用してアプリのエンゲージメントを向上させるための具体的な知識や方法を紹介します。

・App Intentsの概要解説
・SpotlightやSiriなどのOSの機能との連携について
・Interactive WidgetsなどのApp Intentsの活用方法

また、このような機能の実装をスムーズに行うために、日頃の実装で気をつけるべきことなどについてもお話しします。

みなさんのアプリの可能性を広げ、ユーザーに愛されるアプリ作りの一助になればと思います。

iOSアプリ開発のチュートリアルや入門書は多く存在しており、学校の授業で扱われることもあります。しかし一方で、実際のアプリ開発の業務では、より多くの知識が求められます。このギャップに初学者がとまどうことも少なくありません。

このトークでは、初学者が業務レベルに到達するには何が求められるのか、いくつかのポイントについて具体的にお話しします。初学者への学習の方向性を示すとともに、中級〜上級者にも初学者が感じるギャップを捉える機会になればと考えています。より俯瞰的な内容は、パンフレット記事をご覧ください。

・UIフレームワーク（UIKit、SwiftUI）：どのくらい使われているのか、どちらを学ぶべきか
・LinterやFormatter：なぜこれらを導入する必要があるのか
・プロジェクト構成、パッケージ管理（SwiftPMなど）：プロジェクト構成で何を考えておくのか
・デザインや設計のガイドライン（HIGなど）：何を知っておくべきか、ガイドラインの読みかた

UIKit から SwiftUI への移行、進んでいますか？
私が開発に携わっているアプリでは、画面内の一部のコンポーネントにのみ SwiftUI を利用しており、現在画面全体の SwiftUI 移行を検討しています。
すぐにも移行を進めたいところですが、そのためにはユーザの行動ログを収集するためのインプレッショントラッキング基盤が必要不可欠です。

基盤実装には、分析要件を満たすための I/F 設計・ユーザ体験を損なわないためのパフォーマンス・OSバージョンごとの品質担保・デバッグ容易性など考慮すべき観点がいくつもあります。
本トークでは、インプレッショントラッキング基盤を実現する上での UIKit と SwiftUI の違いや、これらの観点に対するアプローチについてお伝えします。

みなさん、Meta社（旧Facebook社）が開発したモバイルアプリ開発のためのデバッグツール「Flipper」をご存知でしょうか。

Flipperはデスクトップアプリを通じて様々な情報を取得したり操作を行ったりと、幅広くデバッグを支援してくれる便利なツールです。
類似のデバッグツールとしては、HTTPプロキシを立てて端末の通信をキャプチャし、リクエストやレスポンスの内容を参照・改変するCharlesが有名かと思いますが、FlipperにはCharlesにはないカスタムプラグイン機能が存在します。自分たちのアプリの要件に合わせたカスタムプラグインを作成することで、バグ調査や開発効率の改善に役立てることができます。

このトークでは、Flipperの基本的な解説からユースケース、カスタムプラグインの作成方法、活用事例までを以下の流れに沿って、ソースコードと共に解説していきます。

• Flipperで出来ること、出来ないこと
• カスタムプラグインの作成方法
• iOSアプリへの組み込み
• Mirrativで利用しているカスタムプラグインの紹介
  • WebSocketベースのPub/Subライブラリのデバッグ
  • Unityとの双方向通信のデバッグ

このトークを通じて、みなさんのモバイルデバッグの選択肢が広がれば幸いです。

弊社では、モジュール分割による影響範囲の限定化とともに、UIViewControllerから呼び出すサブビューの位置付けでSwiftUIを利用しています。
最大限SwiftUIの力を活用できているとは言えず、UIViewControllerから呼び出すことでオーバーヘッドがあるのも事実ですが、UIKitやStoryboard中心の開発を行っていた頃と比較して開発体験の向上が見られるようになりました。

本トークでは、UIKitベースのプロジェクトにおいてSwiftUIを適用したいと迷っている方向けに、具体的な事例を交えながら以下のポイントについて順を追って解説します。

• コードベースの課題認識とゴール設定
  • SwiftUIをどこまで適用するか
• 施策実装と並行し隙間時間でコード改善する進め方
• 修正による影響範囲を明確化、限定化するためのモジュール分割の指針立て

突然ですが、みなさんが開発しているアプリで一番古くからある画面はどこですか？

マッチングアプリ『タップル』は今年でリリースから10周年を迎え、Swiftのアップデートに伴ってその姿形を変えてきた歴史があります。
iOS業界の中でも古いプロダクトになりつつあり、時代の流れとは裏腹に、何年もの間メンテナンスされてこなかった実装が健在しています。

しかし、これらの実装はSwift 6.0の登場により変遷の時を迎えるかもしれません。
そこで本セッションでは実録と称して、IBベースの画面で作られていたタブ直下の画面をフルSwiftUI化し、さらにSwift 6.0対応までのリプレイスの記録を以下の流れに沿って解説します。

• IBからSwiftUIへの移行
• リアーキテクチャ（RxSwiftからSwift Concurrencyへの移行）
• そしてSwift 6.0対応へ

共に古き悪しきコードを討伐していきましょう！

「（舞台上でしゃがみながら）ログビューアのUI/UXについて、マジで今日全員で考えたくて」

os.Logger という、iOS 14.0から使えるロギングのAPIがあります。
print よりもログに特化しており、使っている方も多いと思います。

私はOSログを確認できるSwiftUIのビューをOSSで公開しています。
わずか1行でiOSアプリ上にログビューアを表示できます。

Xcode 15から、OSログビューアが一新されました。
UI/UXについて、できる限りそれに近づけようとしています。

しかし難しい…！
macOSアプリであるXcodeのUI/UXを、iOSアプリ上でどう表現するか。

「検索バーでフィルタリングを実現するのは難しいから、文字列検索と分けて用意しよう」
「スマホはパソコンと比べて画面が小さいので、折り返しを多用するのもよくないよな」

など工夫しました。

本トークでは、私がログビューアのUI/UXをどう考えて設計したかと、改善の余地について紹介します。

もくじ

• OSログの出力と取得
• 自作ログビューアのUI/UX解説
• ログビューアのUI/UXを全員で考えよう

「どうでもいい正解を愛するよりも、面白そうなUI/UXを愛せよ」
全員で一緒に、よりよいログビューアのUI/UXを追求しましょう！