トーク

みなさんはテストをする際に DI や Mock を使いますか？それにはライブラリやフレームワークを使いますか？
実は私は DI も Mock も使いますがそれにライブラリとフレームワークはあえて使いません。ライブラリやフレームワークを使わないことでコードの声により敏感になれるからです。

この発表では DI や Mock の基本からライブラリ・フレームワークを使うメリットとデメリットを説明し、ライブラリ・フレームワークに頼らない開発方法を紹介します。あなたもコードの声に耳を傾けてみませんか？

来るべき Swift Macro に備えて Swift の構文木について学びましょう。この発表の前半では Swift Macro を定義する際に理解が必要な「構文木」とは何かを初心者向けに説明します。後半では構文木の活用方法として、マクロの定義や、静的解析・フォーマッター・コード生成のやり方を説明します。ぜひこの機会に構文木を学び、Swift Macro に備えつつ引き出しを増やしましょう。

9年前から開発している弊社のiOSアプリは大規模なリファクタリングの経験なく、今まで開発してきました。現代のビジネス環境では、高品質でメンテナンス性の高いアプリケーションの開発と維持が求められています。そのようなニーズを満たすために、わたしたちのチームはVIPERアーキテクチャを今年から採用しました。このセッションでは、どのようにアーキテクチャを選び、どのような実践をしているかを紹介します。

この発表は三部構成となっています。
第一部：なぜVIPERを選択したのか？
第二部：VIPERアーキテクチャの実践
第三部：実践で得られた学び

この発表が皆様のチームが未来の開発チャレンジに向けて最適なアーキテクチャを選択し実践するための一助となれば幸いです。

Xcode Previewの登場により、SwiftUIで作成したUIパーツをXcode上でプレビューすることが簡単になりました。UIパーツに渡すデータパターンを複数用意すればUIパーツの実装に問題がないか視覚的にかつ網羅的にチェックしやすくなりました。
Xcode Previewの力はそれだけに留まりません。UIパーツを画像ファイルとして出力することでプログラムの入力情報として扱うことができます。これによってUIパーツのデザインが変更されたことを目で確認することもできますし、CIを使ってデザイン変更に関する不具合を検知するための自動化に繋げられます。
本セッションではSwiftUIベースのサンプルアプリを使ってCIによるデザイン変更の検知がどのように実現されるかをお見せします。

ZOZOでは、GitHub Copilotを全社へ導入しました。iOSやAndroidからSREまで様々な領域のエンジニアがGitHub Copilotを使用して開発しています。本セッションでは、GitHub CopilotのZOZOでの活用事例を時間の限り紹介します！

例えばiOSアプリ開発では、UIKitなどのフレームワークの使用方法の提示、新規画面作成時に必要なコードの提案、API設計書からSwiftのコードへの書き起こし、既存のコードのリファクタリングなどのタスクでCopilotがどのように効果を発揮しているかを紹介していきます。

加えて、GitHub Copilotを活用していくためのtipsを紹介することで、開発作業をより効果的で効率的なものにする一助となればと思います。

• GitHub Copilotの概要
• 導入背景と導入のプロセス
• ZOZOでの活用事例の紹介

SwiftUIを利用したアプリが増えている中、開発中に以下のように思ったことがある方は多いのではないでしょうか？

• 状態管理や画面遷移のベストプラクティスがわからない
• Observable(Object)が肥大化しないように分割することが難しい
• Swift Concurrencyをアプリで使うことが難しい
• テスタブルにするために増え続けているprotocolに身に覚えがある
• 設計はテスタブルにできたがテストを書くことが億劫

TCAは状態管理のためのツールと捉えられがちですが、TCAを正しく理解して利用すれば、SwiftUIを使った開発にありがちだと思われる上記のような課題を意識することなく、機能開発に集中できます。

本トークでは、課題ごとにTCAを一つの解決策として紹介することで、明日からTCAの導入を検討できる状態になることを目指します。

日付・時刻・時間・数値・測定値・名前などの情報を、ローカライズ済の String との間で変換してくれる Formatter。有名なのは DateFormatter・NumberFormatter でしょうか。

iOSDC Japan 2021 では、当時のすべての Formatter を紹介しました。あれから2年、今年は iOS 15+ で使用できる FormatStyle を使用した formatted メソッドを紹介します。これは Formatter の強力な機能はそのままに、自分でインスタンスを作る必要がなく、より Swift らしく書け、さらに iOS 17 ではパフォーマンスも向上します。

FormatStyle の使い方はまだまだ Web 検索での情報が乏しいです。このトークで FormatStyle の使い方をマスターし、従来の Formatter から移行しましょう。

ABEMAでは、iOSアプリとAndroidアプリのアーキテクチャの統一を図っているだけでなく、コード自体も共通化されている状態を目指して一部実装にKotlin Multiplatformを採用しています。これらの取り組みの中で、両プラットフォームで共通して採用できるアーキテクチャとはどのようなものか、どの実装が共通化できてどこができないのかなど、OSの境界を跨いで多くの議論を行ってきました。

