トーク

事業の成長とともにアプリに求められる機能は日々拡張され、その実装は複雑化していきます。サービス拡大に伴いアプリ開発に関わるエンジニアの数も増え、当初の設計や実装では今後の開発・運用に支障をきたすケースもあります。そうした場合、リアーキテクチャなど大規模なリファクタリングによる設計変更が必要となります。

このトークでは、JapanTaxi と GO アプリにおける二度のリアーキテクチャの経験から得られた知見を話します。

・なぜリアーキテクチャを行う必要があったのか
・案件開発と並行して大規模なリファクタリングをどのように進めたのか
・リファクタリングに向けた 2ヶ月におよぶ下準備について
・機械的な作業を自動化し、リファクタリング自体に集中する仕組みの構築
・リファクタリング時のコーディング Tips
・リリースに向けた取り組み

ここ1・2年いろんなサービスで実装されてるライブ配信機能。実装を検討されているサービスも多いのではないのでしょうか？

我が社もそんなビックウェーブにのるべく始まったライブ配信プロジェクトですが、エンジニアはバックエンド2人・iOS2人。
少ないリソース、少ない開発期間でリリースすべく、Clubhouseも使っているagoraというサービスを使用することにしました。

4人の戦士が1ヶ月半でリリースした知見をお話しします。

1. ライブ配信機能一覧と分担
   ・agoraで用意されてる機能
   ・自社で担う部分とagoraに任せる部分
2. コメント機能の設計といろんな使い方
   ・通常コメント
   ・ブロック機能
   ・ギフティング
3. 発生した課題・問題たち
   ・難1 配信開始・配信終了の検知どうするの問題
   ・難2 画面レイアウトの設計複雑すぎ問題
   ・難3 リアルタイムで配信一覧を更新したい問題
4. 小咄 ユーザーの推し機能

「Firestoreの導入を検討しているけど、実際どうなんだろう...？」
「導入事例は、新規アプリとか個人アプリばかりで、大きめのアプリで話はあまりないな...」
と思っているみなさまのためのトークを用意しました。

株式会社mikanでは、2020年夏ごろから9カ月以上の時間を費やし、
英単語アプリmikanのiOS版のクライアント側で使用しているDBを、SQLiteからFirestoreに移行しました。
（現在Androidも移行中です）

このトークでは、9カ月を超えるプロジェクトを振り返り、

そもそもなぜDBの移行が必要だったのか、どんなことに失敗して、どんなことはうまくいって、
同じようなこと企む方々が少しでも僕たちよりもうまくできるようにするためには何を意識すればいいか、という話、
そして、そもそも何故SQLiteを使っていたの？なぜFirestoreを選んだの？実際に使ってみてどう？みたいな部分も赤裸々に話していこうと思います！

• なぜSQLiteからFirestoreへ移行したのか
  • SQLiteが採用された歴史的経緯
  • SQLiteのツラミ
  • Firestoreを採用した理由
• 移行によって変わること
  • スタンドアローン型DB→ネットワーク型DB
  • RDB→KVS
• どのように移行を進めたのか
  • ダブルライト
  • マイグレーション
  • クライアントロジックの移行
• うまく行ったこと
• 難しかったこと
• 実際Firestore使ってみてどう！？
• プロジェクトをやってみての学び・同じことを考えている人へのアドバイス

オーディオのデータは時間に対しての量が多いので何も考えずに波形を表示しようとすると、綺麗に表示されなかったりパフォーマンスが十分に出なかったりメモリを簡単に使い切ってしまったりします。

単に一つの短い数秒のオーディオの波形を表示するだけでも気にすべきことはありますが、大量のファイルの波形を表示したかったりリアルタイムにスムーズなスクロールをしたいとなると、より一層の工夫が必要です。

このトークでは、オーディオ再生アプリを実装した時の知見を元に、場合に応じてオーディオ波形表示をどのように実装すべきかのヒントとなるお話しをします。

