はじめに

iOSDC 2020に参加しました！
https://iosdc.jp/2020/
初のオンライン開催でしたが、会社の仲間と一緒にわいわい見るのは楽しかったです。
SwiftUI関連のトークが多くて、昨今のトレンドを反映してるなぁという印象を受けました。

どれも勉強になるトークでしたが、印象に残ったトークを備忘録としてまとめておきたいと思います。
スライド画像多めでまとめているので、ざーっと流し見するも良し、気になるものがあればURLから飛んで詳細を見るも良しです（YouTubeのURLもアップされ次第追記予定です）

Day1

iOSには無いmacOS独自機能をCatalystで実装する

概要

内容

macOSはもともとAppKitだけだったが、一部にUIKitが利用できるようになった
macOSとiOSの違いも吸収されている
Xcodeでチェックを入れるだけでMacでも使えるようになる

macOS独自機能
* メニュー
* タッチバー
* ツールバー

タッチバーの一部でSwiftUIと相性が悪いところがあった
SwiftUIを利用したい場合はmacOSネイティブのアプリを開発したほうが良いかも？

ひとこと所感

まだ全然macのこととか考えられていませんでしたが、このトークを聞いて、やるべきことのイメージが少し持てるようになりました！

そろそろCombine

概要

スライド
- そろそろCombine - Speaker Deck
YouTube動画
- iOSDC Japan 2020: そろそろCombine / shiz
プロポーザル
- そろそろCombine by shiz | トーク | iOSDC Japan 2020 - fortee.jp

内容

Combineとは？
連続した多種類の非同期処理などを単一の方法で扱う宣言的なAPI

iOSの非同期処理は難しい
* タイミング次第で結果が変わってしまう
* どこで処理を実装しているのか探すのが一苦労

非同期を扱う方法もたくさんある

Combineでは、あらゆる処理をPublisherにすることで、非同期をスマートに扱うことができる
他のフレームワークとの連携も容易になる

宣言的とは？
指示的：「冷蔵庫からペットボトルの水を取り出して、コップに注いで、飲みます」
宣言的：「受け取った水を飲みます」

宣言的のメリット

Combineは宣言的なので、コードも短くスッキリする

ひとこと所感

Combineってなんぞや？という状態でしたが、RxSwiftと概念的・用語的に似ている部分があるとわかって少し安心しました。勉強せねば…

新規機能開発からモジュール分割を始めてみる

概要

スライド
- 新規機能開発からモジュール分割を始めてみる - Speaker Deck
YouTube動画
- iOSDC Japan 2020: 新規機能開発からモジュール分割を始めてみる / Ryo Izumi
プロポーザル
- 新規機能開発からモジュール分割を始めてみる by Ryo Izumi | トーク | iOSDC Japan 2020 - fortee.jp

内容

機能が増えるとコードベースも巨大化して開発効率の低下につながるので、モジュール分割を行った

既存アプリに取り入れたいけど、依存が深くてどこから切り出せばいいのか分からない

大規模リファクタが必要だけど、新規機能開発も止めるわけには…（わかりみ）

そこで、新規機能からモジュール分割する前提で設計することにした

手順はこちら

独立した新規画面であったり、既存ドメイン仕様への依存が少ない場合はモジュール分割しやすい

メリットもあるけど、デメリットもある
コンフリクト回避のために、XcodeGenを先に導入すべきだった
抽象度が上がるので、実装がどこにあるのかわかりずらくなり、新しく入ったメンバーが困る場面もあった

ひとこと所感

新規機能からモジュール分割するの良さそう。いざやろうとしたら「どこから切り出していいか分からない」と絶対なると思うので、その際に再度見返したいトークでした！

効率よくUIKitからSwiftUIへ移行する

概要

スライド
- Migrating from UIKit to SwiftUI efficiently - Speaker Deck
YouTube動画
- 効率よくUIKitからSwiftUIへ移行する - YouTube
プロポーザル
- 効率よくUIKitからSwiftUIへ移行する by josh | トーク | iOSDC Japan 2020 - fortee.jp

内容

