トークセッション

4年間運用されて表示速度が低下した詳細画面を改善する過程で得た知見 by marty-suzuki

iOSDC Japan 2020 Day 1 Track B 10:50 - Speaker Deck
表示が遅くなった画面を、どのように計測して改善していったかの過程を実際のコードを交えて紹介
遅延初期化時のリコメンドを遅延ロードとか
画面回転のリロードとか

感想
前職はSNSで表示速度とかを、かなり気にして実装してたので、共感やなるほどと思うことが多く、自分も知ってることも知らないことも分かりやすく解説してたので、個人的には非常に面白かった

400種類のアプリを毎日ビルドする自動化の技術 by Kishikawa Katsumi

400種類のアプリを毎日ビルドする自動化の技術 - Speaker Deck
ヤプリは、クライアントごとに、デベロッパーが存在するので、それを手動で管理していると大変なので、自動化したという話

感想
実際に、多数のデベロッパーを管理するというのは、中々ないが、自動化のフローや考え方は非常に勉強になった
現在の業務では、多数でデベロッパー管理というのはないが、前職だとそういうサービスがあった(実際に携わってはいない)ので、今後のビジネス展開として十分あり得そうなので、何かしらここで学んだものを取り入れたいなと思った

Flutter移行の苦労と、乗り越えた先に得られたもの by 桐山圭祐

Add-to-appを使用して既存のプロジェクトにFlutterを段階的移行した話

感想
業務的には、１からFlutterを使うというより、既存のプロジェクトに追加するというのが、現実的だと思うので、具体的な方法を見ることが出来たのはよかった
SWiftUIも同じ宣言的UIなので、SwiftUIを見据えて、Flutterを導入するというものありな気がした

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

新規機能開発からモジュール分割を始めてみる - Speaker Deck
マルチモジュール化の話
実際に、モジュール（フレームワーク）化の方法を丁寧に解説
注意点や発見したこと、メリデメなどTipsのような感じ

感想
実際に今の業務でもモジュール化した方がいいねという話はあがっているので、それの判断基準になりそうな話が聞けたのでよかった
XcodeGenは、他のセッションでもよく出てくるので、今のうちに導入は前向きに検討し、実際に導入することになったときのために、知識はもっといた方がいいなと思った

エラーアーキテクチャ設計について考える by きちえもん

エラーアーキテクチャ設計について考える/Thinking about error architecture design - Speaker Deck
エラーハンドリングを、iOSで改善した話とAndroidで改善した話
それぞれ別の話で、コードもそれぞれのコードでの紹介

感想
個人的には、1番このセッションが有用だった。今現在、まさにエラーハンドリングのリファクタをしているところなので、いろんなところに共感できつつ、点で学んでいた中途半端な知識が少し、線でつながった感じ
一部、Androidのコードで紹介していたが、分かりづらいということもなく、考え方は共通なので、逆にiOSでも同じロジックでいけそうだなとイメージ出来たのはよかった

メモ

考え方は、共通なので分かりづらいということもなく、とても分かりやすかった
以下、いくつか頭に残っているものを列挙

Error型を、そのまま使うと、どんなエラーが起こり得るのか分かりづらい
結果の型を、任意のエラー型を指定できるように
個別のエラーを表現することができるようになった
任意のエラー型は、列挙型で起こり得るエラーを記述
固有エラーを、共通エラーと同じ上位で処理すると、全てのエラーを考慮しないといけないロジックになってしまう。
固有エラーは別の流れにしてViewModelで処理したほうがいい

一石二鳥: マルチモジュール化, ビルド速度快適化 by Saryong Kang

マルチモジュール化のコツとメリデメの話、bazelを用いたビルド最適化の話、テストの目的や考え方・Tipsなどの話