以下のような内容を予定しています。

・オーディオデータの仕組みついて
・様々なアプリの波形表示方法を比べてみる
・波形表示のためのオーディオデータの間引き方・扱い方
・パフォーマンスを考慮した波形表示

Network Extensionはあまり使い方が知られていないフレームワークです。
Wi-Fiの設定変更、コンテンツフィルタ、VPNの構成あるいは実装といったiOSのネットワーク機能を拡張するAPIを提供します。

iOSデバイスでパケットキャプチャをする方法は主にCharles ProxyなどのWeb Proxyを利用したツールを使う、仮想ネットワークインターフェースを監視する、Charles for iOSなどのデバイス上でVPNクライアントとして動くツールを使うという３種類があります。

デバイス上で動作するパケットキャプチャを実装するにはNetwork Extensionを使ってVPNクライアントを実装しますが、もともと情報の少ないこのフレームワークの中でもVPNクライアントの実装方法はほとんど情報がありません。
ソフトウェアの性質上、プライバシーの観点からVPNサーバも同じアプリにローカルサーバとして実装することが望ましいですが、そのような例はまず見つからないでしょう。

そこでiOSデバイス上で動くVPNクライアントおよびサーバを実装しパケットキャプチャを行うアプリを実際に作り、パケットキャプチャの方法を説明します。
Web Proxyを使う方法では不可能なUDPパケットのキャプチャができるのでゲームなど主にUDPが使われるアプリの解析もできるのが便利です。
また自分でパケットキャプチャが書けるということは、特定のパケットに対して任意の処理を実行することができるということです。つまり他のアプリの通信内容と連携するツールを作れます。

今回は応用例として、作成したアプリを用いてあるオンライン対戦ゲームの通信を実際に解析し、普通では見えないゲームの状態や他プレイヤーの行動をリアルタイムに監視・追跡するツールを作ってお見せします。

iOSアプリ実装中、「単語の途中で改
行されてしまう…」といった経験はありませんか？
そういったとき、英語の文章であればlineBreakModeに.byWordWrappingを指定してあげれば単語中の改行は起きなくなりますが、日本語の場合は効果がありません。

このセッションでは日本語の文章でも単語中の改行をさせない方法を解説します。

• NSLineBreakModeについて
• 日本語の扱い
• 制御文字について
• どう単語を検出するか？
• MeCabによる形態素解析
• MeCab for Swift Package

開発規模の大きなアプリは、得てしてビルド時間が長くなってしまいがちです。 ビルド時間を改善する手法の1つとして、アプリを複数のモジュールで構成することで部分ビルドを可能にする「マルチモジュール化」を進めているプロジェクトも増えています。

一口にマルチモジュール化といっても様々な分離の仕方がありますが、1機能に関連するいくつかの画面を1つのモジュールとして切り出すことで、その分けられた機能毎に単体ビルドが可能になります。 このモジュールを単体でアプリケーションとして利用できるようにしたのが、開発時の動作確認用のミニアプリです。

これにより、開発途中の画面を確認するのにアプリ全体をビルドする必要がなくなり、動作確認の効率が大いに改善されました。
本セッションでは、このミニアプリの構築にまつわる以下のようなトピックについてお話します。

・単体起動可能なモジュール構成とは
・ミニアプリそのものの仕組みと導入のメリット
・チーム全体で利用してもらうための工夫
・より使いやすい仕組みを目指した諸改善

このトークを聞いて、あなたのプロジェクトでもプレビューサイクルを爆速に改善してみませんか？

みなさんがApp StoreでiOSアプリを探す際には必ずスクリーンショットを見てUIの良し悪しやアプリの機能などのイメージを掴んでからアプリをダウンロードするのではないでしょうか。App StoreのスクリーンショットはiOSアプリを運営していく上で重要な要素です。アプリの対応言語が1言語の場合は、デザイナーが1から丁寧にデザインして仕上げてくれたものを利用することも多いかと思いますが、これが言語の数や対応画面サイズが増えていくと、その必要数が爆発的に増え、対応コストが跳ね上がることになり人手での定期的な更新は難しくなります。