SwiftUIを使ったほうがいい理由
* SwiftUIではより多くのことが、より少ないコードでできる
* 色んな機能がUIKitよりも楽に実装できる（アクセシビリティ、ダークモード/ライトモード、標準レイアウトなど）
* すぐにUIKitがなくなるわけではないが、いずれSwiftUIでやるしかない場合が出てくるかもしれない

SwiftUIへの移行を阻むもの（待ったほうがいい理由）
* UIKitほど歴史がないのでバグがあったり、OSによって違いがあったりする
* UIKitと混ぜて使うのは苦労する

SwiftUIへの移行をどこから始めたらいいか？
* SwiftUIからObjective-Cが直接使えない（逆もしかり）ので、早期にSwift化しておく
* 移行が重なると面倒なので、Swiftの最新バージョン、機能を使っておく

事前にUIKitをモダンな使い方にしておくのも大事。
* AutoLayoutを使う
* SefeAreaを使う
* 巨大なStoryboardにせず、再利用しやすくするためコンポーネントに分ける（部分的にSwiftUIに移行しやすくなる）
* 宣言的なUIKit APIを使う（StackView、Compositional Layoutsなど）

* 本番のアプリにいきなりSwiftUIを導入するのではなく、同じ分野のアプリを小さい規模でプロトタイプとして作ったほうが、メリットデメリットがわかりやすい
* その中で、SwiftUIに向いてない画面が特定できるので、必要に応じてデザインの変更を検討する
* 既存のアプリ内で、iOS13限定の機能をSwiftUIで作るのもおすすめ

SwiftUIに向いているアーキテクチャはこの3つ
* Redux
* TCA
* MVVM

Tips
* 1つの画面の中でSwiftUIとUIKitを混ぜすぎないこと
* TableViewなどシンプルな画面から移行すること
* 急ぎすぎないこと
* SwiftUIは深いところまでCombineに依存しているので、SwiftUIを正しく使うにはCombineの知識も必要になる

ひとこと所感

すぐに使える知見がたくさん詰まったトークでした！いずれSwiftUIを本番に導入する日が来るかも？なので、計画的に準備していきたいと思いました。

Day2

Xcode Preview でUIKitベースのアプリ開発を効率化する

概要

内容

Xcode PreviewsはXcode11で導入されたプレビュー機能

SwiftUIでの実装ではXcode Previewsが使えるので、リアルタイムにレイアウトを確認することができる

UIKitベースの実装ではコード修正のたびにSumilatorを起動する必要があって不便…

現状多くのアプリがまだUIKitベースなので、そこにXcode Previewsを組み込んだ話

Previewコードを書くときに使うプロトタイプたち↑

外部から状態を注入できるような、「PreviewableなView」にしておけると良い

メルペイでの活用例
短いテキストの場合、長いテキストの場合のレイアウト崩れがないか、一度にチェックできる

異なる画面サイズの端末だったり

多言語対応している場合は、言語ごとに見たりもできる

iOS13未満もサポートしている場合はどうしたらいいのかというと、2つのやり方がある
* マクロを使ってPreviewコードをビルドから除外する
* Preview専用のターゲットを追加する

Xcode Previewsを導入して既存アプリをSwiftUIの開発スタイルに寄せておくと、SwiftUIへの移行がよりスムーズになるかも？

ひとこと所感

いろんな状態のViewを一度に表示・確認できるのはめちゃくちゃ便利だなと思いました！毎回Simulator起動するのめんどうなので、ぜひ導入したい…

XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する

概要

内容

UITestのつらさ。いつの間に壊れている（悲しい）

UIは変わりゆくものだから…

もともと手動テストのみだったが、QAの工数を減らす手段の一つとしてUITestを導入

新機能と既存機能、どっちを対象にするか？という話があるが、メルペイでは既存機能に対象を絞った
UITestは繰り返し実施されるテストと、安定稼働している機能に対して行うと効率が良い

リグレッションテストに組み込み、効率化を実現した

XCUITestに入門する上で押さえたい3つの重要なクラス

実際のコードはこんな感じ
テスト対象アプリを定義 → UI要素検索 → UI要素取得 → UI操作 → UI検索 → 表示チェック