このトークでは、こうした議論を経てABEMAがモバイルアプリのアーキテクチャをどのように捉え、検討し、運用していくことになったのかをご説明します。また、議論によって整理された考え方の中心的な部分を、大規模なアプリから開発が始まったばかりのシンプルなアプリまで多くのアプリに応用できるように体系立ててご紹介します。

アーキテクチャにまつわる多くの人の多くの疑問に答えられるトークを目指します。

Swift UIの登場によって、私たちはデータの画面反映に関するロジックの管理から解放されました。

これに加え、複数のAPI結果を画面ごとのStateに変換するまでの処理を、サーバーサイドにまるっと移譲することで、
アプリは最適なUXの提供に専念できるだけでなく、ストア審査やリリースから独立した変更が可能になります。

本トークでは、AirbnbやLyftなどの海外企業で導入されているServer-Driven UI アーキテクチャについて、下記について深く掘り下げてお話しします。

• Server-Driven UIは何を解決するものか？
• 先行事例、各社がどういった形で実現しているか？
• タップルでのSwiftUIとBackends for Frontends（BFF）を活用した取り組みと運用
• 運用の中で得られたメリット

現在、iOS1人・Android2人の少数チームで新規動画配信アプリを開発しています。
技術選定やアプリのアーキテクチャ設計に際しての工夫点やハマり所、そしてSwiftUI, TCA, KMMを活用した開発Tipsについてお話します。

これから新規アプリ開発を予定している方々にとって、技術選定やアーキテクチャ設計の参考としていただければ幸いです。

キーワード：
・iOS Deployment Target 16.0+での新規iOSアプリ開発
・swift-composable-architecture (TCA)
・Kotlin Multiplatform Mobile (KMM)
・kotlin-inject
・Apple TV対応も踏まえたSPMでのマルチモジュール化
・多言語対応, Localize
・iOS ⇔ Androidの技術トランスファー

ネイティブアプリからWeb APIを利用するとき、なんらかの認証・認可の仕組みが必要になることがほとんどです。こんなとき典型的なアイデアは、OAuth 2で認可すること。でもOAuth 2って、10年も前に標準化された規格だし、RFCもたくさんあるし、なんだかとっつきにくいですよね。
ということで本トークでは、OAuth 2がどういうもので、どういう問題を解決し、あるいは解決しないのか、その全てを説明します。特にネイティブアプリにはアプリならではのポイントがあり、正しく実装することでセキュリティリスクを軽減させられます。
トークの内容は、自社のアプリの認証をOAuth 2に移行させるため、認可サーバーとリソースサーバー、自社アプリ向けのSwift SDK、そしてアプリの実装まで手がけた私の経験に基づきます。

Hapticsとは、iPhoneを操作しているときに「ポコッ」と振動するアレです（「ポポポポ」とか「ブーーーン」とかもあります）。
UXを向上させたりアプリのらしさを演出したりできる強力なフィードバックツールですが、その扱い方は公式ドキュメントを軽く読むだけでは理解できないほど難解です。
このトークを聞いて、あなたのアプリをhaptics付きのより魅力的なものにしましょう。

このトークでは以下のことをお話をします:

• CoreHapticsの使い方
• Hapticsを構成するパラメータの解説
• 動的なhaptics/オーディオ付きのhaptics
• Hapticsのベストプラクティス

このトークを聞くと以下のことができるようになります:

• 複雑なhapticsを実装できる
• Hapticsを導入すべき箇所がわかる
• デザイナーさんとの協業方法がわかる

昨年のiOSDC JapanではARKit 6のLocation Anchorをはじめとする“Visual Positioning Service/System”のVPSの世界を紹介しました。
その後、Geospatial Creatorが登場したことにより、VPSを生かしたコンテンツ作りがより身近に、よりお手軽になりました！
文字通り街中をキャンバスとして、現実世界とバーチャルな世界を統合できます！

VPSの最新動向にあわせて、Geospatial Creatorの基礎からVPSコンテンツの具体的な制作方法までお伝えします。百聞は一“体験”にしかずなので、iOSDC Japanの会期中は、実際に会場付近などでGeospatial Creatorを使ったVPSコンテンツをお試しいただけます！

iOSDC Japan 2020、2021で発表してきた『iOSではじめるWebAR』シリーズの最新版です！

先日のWWDC23でVision Proが発表されましたが、あわせてSafariのレンダリングエンジンであるWebKitがWebXR Device APIに対応することも公開情報として発表されました。

これまでSafariがWebXR Device APIへの対応を明言してこなかったことも、3Dモデルを表示するAR Quick Lookやmodel要素もすべてはこのVision Proを見据えてのものだったと今ならわかります。