既知の解決策としてfastlaneというツールのsnapshotとframeitを利用することで、ある程度決まった定番のデザインでこのスクリーンショットを自動生成することが出来るのですが、とある理由から私が業務で開発しているアプリ（20カ国・言語以上のApp Storeのローカライズ対応済み）では採用出来ませんでした。それはframeitではRTL(Right-To-Left)言語であるアラビア語などが対応していなかったことや言語毎のフォントの準備やサイズの調整が難しかっためです。

この発表ではApp Store向けのスクリーンショットを多言語化して運用していく上での課題となる点を触れ、snapshotとframeit相当の処理を自前のSwift製のCLI実装する際に得た知見や、SwiftUIを画像のレンダリングエンジンとして活用する利点などについて紹介したい思います。

エンジニアに「状態管理うまくいってますか」という言葉を投げつけるのは、心に深い傷を刻む結果になると一般に知られています。

宣言的UIの流行により、GUIアプリケーションにおける支配者は状態（データ）となり、表示コンポーネントは状態の落とす影に過ぎない存在となりました。これにより「開発者は状態管理だけをうまくやればいい」という仕組みが出来上がるのですが、我々は次の現実に直面することになります。そもそも状態管理をうまくできない、と。

私がウェブ技術を17年間触れてきた中で、状態管理というのは最も難しい技術に分類されると感じています。そしてウェブ技術をベースにしているReact Nativeではその問題が直撃します。

密結合にすると変更に対して硬直化する、疎結合にすると流れが把握できなくなる、綺麗にするために状態管理ライブラリを入れたのに逆に散らかってきた、公式サイトに書いてある方法でやっても改善しない、ベストプラクティスを実践しているはずなのに結果が出ない。何も思い通りにならない。チームが技術に振り回されてる気がする。状態管理だけうまくいけば開発はスムーズにいくのに、状態管理ができない！

実際に状態管理の設計に取り組むと「管理と言いつつもほとんどの状態は管理できない場所にある」ことに気づきます。HTTP通信、デバイスのセンサ、回線の状況。つまり状態管理というのは、根本的に管理できないものを管理する技術でもあります。

このトークでは、そもそも状態とは何なのかという基本的なところから、状態をいかにコントロールして、アンコントローラブルな状態に対してどう立ち向かえばいいのかという実践的なところまで、私が今まで開発に携わってきたtoBのシステムや音声ライブサービスなどから得られた経験をもとに知見を共有したいと思います。

WWDC は async/await で盛り上がっていて Combine ロスなので、Combine について発表したいと思います。

Combine は複数のイベントを扱うのが楽だったり、debounce operator などを利用した時間を制御するような処理も容易に記述できるので、有用なシーンはまだまだあると個人的には思っています。
しかし、Combine を使って時間の制御などを行い始めるとテストが難しくなっていきます...

このトークでは、そんな Combine を使ったコードのテスト方法と仕組みについて以下のような内容で発表したいと思っています。

・ViewModel 内で Combine を利用するコードの基本的なテスト方法
・combine-schedulers というライブラリによって Combine の時間を操りテストを劇的に改善する方法（より正確なテスト・テストの実行時間の削減が可能）
・combine-schedulers の仕組み

発表で紹介させて頂く combine-schedulers は、最近話題になっている The Composable Architecture（TCA） や isowords の作者である Point-Free さんが作っているライブラリで、TCA との相性も良かったりします。

しかし、このライブラリは TCA には依存しておらず、TCA を利用していないコードでも十分に効果を発揮できるものになっています（本トークも TCA に依存しない形式にします）。