UITestを書いていると、重複したコードがあることに気づく
まとめたい

Page Object Patternというデザインパターンが有効

3つの大きなメリットがある

PageObjectable プロトタイプを定義して、重複するコードをまとめる

UITestは並列化実行しても時間がかかる

メルペイでは夜間実行したり、GitHub ActionsのLabelトリガーを使ったりしている

ひとこと所感

苦難に立ち向かった知見が詰まっていて、これからUITestを始める人にとってぴったりのトーク内容でした。具体的なコードがあったのでとてもわかりすかったです。

Webとネイティブアプリの付き合い方を改めて考える

概要

内容

新しいサービスを作るようになったときのあるある

Webとネイティブアプリの比較
* アプリ単体での起動・動作
* オフライン動作
* プッシュ通知
などはネイティブアプリにしかない機能

PWAとは？
ネイティブアプリっぽく動くwebアプリケーション

PWAも比較
インストールが可能なので、アプリ単体で立ち上げることができる

App Clipsも比較

（ここから先はあくまで私見によるものと伝えつつ）
ネイティブアプリと同じ体験をWebでも提供することは可能か？
プッシュ通知や最新のiOS技術のことを考えると難しいのでは

現状、プッシュ通知はネイティブアプリ一択

どういうときにWebを活用したら良いか？
* まずは広く機能を提供したいとき
* プッシュ通知がいらないとき
* 最新のOS機能がいらないとき

専門知識が必要だったり、iOS/Androidセットで作らないとユーザーが減ってしまうことなどがネイティブアプリのデメリット

Googleからの検索流入が見込める、両OSに対応できるのはWebのメリット

ひとこと所感

アプリエンジニアなのでネイティブを推したい気持ちはありつつ、Webのメリットも知った上で正しく技術選択をしていく必要がありますよね…。深く考えさせられるトークでした！

テストコードが増えるとバグは減るのだろうか？ - 「0% → 60.3%」で見えた世界の話

概要

内容

仕様は決まった！と言っても、実は完全には決まっていないことも…（あるある）

テストを書くことで仕様の理解が深まる

テストには動的テストと静的テストがある

仕様書のチーム内レビューは静的テストに分類され、動的・静的を併用することで大きな成果が得られる

UI，ロジック、APIなどそれぞれテストが書けていれば、不具合の原因特定も容易になる

モックが書けていれば、意図しないレスポンスが返ってきたケースなども再現できる

しかし、適切なテストを書くには、経験や慣れ、様々な知識が必要

長い目で見たら役に立つが、開発時点では間違いなく工数がかかる
それを許容できる開発環境が必要

現状の課題をよく見つめ、様々なテスト手法がある中で最適なテスト方法を選択すること
費用対効果があるかを考えるのがポイント

テストコードが増えるとバグが減るか？
→ △

テストコードにバグがないなど複数の前提条件を満たすとき、バグは減らせる

ひとこと所感

△というのがリアルでいいですね。経験が浅いとテストコードのテストコードが必要になってきそうで、テスト難しいなって改めて思いました。

おわりに

（トークの内容が濃すぎて）気づいたら大作になってしまいました！

見たかったけど見れなかったトークのスライドをここに置いておきます。
YouTube動画が配信されたら見るぞ〜

iOSDC本当に楽しかったです！みなさまお疲れ様でした！！！！

iOSDC 2020 印象に残ったトークまとめ🎉

はじめに

Day1

iOSには無いmacOS独自機能をCatalystで実装する

概要

内容

ひとこと所感

そろそろCombine

概要

内容

ひとこと所感

新規機能開発からモジュール分割を始めてみる

概要

内容

ひとこと所感

効率よくUIKitからSwiftUIへ移行する

概要

内容

ひとこと所感

Day2

Xcode Preview でUIKitベースのアプリ開発を効率化する

概要

内容

ひとこと所感

XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する

概要

内容

ひとこと所感

Webとネイティブアプリの付き合い方を改めて考える

概要

内容

ひとこと所感

テストコードが増えるとバグは減るのだろうか？ - 「0% → 60.3%」で見えた世界の話

概要

内容

ひとこと所感

おわりに