Safariが歩んできたWebXRのこれまでと現状、そしてきたるべきSpatial Webの世界を見据え、想定されるWebXRのこれからをお伝えします。

Swift Concurrencyは、強力な型システムによって、同時並行処理時のデータ競合防止の静的な保証を目標としています。
しかし、クラッシュの発生や期待したスレッドで処理が実行されないなど、実際はさまざまな問題が起きます。これは、デフォルトではSwift6未満で完全なSendabilityチェックが行われない、既存のシステム(DispatchQueueなど)に対してコンパイラが静的に安全性を保証できない、などの原因が考えられます。
そこで、これを補完するための多くのツールが、公式から提供されています。
本トークでは、
「事前に防ぐ」
「問題をすぐに検知する」
「原因を調査する」
という3つのポイントで活用できる、さまざまなツールについて見ていきます。
Swift Concurrencyをより安全に利用し、既存のコードとよりスムーズに連携するためにできることを一緒に整理してみませんか？

KotlinMultiplatformForMobileの導入によりアプリ開発者はビジネスロジックの差異という問題を乗り越える事が出来ましたが、一方で独自の問題も待ち構えています。
KMM内でerrorがthrowされそれがKMM内で適切にハンドリングされなかった場合にアプリはクラッシュし、おまけにそのクラッシュはkonan::abort()という一つのクラッシュに纏められてレポートされます。
どの処理でクラッシュしたか詳細なStackTraceは提供さておらず、この状態からクラッシュを解消するための道筋を立てる事は困難でしょう。
本セッションではそのような原因不明な闇のクラッシュに対し、起きる前後それぞれで出来ることを考えていきます。

40分拡大版ではそも何故Kotlin側でerrorがハンドリングされない設計になってしまうのか、検査例外に関する歴史を踏まえた考察もしていきます。

SwiftUIでTCAを効率的に適用するためのモジュール化の原則を紹介します。

iOSプロジェクトの規模が大きくなるにつれて、複雑さは指数関数的に増加します。 この複雑さをコントロールするために、高い凝集力と低い結合を持つモジュールの編成方法を紹介します。
このトークでは、Github上のリポジトリを検索するサンプルアプリでTCAプロジェクトをモジュラー化するための実践的な方法について説明します。

堅牢なモジュールを構築するための原則について説明します。

• 高い結合力 低い結合力
• 懸念事項の分離
• 依存関係の逆転
• テスト容易性

対象者

• SwiftUIを使用しているチーム
• TCAの採用を検討しているチーム

本プレゼンテーションでは、以下の内容に焦点を当てます。

• TCAプロジェクトの長所と短所
• モジュール化の利点と注意点
• 堅牢なモジュール構築のための原則

AppleのGPU向けプログラミングインターフェースMetalと、画像処理で一般に用いられる形態学（Morphology）を駆使し、麻雀牌の画像からその種類を見分けることに挑戦します。

「分類」と聞くと、機械学習や学習データが必要なのでは？と思う方もいるかもしれませんが、今回はあくまで画像処理だけのアプローチにこだわります。 (学習データなどは使いませんが、いくつかの制約を課します。)

宜しくお願いします。

(本セッションを聞いて下さる方へ: 麻雀のルールを知らなくても全く問題ありません。)

RunCatはMacのメニューバーにCPU使用率に応じて走るネコを表示できる個人開発のユーティリティアプリです。
開発/運用が5年目となるRunCatの歴史を振り返りつつ、技術的な課題や工夫、知見を詳解します。

・OSごとに変わるメニューバーの仕様
・ランナーの作り方とリソース節約の工夫
・アプリ内課金のProduct IDにまつわる失敗
・システム情報の取得に関する苦労
・アプリ自体のCPU使用率を下げる工夫
・バージョンアップによるマイグレーションの難しさ
・ユーザーからの不具合報告対応のコストを減らす工夫
・開発者向け機能から生まれた自作ランナー登録機能
・無学によるスパゲッティコードとリアーキテクト

などなど、可愛いだけじゃないRunCatの裏側を覗いてみませんか？

SwiftUIが発表されてから5年目に突入し、様々な応用方法がコミュニティに出回っています。
そんな中、便利ではあるものの、SwiftUIの仕組み上よろしくない実装をしているケースを見かけます。
この様な実装をしないために、初心に戻ってSwiftUIの基礎を学び直してみませんか？

このトークは次の様なテーマを取扱い

• Viewが再生成・再描画されるタイミング
• 再描画を減らすポイント: View Identity
• SwiftUIの裏側にあるUIKit

これらのテーマごとに

1. WWDCのセッション等を引用しながら、仕様を確認
2. どのようにコードを書くべきか考察

の2ステップを繰り返す内容になっています。

既にSwiftUIを使っている人でも、このトークで基礎を再確認することで
より描画パフォーマンスの良い書き方や、新しい視点での実装ができるようになることでしょう。