さらに、このライブラリには他にも様々な機能があります。
特に UIKit や SwiftUI のアニメーションを操る機能もあるのですが、時間に余裕があれば紹介させて頂きたいと思っています！

SwiftUIではViewが状態を持たなくなることによりシンプルにコードでUIを表現できるようになりました。
しかし状態がなくなったわけではありません。この状態をどう管理していくかが問題になります。

宣言的UIコミュニティでは、状態管理手法について数年さまざまな議論を経て変化を遂げてきました。
その中で一定の答えが出ようとしています。その歴史と現在の回答を説明したいと思います。

本発表でみなさんがシンプルでスケーラブルなコードにより高速にiOSアプリを開発できる体制を構築するお手伝いができたらと考えています。

この発表では、以下について解説します。

• なぜ状態管理のアーキテクチャを考える必要があるのか？
• 宣言的UIの状態管理アーキテクチャの歴史(Flux、Redux、GraphQL)
  • Fluxが提案された根本的な理由と現代における異なる解決手段
  • Redux(The Composable Architecture)のボイラーテンプレートと正規化の課題
• コンポーネントとカプセル化
  • 状態とは何か？
  • 2つのSingle Source of Truth
  • Lifting State Up(State Hoisting)
  • Reducerの必要性
  • 状態の種別と管理方法、状態における新たな認識と捉え方
• 宣言的UI(SwiftUI)と宣言的データフェッチング(GraphQL)によるシンプルなアーキテクチャの実現
  • なぜAPI仕様であるはずのGraphQLが状態管理に関係するのか、クライアントキャッシュ
  • GraphQLとViewModel
  • Fragment Colocationによるスケーラブルな開発
  • RESTのためのクライアントキャッシュ

近年、高性能なサーバーではなくスマートフォンなどのモバイル機器上で機械学習モデルの推論を走らせる、EdgeAIと呼ばれる技術の開発が進んでおり、 TensorFlowLite/MLKit/CoreML/MediaPipe をはじめ様々なモバイル端末向けの推論ライブラリが開発されています。

メルカリでは、動画などストリーミングメディアの推論に特化した MediaPipe というGoogle製のOSSの活用して、カメラをかざすだけで家の中にあるアイテムがいくらで売れるのか知ることができる、「かざして売れるかチェック」という機能を提供しています。

このトークでは、この機能が開発されるまでに遭遇した困難とその解決方法を、大きく3つのトピックに分けてお話していきます。

• BazelでBuildされるMediapipeをiOS Frameworkとして提供する方法
• 推論の計算負荷を減らし、電池消費を抑える工夫
• モデルサイズを小さくしてダウンロードサイズを抑える工夫

従来の iOS アプリ開発では、主に Grand Central Dispatch を用いた非同期計算（イベントループ、マルチスレッド、マルチコア）と、
それらの処理をパイプライン合成可能な単位にラップしたリアクティブプログラミングが主流でしたが、
Swift 5.5 の登場により、いよいよ言語仕様としての async/await と Structured Concurrency が導入されます。

普段、私たちが Swift プログラミングで書く同期的なコードが、 async/await キーワードを付けるだけで、いとも簡単に非同期のコードに変換できてしまう。
さらに、協調的マルチタスクによって、スレッドを大量消費したりブロッキングすることなく、実行途中の関数を一時停止したり再開できる。
まるで魔法のようにも見えるこれらの仕組みですが、その裏側は一体どのように動き、解釈できるのでしょうか？

理論的背景からコンパイラ・ランタイムの実装に至るまで、テーマが非常に多岐に渡るとても奥深い領域ですが、
今回の発表では主に前者について、関数型プログラミングの観点から解説を試みようと思います。

重要なキーワードは、ずばり「モナド」「継続（コールバック）」「コルーチン」。

関数型プログラミング界の三銃士を連れながら、皆様の心の中の継続を呼び起して協調的な発表になるよう目指します。