感想
1番、メモを撮った。モジュール編では、別のモジュール化をテーマにしたセッションをより概念的なところからの話のような感じで、モジュール化に対する理解が深まった
ビルド編では、Bazelというビルドツールを知らなかったので、構築が難しいのと、まだXcodeとの相性が悪そうだが、利用できるようになるといろいろなことが出来そう
テスト編では、テストコードを各基準や目的など、よりどんなテストを書けばいいかの理解が深まった

メモ

実践マルチモージュル編
モジュールを分ける基準
・ドメインロジックがグループに分けられる
・スコープがよく定義されている
・複数のアプリで適用可能
・アプリによって活性化される
・既存のモジュールと明確に違う
・長期間担当するチームが存在している

あとから分けるのは難しい
初期段階で分けた方がいい

スピード感と正しさを両立

ドメインごとの分離
各ドメイン３−４つのレイヤーに分離
Binding,Presentation,Data
Presentationレイヤーは、ドメインロジックと分けるメリットはあまりない

Dependency Inversion Principle　依存性逆転の原則
依存性逆転したほうが、分かりやすい
例えば、Repositoryのインターフェースを、プレゼンテーションレイヤーに書く

ビルド編
Bazel　
バックエンドからモバイルまで、幅広くビルドができるもの
Skylark　Pythonのサブセット
分析段階のビルドは、LinuxでもOK、コンパイルはMacが必要

Bezelがつかわれない理由
最近のXcodeビルドが、そんなに遅くない
リモートビルドの設定の難易度が高い
Xcodeとの相性が超悪い

であれば
CIサーバーに導入を目標にする
podなどは、ビルドに埋め込む

Googleが方向性を変更、Appleは対応しない方針だったが、転換

テスト編
いいテストの条件
実際のアプリに期待している行動と一緒

目的は、行動の変化がない限り、更新しない

テスト作成の原則
テストが失敗したら、アプリも失敗しているのが理想

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

SwiftUIに移行したほうがいい理由やしない方がいいケース、SwiftUIに移行する上で大事なこと、SwiftUIに移行した時のメリットなどの話

感想
実際のコードの例を紹介というより、どういったケースや考え方で、SwiftUIへ移行した方がいいのかという内容だったので、逆に、SwiftUIの情報が少ない自分には、ちょうどよかった。SwiftUIの導入の判断基準としては役に立ちそう

メモ

SwiftUIに移行した方が良い理由
UIKitはどんどん複雑になっている。今後はSwiftUIが主流になる

SwiftUIに移行しない理由
安定しない、バグが多い
パフォーマンスによっては、SwiftUIの方が悪い場合がある
ビジネスの優先順位

SwiftUIに移行する上で大事なこと
Objective-CからSwiftに移行しておく
コードもSwiftらしいコードにしておく
FRPに触れておく

SwiftUIに移行した時のメリット
AutoLayoutに対応
SafeAreaの概念への対応
Storyboardがスリムになる
ダークモードへの対応
宣言的なUIKitのAPIを使える

SwiftUIにマッチするアーキテクチャ
Redux
TCA
MVVM

SwiftUIをどの画面から実装するのがいいか
二つのアプローチ
AppDelegateやTabBarControllerなど、上位のものを対応するのは、大変。下位のVCに依存している可能性がある

Tips
同じ画面で混ぜすぎないこと→UIKitもSwiftUIどちらも概念が違う。画面単位で実装する方がいい

LTセッション

Catalystに対応したアプリをリリースするまでのリジェクト集 by かっくん

Catalystに対応したアプリをリリースするまでのリジェクト集 #iosdc #a #lt/iosdc_2020_lt - Speaker Deck
既存のiOSアプリをCatalyst化してリリースする際の苦労話
iOSとMacアプリでは、審査の基準が違うようで、単純にCatalyst化しただけではダメらしい

感想
Catalystについては、あまり情報がなかったので、これを機に知れたのはよかった
業務でもビジネス展開によっては、ありえるので、キャッチアップしておく必要がありそう

In App Purchaseのこれからの在り方を考える by Yuki Yamamoto

