こんにちは！
Sansan事業部でiOSアプリエンジニアをしている砂金です。
先日開催された「After iOSDC Japan 2020」に参加しましたので、その様子をレポートしたいと思います。
After iOSDC とは
After iOSDCとは、iOSDCの振り返りをしつつ、LTやパネルディスカッションにより、iOSに関連する技術やノウハウを共有するイベントです。
今回のAfter iOSDCは、note（株）、（株）ZOZOテクノロジーズ、Sansan（株）の3社によるオンライン合同イベントとなりました。 イベントの様子はYoutubeからも確認できますので、ぜひご覧になってみてください。
イベント概要
LT
特別講演
パネルディスカッション
LT
iOSアプリの起動時間短縮にむけて（ZOZOテクノロジーズ 元 政燮氏）
トップバッターは、ZOZOテクノロジーズの元さんによる、アプリの起動時間の改善に関してのLTとなります。
起動時間について考慮することがなぜ重要かについては、WWDCでAppleは以下の3点を挙げています。
- 起動がスムーズであることが、アプリの第一印象の良さに繋がる
- 起動時の処理がコードの全体的なパフォーマンスを示す
- 起動時にCPUやメモリの負荷を抑えることが、バッテリーやパフォーマンス改善に繋がる
上記を踏まえた上で、どのようにして起動時間を短縮していくかを見ていきましょう。
どのようにしてアプリの起動時間を計測するか
まず、アプリの起動時間短縮のためのアクションをとる前に、現状の起動時間を計測しないことには改善のしようがないですね。 そこで挙げられていたのが以下の3つです。
- Metrics Organizerを使う
- Window → Organizer → Metricsから確認可能
- 現状の起動時間を把握する
- Instrumentsを使う
- App Launchを使うことで、起動処理のデバッグが可能
- 環境変数にDYLD_PRINT_STATISTICSを追加する
- pre-main time（UIApplicationMainがreturnされるまでの時間）を表示できる
起動時間計測の際の注意点
計測する際には以下の2点をしておくことで、起動時間の計測に対しての外部からの影響を抑えることができます。
- iCloudをログアウトしておく
- ネットワークは切るか機内モードにしておく
アプリ起動フェーズについて
アプリ起動時間の計測方法と注意点について理解したところで、 次に、アプリの起動フェーズを6つに分けて説明していただきました。
- System Interface Init
- Runtime Init
- UIKit Init
- Application Init (didFinishLaunchingWithOptions)
- Initial Frame Render
- Extended（今回のLTでは省略）
各フェーズでの処理の内容とその短縮方法を見ていきましょう。
System Interface Init
処理内容
- 共有ライブラリやフレームワークのロード
- アプリ起動に必要なデータをメモリにロード
短縮方法
- 不要なLibraryやFrameworkをリンクさせない
- 起動時の動的なライブラリロードを避ける
- 複数のFrameworkをマージする
Runtime Init
処理内容
- 言語ランタイムの初期化
- Rebase & Binding
- Objective-Cのmeta dataを読み込む＆初期化
- staticメソッドの初期化
短縮方法
- Staticメソッドを減らす
- Objective-Cのクラスを減らす
- +[Class load]を避ける
- +[Class initialize]を使う
- Objective-Cではなく、Swiftを使おう！
UIKit Init
処理内容
- UIApplicationとUIApplicationDelegateの初期化
- UserDefaultsの初期化
短縮方法
- UserDefaultsに格納する内容を減らす
Application Init (didFinishLaunchingWithOptions)
処理内容
- アプリ仕様による処理
- 外部SDK（Firebase等）の初期化処理
短縮方法
- 後回しできる処理があれば、実行タイミングを変更する
Initial Frame Render
処理内容
- ビューの作成、レイアウトの実行及び描画
短縮方法
- Viewの構成を単純化する
- Autolayoutの制約を減らす
Extended（補足）
処理内容
- アプリ固有のロジック
- 非同期にロードされたデータの表示
短縮方法
- os_signpostを使用して時間を測定する
起動時間短縮に向けた対応の流れ
最後に起動時間を短縮する際の基本的なフローとして、以下の3点が大事であると説明されました。
- 現状の起動時間を把握する
- ボトルネックを探す
- 各フェーズの手を付けられるところで起動時間短縮のための対応を行う
まとめ
アプリの起動時間短縮に関して、こちらのWWDCのセッションも参考になるかと思われます。併せて御覧ください。
現実的かどうかはともかくとして、Appleによる理想起動時間は400ミリ秒とのことです。
iOSエンジニアの皆さん、頑張りましょう😇
Firebase In-App Messaging で過去バージョンのユーザーへ更新を促したい！（Sansan 中川 泰夫）
続いて、弊社iOSエンジニアである中川から、FirebaseのIn-App Messagingを使って特定のユーザーへメッセージを配信する方法に関しての話となります。
In-App Messagingとは？
In-App Messagingとは、特定のユーザーに特定のタイミングでメッセージを配信する事ができるFirebaseのサービスです。非常に導入が容易であり、配信するメッセージのデザインもカスタマイズ可能です。
なぜIn-App Messagingを検討することになったか
PM「バージョンアップなしで過去バージョンのユーザーへガイドすることはできないか？」
この一声によりIn-App Messagingの技術調査を開始しました。
In-App Messagingでできること
In-App Messagingでメッセージの配信ができると説明しましたが、具体的にどの程度の配信が可能なのかを見ていきましょう。詳細な内容については公式ドキュメントに任せることとして、ここでは基本的な機能を紹介したいと思います。
- メッセージレイアウトの種類
- カード・モーダル・画像のみ・トップバナーの4種類
- メッセージコンテンツ
- 各メッセージタイトル・本文・ボタンの色を設定
- 画像の設定
- ボタン・画像・バナー押下時のアクション先の指定
- 配信対象ユーザー
- アプリバージョンや言語・国といったものから、起動回数による指定も可能
- 表示トリガーの条件
- 開始日と終了日の設定
- メッセージの表示タイミングの設定（アプリ起動時、フォアグラウンド時など）
- 独自のメッセージ表示UIの作成も可能（InAppMessagingDisplayプロトコルに適合させる）
In-App Messagingの導入手順
導入手順に関しては、上記のスライドにて、Firebaseの導入から実際にメッセージをテスト配信するところまで、詳細に記載されているのでぜひ確認してみてください。非常に簡単に導入ができるということが理解できるかと思います。
SansanアプリでIn-App Messagingを採用してみて
ここまで使い方やその機能を見てきましたが、FirebaseのIn-App Messagingを使うことで、無事PMの要望は叶えられそうですね🤗
それでは実際にSansanアプリにIn-App Messagingを採用してみた結果を見ていきましょう。
Firebase In-App Messaging 採用されんかった😢
はい。
悲しみのある一文ですね😇
今回採用されなかった理由は以下の3点となります。
- 外部サービスに依存するリスク
- すでにAWSに依存している上で、更にベータ版であるIn-App Messagingにも依存することのリスク
- Sansanアプリにはすでにお知らせ機能があり、その機能を拡張したほうが運用面で楽
- アプリのアップデートを促すプロジェクトが別にある
- バージョンチェックによってアップデートを促すライブラリ（Siren等）とお知らせ機能を組み合わせることで要望は十分満たせる
まとめ
今回弊社では採用とはなりませんでしたが、In-App Messagingは特定のユーザーにメッセージを配信する事ができる非常に便利なサービスなのでおすすめです！
note社でのMagic Pod活用事例（note 植岡 和哉氏）
最後のLTはnote社のMagic Podの活用事例について、植岡さんにご紹介いただきました。
Magic Podとは
Magic Podとは、クラウド上でUIテストの作成実行が可能なサービスです。
note社ではMagic Podを2種類のタイミングで動作させているとのことです。
- masterブランチへのマージ
- 毎朝の定期実行
Magic Podのメンテナンスのタイミングは、問題が発生した時や新機能の追加・既存機能のリニューアルの時に対応しているようです。
またテストの作成箇所に関しては、よく通る導線や優先度が高い機能においてテストをしているとの説明もありました。
Magic Podの操作
Magic Podはテスト対象のアプリを指定し、端末を起動するだけで始めることができます。
Magic Podの説明のため、植岡さんの発表を参考に私の方でサンプルアプリを用意しました。
サンプルアプリをもとに使い方を順を追って見てみましょう。
用意したアプリにはTOPページにボタンが2つあり、ボタンによって遷移先の画面で表示される文言が変更されるものです。（サンプルなので低機能なことはご勘弁ください🙇）
テスト定義の基本的な作成フローは以下の通りです。
- Magic Podでアプリを起動する
- カメラアイコンから画面をキャプチャする
- キャプチャすることで、スキャンされUIコンポーネントとして認識される
- 認識されたUIコンポーネントをリストにDrag&Dropしてテストを作成する
それでは画像とともにテスト定義の作成までを見ていきましょう。
①Magic Podでアプリを起動する
②カメラアイコンから画面をキャプチャする
③キャプチャすることで、スキャンされUIコンポーネントとして認識される
④認識されたUIコンポーネントをリストにDrag&Dropしてテストを作成する
これでテスト定義の作成が完了しました。
今回定義した内容自体は非常に単純なもので、ボタンタップで画面遷移をし、その表示内容が期待していたものと同じかどうかを確認しています。
テストを実行した結果が以下となります。
無事成功となりました。
それでは次に失敗するテスト定義を作成してみます。
5番目の期待値をボタン２からボタン１に変更しています。
再度実行してみましょう。
無事？に失敗となりましたね。良かったです。 今回は非常に簡易的なテストでしたが、より実践的なテストを確認したい場合は、植岡さんの素晴らしいデモをぜひ御覧ください。
便利だと思った機能
Magic Podを導入しているnote社において、特に便利だと考えている機能についても共有していただきました。
- 共有ステップ
- 複数行をまとめられる
- 会員登録やログインなど、何度も実行するような機能をまとめておくと便利
- 一括実行時にテストケースの番号を指定
- 一括実行時に指定するテストケースの番号を一覧で指定
- 作成途中のテストケースや仮で作ったテストケースを一括実行には含めない
- 動的な変数の作成
- 会員IDなど重複しない値を設定したい場合に使用
まとめ
テストの実行のためにはテストコードの作成と実行環境の構築が必要ですが、その点、Magic Podはテストコードの作成と環境設定が非常に楽ですね。 スキャンをするとUIコンポーネントとして認識されるので、後は設定したいテストを選択していくだけで完成なので非常に簡単です！
特別講演
SourceKit-LSPを使ってWebブラウザでSwiftの入力補完を実現する（ZOZOテクノロジーズ 技術顧問 岸川 克己氏）
特別講演としてZOZOテクノロジーズ 技術顧問 岸川さんによる、SwiftFiddleとSourceKit-LSPに関するお話でした。
iOSDCではSourceKit-LSPがそもそも何かという話やその使い方の話をされていました。 今回はその応用として作成されたSwiftFiddleでのコード補完等のデモを見ながら、SourceKit-LSPに関して詳しく説明していただきました。
SwiftFiddleとは？
Webブラウザを使えるPlaygroundです。Swiftのバージョンもver3.0.1以降に対応しているようです。
実際のデモ映像はYoutubeからご確認いただければと思います。
SourceKit-LSPとは？
SourceKit-LSPとは、SwiftとCベースの言語のためのLanguage Server Protocolです。
LSPというものについても簡単な説明を加えておくと、LSPとは開発ツールと言語間をJSON-RPCでやりとりをするプロトコルです。コード補完やコードジャンプ等に対応するためには、エディタと各言語のためのアドインの実装が必要だったので開発者としては非常に労力がかかるものでした。
そこで登場するのが開発支援のための共通インターフェースであるLSPであり、エディタ（Client）と言語（Server）間の通信をJSON-RPCによって行うことで、エディタは最小限の労力で言語をサポートすることが可能となります。そのため、LSPに対応しているものであれば、Xcode以外のエディタでも補完やコードジャンプ等が使えるようになります。素晴らしいですね！
SourceKit-LSPの開発状況を確認したい場合は、Statusから確認することが可能です。
SwiftFiddleがどのようにして通信しているか？
LSPの具体的な通信仕様に関しては、MicrosoftのLSPドキュメントを御覧ください。
これまではNode.jsのサーバがブラウザからのコードの内容をキャッチし、サーバサイドでSwiftをコンパイルし、実行後に結果を返す仕組みであったようです。
そこに今回SourceKit-LSPと通信して結果を返すために上記の仕組みを拡張したとのことです。
SourceKit-LSPと通信するための仕組みとしてVaporを採用し、Vaporによるバインディングを利用し直接やり取りをさせるようにして結果を返すようにした、との説明がありました。
GitHub Codespaces
SwiftFiddleと同系統のものとしてGitHub Codespacesの紹介もされました。
GitHub CodespacesとはWebブラウザから使えるIDEであり、VSCodeをベースとしたWebアプリケーションです。GitHub Codespacesという名前の通り、GitHubから直接利用できるのが最大の特徴ではないでしょうか。
現時点ではGitHub Codespacesは限定パブリックベータであるため、申込後招待を待つ必要があります。ベータ参加に申し込むか、一般提供されるまで首を長くして待ちましょう。
パネルディスカッション
『初のオンライン iOSDC、どうでしたか?』
イベントの最後に、モデレータにnote 森口さん、パネラーにnote 植岡さん、ZOZOテクノロジーズ 西山さん、弊社 栗山によるパネルディスカッションへと移りました。
オンライン開催となった今年のiOSDCに関して、各々の感想を述べてもらいました。
初のオンライン開催となったiOSDCに関して
（ZOZOテクノロジーズ 西山さん）
- 初めてニコ生で8888コメントを打ち込んだ
（note 森口さん、植岡さん）
- 初めての参加でかつ登壇となったが、iOSDCにお祭り感を感じた
- 発表に対して簡単にコメントを打ち込めて、かつ盛り上がりが視覚的に見られるのが良かった
（Sansan 栗山）
- ニコ生での8888コメントデビューをさせてもらった
オンライン収録による発表
（ZOZOテクノロジーズ 西山さん）
- 登壇者による裏話も聞けて楽しかった。
- 「この時スライドのミスに気付いたので、撮り直すべきか悩んでいます」といった裏話が聞けたのは事前収録のおかげかもしれない！
（note 森口さん、植岡さん）
- どのように収録することになるのか最初は不安だったが、非常にシステマティックで収録がしやすかった
- 登壇者はDiscordで補足や質問に対する解説ができたのも良かった。オフラインではできない体験だった
- ニコ生とDiscord、Twitterと、多くのツールに対応するのは大変だった。来年はよりシンプルになると尚良いと感じた
- ツイート内容がニコ生にも流れたら面白そう
（Sansan 栗山）
- 登壇したが、LTでの参加となったので収録自体はしなかった
SwiftUIの導入
（ZOZOテクノロジーズ 西山さん）
- 今回のiOSDCではSwiftUIネタが多いと感じた。無視できない存在に感じた
- ZOZOテクノロジーズではプロダクトへの導入はまだ出来ていない
- 社内で使うデモアプリではSwiftUIを導入し始めてはいる
（note 森口さん、植岡さん）
- SwiftUIの本格導入はまだだが、Combineは移行し始めている
（Sansan 栗山）
- SansanアプリはiOS11以降をサポートしているので、プロダクトへの導入はまだできていない
Xcode Previewの使用
（ZOZOテクノロジーズ 西山さん）
- UIKitベースのアプリへのXcode Previewの導入に関しても気になった
（note 森口さん、植岡さん）
- note社ではすでに導入している
- Preview用のターゲットを作って、依存関係を閉じ込めている
（Sansan 栗山）
- Sansanアプリでもつい最近Xcode Previewを使い始めたところ
原稿の大変さ
（note 森口さん、植岡さん）
- 原稿を出せたことは家族に誇れることだよね
（Sansan 栗山）
- 原稿2本出し終えたところで、燃え尽き症候群になった
- 締切が思ったよりも早く、中々ヘビーだった
- InDesignを使って原稿を書いたが、初めて使ったので使い方に慣れるまでが大変だった。InDesign自体はレイアウトの変更も柔軟に対応できるのでオススメできる
OSのサポート対象とサポートを切る判断
（ZOZOテクノロジーズ 西山さん）
- プロダクトにもよるが、3バージョンをサポートをしている
- 利用率を見ているが、だいたい3バージョンのサポートで90%後半程度はサポートされる状態となっている
（note 森口さん、植岡さん）
- noteではiOS13以降をサポートしている
- DAU・MAU等を見て閾値を下回ったら切る判断をしている
- 古いユーザーのサポート範囲を広げることの重要さも理解しているが、古いOSは脆弱性を抱えたままになってしまう。よりセキュアにアプリを使ってもらうためにも、開発者側から下位OSのサポートはしないという積極的なスタンスを取ることが重要だとも感じている
（Sansan 栗山）
- iOS11以降をサポートしている
- サポートを切る際には半年前に事前にアナウンスをしている
- ユーザーの使用OSのパーセンテージが一定値を下回ったらサポートを切るためのアクションをしている
おわりに
今回、After iOSDC Japan 2020をレポートさせていただきました。
iOSDC、After iOSDC共にオンライン開催となりましたが、皆様にはどのように感じられたでしょうか。
私個人としてはオンラインでのカンファレンスも非常に良いものだと感じました。
登壇者による裏話も聞けましたし、コメントという形で視覚的に盛り上がりが見られたのもオンライン開催の良さだと思います。
登壇者の皆様お疲れさまでした。8888