近年、1つのiOSアプリケーションを複数のモジュールに分割してビルドするマルチモジュール構成を採用したプロジェクトが増えてきています。

我々のアプリでは、過去2年間で、アプリ全体を30個程度のモジュールに分離し、十数名の開発者で年間50回程度のリリースを実現しています。

この構造により、各機能が疎結合になったことや、単機能でのアプリ実行によるビルド時間の高速化、Xcodeの動作速度アップといったDX改善の恩恵を受けることができました。

しかし、その構造を実現するには、モジュール構成のデザインや、依存関係の解決といった技術上の課題も多く存在しました。
また、如何にアーキテクチャを整備できたとしても、チーム全体で日常的に利用していくために、モジュール分離を促進していくための仕組み作りも不可欠です。

本セッションでは、我々のアプリ開発を通して培った、実践的なマルチモジュール開発についての実情をお伝えします。
以下の論点について網羅的にお伝えする予定です。

• マルチモジュール化以前
  • なぜマルチモジュール化が必要だったのか
  • どのようなマルチモジュール構成に向いているか
• モジュールの構成
  • アプリ全体のプロジェクト構成をどのように分離すべきか
• 依存解決
  • 型安全なモジュール間の相互依存解決の仕組み
  • 外部ライブラリの利用や抽象化
  • テストや動作確認環境の整備
• チーム内にモジュール分離を用いた開発を浸透させるには
  • コード生成機によるモジュール分離の促進
  • ドキュメントやポリシー整備のノウハウ
  • メタプログラミングやlinter、コンパイル時チェックを利用した機械的な制約手法

Swift Concurrencyは、WWDC2021で発表されたSwiftの言語に追加された大きな機能です。個人的な興味から、Swift ForumにSwift Concurrency Roadmapが登場して以来、40以上のスレッドを追っかけてきましたが、様々な機能やルールがあり、とても便利であるように見えるものの、学習コストは決して低いとは言えず、使いこなすのはかなり大変になるのではないかと感じています。

そこで、今回は、みなさまと一緒に、Swift Concurrencyの世界へ最初の一歩を踏み出したいと思い、このプロポーサルを出しました。

このトークでは、これからSwift Concurrencyを学ぶために

• Swift Concurrencyってそもそも何？どういうものがあるの？何ができるの？
• Swift Concurrencyは内部の仕組みはどうなっているの？
• GCD(Grand Central Dispatch)とは何が違うの？

など、Swift Concurrencyのなぜ？や何？を見ていきたいと思います。

また、WWDC2021の時点では機能が完全に揃ったわけではなく、WWDC2021の後も議論は継続しており、現在も色々な変更が入っています。そういった変更点などにも触れていきたいと思います。

Swift Concurrencyの世界はとても壮大ですが、まず一歩、新しい世界へ一緒に踏み出してみるのはいかがでしょうか？

iPhone 12 Pro 以降に搭載されたLiDARスキャナにより、
ARだけでなく、カメラのオートフォーカス（以下AF）性能が飛躍的に向上しています。

特に、画像から距離情報を取り出すタイプのAFが苦手とする
暗所での撮影において、非常に高速なAFが実現されています。

この講演では、LiDARスキャナを利用したシンプルなAFと、
対象物の背景にぼかしを作る機能を盛り込んだカメラアプリを作成し、コードを中心に解説します。

AF自体はiOSに標準搭載されていますが、自分で作ってみることでAFとLiDARの理解を深めることができます。

この講演では、以下のトピックを中心にお話しします。
・各AF方式の簡単な説明
・暗所での性能比較 (iPhone12 Pro / iPhone11)
・LiDARによるオートフォーカス機能の実装方法
・背景ぼかし機能の実装方法
・動画によるデモ
・実装が困難だったところとその解決方法の提案

私たちは常日頃、日付や時刻、時間、数字、名前などを表示するために、最終的に様々な情報を String に変換しています。
その際に便利な API が Formatter です。Date を String にする DateFormatter が良く使われる一例ですが、実は真の力はそこにとどまりません。