最近、トレンドになっているIn App Purchaseの件
自社(hey)とフォートナイトの話を交えて、今後のありかたを訴えるような内容でした

感想
個人的には、Appleとフォートナイトの件は、気になっていたので、似たような事例の話を聞けてよかった
今後は、アップルがガイドラインを変更したように、バグ修正以外の違反では即時リジェクトしないと言っている(実際、どんな運用になるかは分からないが）ので、今後の審査の変化はキャッチアップしていく必要がある

iOS Custom Keyboards でできること／できないこと／やってはいけないこと by Kyome

iOS Custom Keyboardsでできること/できないこと/やってはいけないこと / iOSDC Japan 2020 LT - Speaker Deck
iOSカスタムキーボード開発の話
実際の開発例をコード共に紹介
できること/できないことの他に、変わったキーボードも作れるよ

感想
デザインが未来的なキーボードや、罫線のみのキーボードや、楽器のキーボードなど、かなり自由に作れるんだなと分かって、実際に開発してみたい

DroidKaigiの公式アプリで始めるiOSアプリのOSSコミッターへの道 by 遠藤拓弥

DroidKaigiの公式アプリで始める_iOSアプリOSSコミッターへの道 - Speaker Deck
OOSコミッターをやってみたという話
最初のしくじりから反省し、こうすればいいよという内容

感想
OSSコミットは、やってみたいなと思うので、軽い気持ちでPR出したらダメだなという気づきと、やってみたいという気持ちになった

Apple Pencilと左利き対応 by ああうえ

Apple Pencilと左利き対応 - Speaker Deck
利き手を意識したUI設計の思考過程を紹介
HIGに基づいて検討し、実際に試行してもらったデータに基づき、決めていった

感想
実際の業務でも、アプリを片手で使うか、両手で使うかのような議論が出たこともあったので、単に机上の空論で決めるのではなく、実際の試行結果から、データに基づき決めていくのが重要だなと共感

macOS仮想カメラ「テロップカム」実装方法とその先 by 服部智

macOS仮想カメラ「テロップカム」実装方法とその先 - Speaker Deck
仮想カメラの実装の仕方を、実際のコードを元に紹介

感想
仮想カメラは、VRやARに興味を持っていたときに、いろいろ触っていたので、面白かった。ただ、以前、触っていたのは、別の言語とライブラリだったので、iOSでの実装例が見れてよかった

文字列をコピーできるスクリーンショットを作る by えんどう

文字列をコピーできるPDFを作るにはどうすればいいかの話

感想
あまり、、内容覚えてないな。。集中力が切れてたかも。汗

あなたのアプリ、✨リブランディング✨できますか？ by monoqlo

あなたのアプリ、✨リブランディング✨できますか？ / iosdc2020 - Speaker Deck
リブランディングを伴う複数回に及ぶリニューアルの話

感想
あまり、、内容覚えてないな。。集中力が切れてたかも。汗

iOSアプリを譲渡！？失敗は許されない一発勝負！予想外に立ち塞がる様々な罠に挑んだストーリー🙌 by じんむ

iOSアプリを譲渡！？失敗は許されない一発勝負！予想外に立ち塞がる様々な罠に挑んだストーリー / ios app transfer - Speaker Deck
iOSアプリを譲渡申請したときの、苦労話

感想
アプリ譲渡に関しては、前職で過去に検討したことがあって、実際に譲渡申請はやらなかったが、だいぶ大変そうだなというのは、感じていたので、実際の苦労話を交えて、注意するポイントなどが聞けたので、自分の知識の一つとしていい話が聞けた
スピーカーの話し方が、絵本を読んでくれてるような話し方で、とても面白かった

その他の見たセッションで感想

ここに書いてないセッションの感想を、以下のページに分けて、書きましたので、こちらもどうぞ
iOSDC2020のday0に参加したセッションの内容と感想 - Qiita
iOSDC2020のday2に参加したセッションの内容と感想 - Qiita
iOSDC2020に参加して３日間で36のセッションを見ました - Qiita