iOSDC JAPAN 2020 感想 自分用メモ
iOSDCの概要
iOSDC JapanはiOS関連技術をコアのテーマとした技術者のためのカンファレンスです。今回はオンライン開催です！ iOSDC Japanと言えば日本中、世界中から公募されたスピーカーによる知的好奇心を刺激するトークと参加者間のコミュニケーションですが、オンライン開催となる今回も変わらず、そして今まで以上にお楽しみ頂ける企画を検討中です。 開催に関連するニュースは本サイトのお知らせや公式Twitterアカウントでお知らせします。是非フォローしておいてください。
開催概要 開催2020年9月19日（土）〜9月21日（月・祝） 場所オンライン 対象iOS関連技術およびすべてのソフトウェアエンジニア 主催iOSDC Japan 2020実行委員会 （実行委員長 長谷川智希 @tomzoh）
コメントが多かったトーク
全体の感想
- ニコ生について
- そもそもニコ生をあまりみないのでシリアルコードの入力など戸惑う
- 家のネットワーク環境の問題かニコニコの問題か、高画質で見ると音が飛び飛びになる
- リアクションが文字なので独特
- 内容について
- その他
自分が聞いたトーク
- 9/20
- 9/21
9/20
Background Notificationで新聞紙面の大きい画像の自動ダウンロードを実現する / Takagi Go
- 背景
- コンテツの自動ダウンロード
- 快適なユーザ体験
- 通信環境
- 的配信コンテンツ
- 寝ている間にアプリへ配達
- ユーザーを逃さない
- 通信量はそれなりのサイズ
- コンテツの自動ダウンロード
- iOS Background Mode
- Background Mode
- 制約
- Backgroundでダウンロードする方法
- Background App Regresh Task(iOS 13.0+)
- Background Notification(iOS7.0+)
- push型
- 許諾は必要なし
- Background Transfer Service(iOS7.0+)
- 「Background Notification(iOS7.0+)」採用
- Background Mode
- 全体的なアーキテクチャ
- 細かいTips
- Background Notificationの性質に対処
- 実行確率を上げるため、複数回送る
- Background Notification自体を複数種類作らない
- OS側が止めてしまうことを前提としたロジック
- 排他制御のミスに気をつける
- 最小限の単純なロジックにする
- 提示できる状態はなるべき明示的に周知
- Background Notificationに通知の許諾はいらない
- Background Push Notificationの動作確認
- 通知が必要なので、基本的に実機が必要
- （ちなみに）Simulatorで通知を操作する
- 運用すると課題が見えてくる
- アクセスのピークが発生する
- 端末側の問題
- 端末による成功率の違いが如実に
- OSによって落とされにくいアプリへと改善する
- Background Notificationの性質に対処
- 安定して受け取るために
- 利用するBackground Modeの選択
- 動かしたい時間帯の考慮
- アプリ本体は健康
100人でアプリをリファクタリングして見えてきた、最強のiOSアプリ設計に求められること / Yuta Koshizawa
- 設計に見られた共通項
- Presentation Domain Separation
- Presentation（UI）とDomain（ロジック）を分離する
- Clean Architecture
- モジュールを分ける方法
- Enterprise Business Ruleの分離
- Enterprise Business Ruleとは、アプリに依存しない汎用的なルール
- オセロ
- Disc・・・おせろ、白黒の状態を持つ
- Board・・・オセロの数、挟んだら色が変わる
- Game・・・ゲームの状態（ゲーム中/終了）、どちらの番とか(対戦相手がマニュアルかコンピュータかはゲームに含めない)
- 状態遷移の整理
- 依存関係逆転の原則(DIP)
- デリゲートで依存関係を逆転される（Presentation -依存-> Domain の形にする）
- 他の方法
- DI
- Combineによる変更通知、値型による変更通知
- 一方向のデータフロー
- 静的型の活用
Flutter移行の苦労と、乗り越えた先に得られたもの / 桐山圭祐
- Flutterとは
- Google製のクロスプラットフォームSDK
- 開発言語：Dart
- 話すこと
- Flutterを採用して実際どう立ったか
- どんな技術的課題に直面したか
- 乗り越えた時のメリット
- Flutterを採用して実際どう立ったか
- じゃらんおFlutter移行
- 10年を迎えリプレイス
- クロスプラットフォーム技術の検討
- 前提の共有
- Flutterへの段階的移行
- Add-to-appを使用
- FlutterViewController
- FlutterView
- FlutterEngine ← Dartのコードを実行している
- 既存のネイティブプログラムに組み込む
- Add-to-appを使用
- Flutterのレイアウト構築
- Flutterへの段階的移行
- 直面した課題
- タブ切り替えのパフォーマンス
- リストのアイテムを大量に読み込んでタブを切り替えると重い、またはクラッシュする
- どう回避したか
- AutomaticKeepAliveClientMixinを適用することで、画面をクリアさせない
- Flutterの画面が初期化されない
- Flutterの画面を再度開くとFlutterの画面だけ、前回の画面が残る
- どう回避したか
- FlutterViewControllerは初期化されていたが、FlutterEngineが初期化されていなかった
- FlutterEngineを初期化すると時間がかかる
- 初期画面を明示的に呼び出す処理を書く
- ネットワーク通信がproxyサーバを経由しない
- Flutterだとproxyサーバを経由できない
- どう回避したか
- PACを指定する
- Google Mapのクラッシュ
- 直面した課題まとめ
- 致命的なものはなかった
- メリット
新規機能開発からモジュール分割を始めてみる / Ryo Izumi
- マルチモジュール
- 大規模リファクタリングが必要
- その間も新機能で太っていく
- 新規機能からモジュールを分割する
- 新しい施策の機能をモジュールに分割する前提で設計する
- 手順
- 要件、使用の整理
- 責務を決める
- input/outputを定義
- framework
- 開発
- メリット
- 共通化すべき部分が見えてくる
- 既存コードに囚われなくなる
- 影響範囲の縮小
- デメリット
- プロジェクトファイルのコンフリクト
- XcodeGenを導入するべきだった
- モジュール分割の単位が機能単位になる
- 抽象度が上がるので実装がどこにあるか分かりにくくなる可能性
- プロジェクトファイルのコンフリクト
エラーアーキテクチャ設計について考える / きちえもん
- モチベーション
- エラーをいい感じに扱いたい
- 環境
- RxSwift
- エラーの種類
- enumで定義することでなんのエラーがあるかわかる
- 固有エラーは個別定義
- 問題点
- エラーケースを方で表現できない
- エラーケースの漏れが発生
- 機能固有のエラーケースを個別に処理できない
- 改善
- 型で制約をかける
- 列挙型を利用する
- 固有エラーは個別に処理する
- ２種類のユースケース
- 基本コース：晴れの日のシナリオ
- すべてが上手く行ったシナリオ
- 代替コース：雨の日のシナリオ
- 何かしらうまくかなかったシナリオ
- 基本コース：晴れの日のシナリオ
- 雨の日のシナリオを考えるのがエラーアーキテクチャ
- エラーアーキテクチャ設計まとめ
iPadOSDC: Multiple Windows / ひろん
- iPadOS
- Multiple Windows
- 複数のスペースで同じアプリを開いて作業する
- メモの動作
- SplitViewで同じアプリの別ウィンドウを並べられる
- メモのアイテムをドラックすると別のウィンドウを開くことができる
- Appスイッチャーや、AppExposeでウィンドウを閉じることができる
- 予備知識
- １つのアプリのプロセスは従来どおり１つ
- ここまで「スペース」や「ウィンドウ」とよんできたものは「シーン」に相当
- 全面に表示されていないシーンは切断されたり、そもそも接続されてなかったりする
- 登場人物図
- サンプロコード
- MultipleWindowsSample github
- （commitのログなどから作るのがわかりやすそう）
- Step 1 シーンは簡単
- Xcode11で新規プロジェクト作成
- iOS13以降で考える（iOS12で対応すると大変）
- info.plist に Scene Manifest を追加
- SceneDelegate クラスを作る
- 今までは画面のライフサイクルに関する通知はAppDelegate
- Sceneごとにの通知はSceneDelegateが呼ばれる
- AppDelegate から SceneDelegate へ引っ越し
- Xcode11で新規プロジェクト作成
- Step 2 複数のシーンをサポート！戦いの始まり
- Step 3 シーン状態の保存ならオレにまかせろ
- NSUserActivity
- アプリの状態を表現するクラス
- OSからの要求に答える
- 状態の復元
- 状態の保存はシーン API の機能
- NSUserActivity
- Step4 プログラムから新しいシーンを展開
- Step4(2) プログラムから新しいシーンを閉じるようにしたい
- その他のトピック
- シーンのライフサイクル
- シンクロナイズドシーン
- 片方の画面を更新したらもう片方に反映したい
- 特別な方法があるわけではない
- KVM、NotificationCenter、Combine、他
- データが単方向に流れていると同期しやすい
- シーンのライフサイクル
効率よくUIKitからSwiftUIへ移行する / josh
- Why move to SwiftUI
- 少ないコードで実装できる
- アクセシビリティ、ダークモード、マージンなど
- 少ないコードで実装できる
- Why not move to SwiftUI
- バグが多い
- 古いOSに対応していない
- 複雑な画面に対応できない場合がある（ヒューマンインターフェースガイドラインに準じていない場合もある）
- Modernize Swift usage
- Objective-CをSwiftへ移行する
- Swiftのバージョンを新しくする
- Modernize UIKit usage
- Storyboardを分ける
- Plan and prototype
- プロトタイプのアプリを作って、実験する
- Architecture
- SwiftUIに向いているアーキテクチャ
- Redux
- The Composable Architecture(TCA)
- MVVM
- SwiftUIに向いているアーキテクチャ
- Two approaches
- 末端の画面からSwiftUIへ変更している
- Tips
- 画面内でUIKitとSwiftUIを混ぜない
- 簡単な画面からSwiftUIへ切り替えていく
- 急ぎすぎない（無計画に進めると大変なことになる）
- SwiftUIとCombineを事前に勉強しておくことが大事
ライトニングトーク
- Catalystに対応したアプリをリリースするまでのリジェクト集 / かっくん
- Macだと考えることが少し多い
- In App Purchaseのこれからの在り方を考える / Yuki Yamamoto
- ガイドライン≠ルール
- iOS Custom Keyboards でできること／できないこと／やってはいけないこと / Kyome
- できること
- 好きなキー配置、特殊な記号、背景を変更
- できないこと
- キーボードだけをAppStore配信できない
- やってはいけない
- 余計な機能を搭載
- できること
- DroidKaigiの公式アプリで始めるiOSアプリのOSSコミッターへの道 / 遠藤拓弥
- 修正が認められなかった
- issueに取り込む前に修正範囲を明確にしていなかった
- 確認が足りなかった
- この経験を活かして次は修正したところ無事コミットできた
- 修正が認められなかった
- Apple Pencilと左利き対応 / ああうえ
- ツールバーの位置について（右利きは右側、左利きは左側）
- ダークモード対応とAutoLayoutアニメーションと私 / Abebe
- macOS仮想カメラ「テロップカム」実装方法とその先 / 服部 智
- CoreMediaIO DAL Plugin
- NSPasteBoard
- 文字列をコピーできるスクリーンショットを作る / えんどう
- なぜPDFは文字列をコピーできるのか
- PDFに文字情報を持っている
- なぜ文字列をコピーできなかったのか
- 文字情報を持っていなかった
- 文字列をコピーできるPDFを作るには
- ViewをそのままPDFに出力する
- なぜPDFは文字列をコピーできるのか
- あなたのアプリ、✨リブランディング✨できますか？ / monoqlo
- iOSアプリを譲渡！？失敗は許されない一発勝負！予想外に立ち塞がる様々な罠に挑んだストーリー / じんむ
9/21
詳解Storyboard / 日向強
- UIHostingController
- 内部にSwiftUIを持つことができるViewController
- IBSegueAction
- リストア機能
- Restoration
- SceneDelegateでは使えない
- Restoration
- Storyboardを分割する
- Localization
- テキストにundoをつける
- OSバージョンごとにStoryboardを差し替える
- 様々な画面に対応する
- ActionはObject化する
- Delegate
- Collectionで返すと複数のActionを呼べる
継続的にアプリのパフォーマンスを計測する / kariad
- アジェンダ
- なぜパフォーマンス計測が必要なのか
- iOSアプリにおけるパフォーマンス計測
- 継続して計測する仕組みの作成
- 運用してみて
- これから
- なぜパフォーマンス計測が必要なのか
- 重い、クラッシュする
- iOSアプリにおけるパフォーマンス計測
- 代表例
- Instruments,MetricKit、外部サービス
- Instruments
- どこのパフォーマンスが悪いのか分析、特定する機能をサポート
- MetricKit
- iOS13から利用可能
- 起動時間、CPU使用時間、バッテリー消費、クラシュなど
- ユーザの操作の計測
- 外部サービス
- FireBase、HeadSpin
- 代表例
- 継続して計測する仕組み
- パフォーマンスが悪くなってからでは遅い
- 継続的な計測で必要なもの
- アプリ操作用のUITestフレームワーク
- Appium
- アプリに負荷をかけるツール
- この構成で起きた問題
- 実際に運用してみて
- 問題点
- Appiumの不安定さ
- 実行パターンの増加
- 季節
- インカメラの利用
- 結果確認フローの問題
- 運用した結果の変更
- 問題点
- これからの展望
- xctrace
- Xcode12からInstrumentsコマンドがdeprecatedとなりxctraceが追加された
- Bitrise(MacStadium)への移行
- 他項目の計測
- FPSなど
- xctrace
「クックパッドが、革新的な方法でまったく新しい買い物体験を皆様にお届けします」 / 藤坂 祐史
- 全く新しい買い物体験 クックパッドマート
- 課題
- 実店舗だと品揃えや並びなど
- ネットだと送料や１品だと買えないなど
- クックパッドマート
- 送料無料で1品からでも買える
- 専用冷蔵庫
- 好きな時間、好きな場所で受け取りOK
- 注文アプリ、配送アプリ
- 技術的な取り組み
- 配送アプリ・・・配達員専用アプリ
- ドライバの位置情報を常にオンにする
- puree
- 配送アプリ・・・配達員専用アプリ
- クックパッドアプリの「買い物」機能
- レシピから買い物へ
- 新機能の画面はSwiftUIで実装している
- SwiftUIを導入すべきか？
- SwiftUIで良かったこと
- Viewの組み立てが楽
- 状態のあるUIがわかりやすい
- データを入れるだけで、良きに再描画される
- コンポーネント単位で使いまわし、可変しやすい
- スタイル調整も楽
- Viewの組み立てが楽
- 課題
大解剖！UIColorファミリー / しもとり
- 話すネタ
- UIColorにはサブクラスがいっぱい
- サブクラスの紹介
- UIColorのサブクラス自作は結構難しい
- UIColorのメソッドの挙動を見る
- UIColorにはサブクラスがいっぱい
- サブクラスは18個ある
- デザインパターン
- Class Cluster
- サブクラスが複雑な処理をしてくれる
- Class Cluster
- サブクラスの紹介
- UIPlaceHolderColor
- 何か特定の色を指しているわけではない
- UI(Cached)DeviceRGBColor
- RGBで指定される色のクラス
- UIDynamicColor
- traitの変化に応じて動的に変わる
- systemBlueなど
- Asset Catalogから得られる
- traitの変化に応じて動的に変わる
- その他フレイムワーク
- UICIColor
- CIColorを受け取って
- UIPatternCGClor
- NSColor
- UICIColor
- UIColorのサブクラス自作は結構難しい
- UIColor直下に作る簡単なものならOK
- privateのサブクラスに作るのは難しい
- UIColorのメソッドの挙動を見る
- isEaual(to:)
- 同じ色でもサブクラスが違うと等しくならない
- isEaual(to:)
SwiftUIを導入したアプリ設計 / Yu Tawata
- アジェンダ
- 設計の目標
- SwiftUI
- 課題
- 検証
- アーキテクチャ
- フロー
- まとめ
- 設計の目標
- SwiftUI
- 考慮すべき要件
- 機能
- 複数のアプリ起動経路
- 非機能
- アナリティクスの画面遷移
- 機能
- 複数のアプリ起動経路
- UIKitの場合
- Coordinator
- SwiftUIの場合
- トラッキングが難しい
- UIKitの場合
- UIKitをベースにしてSwiftUIを実装する
- 考慮すべき要件
- 検証
- 次のクラスでSwiftUIを利用できるか
- UITableView
- UICollectionView
- 次のクラスでSwiftUIを利用できるか
- アーキテクチャ
- フロー
Apple Silicon への長い道 / hak
- SoCの歴史
- AAPL0098
- AAPL0298
- AAPL0398 / A4
- AAPL498, 2498, 7498 / A5
- AAPL5498 / A5X
- A6 / X
- A7
- 64bit
- A8 / X
- A9 / X
- A10 Fusion / X
- Big/Small コア
- A11 Bionic
- A12 Bionic / X / Z
- A13 Bionic
- Apple Silicon
ライトニングトーク
- 本当はこわいLLDB / みやし
- Objective-Cだと中身が結構見れる
- iOS 13における Siri Shortcuts 最小実装+α / 明渡麻衣花
- NSUserActivityを利用する
- xcrun Essentials / Yutaro Muta
- xcrunとは
- コマンドラインからCcode内の任意のツールを検索または実行する
- xcrunを使う
- xcrun simctl
- xcrun xccov
- xcrunとは
- Swiftで分かるSOLID原則 / 川口 航平
- 単一責任の原則
- リス古布の置換原則
- 依存性逆転の原則
- SwiftUIとFlutter / tamappe
- Flutter最高
- SwiftUIとFlutterは似ている
- コンポーネント
- レイアウト
- TableView & Collection
- 100人以上の中高大学生にiOSアプリ開発を教えていて感じたこと / とし
- プログラミング
- 一緒にやる、自分でやってみるのフロー
- 何度でも説明など
- アプリについてきちんと考えられるのか
- プログラミング
- Feature Flagを適切に分類することでA/Bテストの運用コストを下げる / Takeshi Ihara
- A/Bテスト + Feature Flag
- Feature Flagの分類（生存期間、変更規模を考える）
- Release Flag
- Ops Flag
- Permission Flag
- Experiment Flag
- CryptoKitとCoreBluetoothを利用したスマートキー開発 / saiten
- 車の鍵をiPhoneで開く
- RxBluetooth
- CryptoKit
- Apple Low-Latency HLSを使った超低遅延配信について / meteor
- 遅延
- HTTP Live Streaming
- CMAF
- 着信時氏名表示させたいエンジニア vs 簡単には着信時氏名表示できない電話番号 (iOS13対応版) / 栗山 徹
- 0はじまりでない電話番号で氏名が表示できない