数字を3桁おきに 「,」を入れた表示をしたい
「0.85」を「85%」と表示したい
「-1700」を「(1,700)」と表示したい
1日前を「昨日」、1ヶ月後を「来月」と表示したい
[“Apple”, “Banana”, “Orange”] の Array を「Apple, Banana and Orange」と表示したい

…これらを実現するために独自で実装を行っていませんか？
コーディングのトレーニングのために独自実装する分には問題ありませんが、実プロダクトでは工数がかかり、考慮漏れがあると問題になります。しかし大抵は対応する Formatter が標準で用意されています。

日付、時刻、時間、%、通貨、指数表記、バイトサイズ（MB、GB…）、人の名前、加速度、角度、面積、体積、質量、濃度、期間、電気、エネルギー、周波数、燃費、照度、長さ、圧力、速度、温度…

これらの Formatter は i18n 対応を含めて強力にサポートしてくれますが、1つの言語のみに対応する場合でも Formatter を使うべきです。言語は同じでも地域によって適切なフォーマットが違う場合があるからです。
このセッション（40分版）では標準で用意されている Formatter のすべてと、その使用例、絶対にしてはいけない使い方を紹介します。

誤った使い方をすると、あなたも「令和2021年」に飛ばされますよ…

Happy Formatting!

アプリケーションの体験にはUIがザラつかない・カクつかないことは重要です。
Xcode12ではInstrumentsにAnimation Hitchesが追加され、WWDC21でもスクロールパフォーマンス関連のセッションがありました。この手のアップデートは毎年のようにあり、Appleも力を入れています。

本トークでは、UIが描画されるまでの基本的な原理を紹介し、その後描画を軽くするための実践的なテクニックを紹介します。
残念ながらUIKitは内部動作を知ることができないため、基本原理はFlutterを通してMetalの動作を覗くことで紹介します。実践的なテクニックはUIKit（やSwiftUI）で使えるものを紹介します。
主な題材として影の描画を取り扱う予定です。

iOSアプリを作成する上でこれってセキュリティ上大丈夫だろうか？
セキュリティ上どういうところが危ないんだろう？って思ったことないでしょうか。
iOSアプリを作成する上でセキュリティ上気をつけた方が良い基礎を紹介します。

コンテンツ(予定):
・通信する上で気をつけた方が良いこと
　　通信の暗号化とSSL証明書、ATS対応
・URLスキームの脆弱性
　　URLスキームであり得る複数の攻撃手法と対策
・ハードウェアへの重要情報をどこに保存すれば良いの？
　　Keychain、UserDefaults、ファイル保存などの保存方法とセキュリティの違いについて
・認証って何？
　　OAuthなどのいくつかの認証フローの仕組みについて

今秋リリース予定のSwift 5.5には、async/awaitやactorなどの並行処理関連の新機能が多く含まれます。これによって、iOSアプリ開発における非同期処理や並行処理のコードは劇的に変化します。本トークでは、iOSアプリ開発でよく見かけるようなケースを取り上げ、Before & Afterのコードを示し、何がどのように変わるのかを説明します。

async/awaitやactorは使いこなせばとても便利ですが、新しい概念を初めから抽象的に学ぶのは大変です。しかし、それらが解決しようとしている問題自体はiOSアプリ開発者にとって馴染み深いものです。async/awaitやactorで書くコードが既存コードのどのような処理に対応するのか、既存コードにはどんな問題があり、async/awaitやactorはそれをどう解決してくれるのか、具体的なケースで学べば入口のハードルはぐっと下がります。

Swiftの並行処理関連の新機能は、async/await、async let、Task、CheckedContinuation、actor、Sendable、MainActorなど多岐に渡ります。それらを一つ一つ取り上げ、具体例を題材に、iOSアプリ開発のコードがどのように改善されるのかを説明します。