概要
iOSDCの1日目に参加しました。
僕の気になった内容メモと感想をまとめる記事です。
見たトークは、
- Apple Pencil対応の勘所を話します
- 100人でアプリをリファクタリングして見えてきた、最強のiOSアプリ設計に求められること
- 新規機能開発からモジュール分割を始めてみる
- ベジェ曲線の知らない世界
- GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス
- 効率よくUIKitからSwiftUIへ移行する
iOSDC全体
ガイダンスの声優に緒方恵美さんや三石琴乃さんが出てきてすごい！
スポンサーの説明がなんかすごくてテンション上がりました！
テンション上がってノベルティのTシャツを着るという流れです。
Apple Pencil対応の勘所を話します
プロポーザルはこちら
スライドはこちら
- 紙のようにかけるアプリを開発。iPad&apple pencilを持っているのになぜ自分は紙でメモをとっているのかという疑問から着想。
- Apple Pencilの書きっぷりは紙に近いものがあるが、書くまでのフローが多いので、問題はハードではなくソフトにあるのではないか。
- ダウンロードは4330あるが、日本は20程度。英語対応が大事
- WWDC 2019で登場したPencilKitはそこまでUIのカスタマイズはできない。
- 指で描くのはDeprecated
- PKCanvasViewは3行で導入可能！
- PKDrawingは順序や書いた日時などのメタデータがないため、モデルにして持たせると良い
- Imageの出力はライト、ダークモードに応じて出るので、生成後モードを変えると白飛びしたりする。モード反転のタイミングでリロードすることで対策できる。
Apple Pencil対応楽しそうでした！
英語対応は必須だと思いました！
100人でアプリをリファクタリングして見えてきた、最強のiOSアプリ設計に求められること
プロポーザルはこちら
リバーシのリポジトリはこちら
- リバーシを100人でリファクタリングチャレンジした
- みんなが取り入れている設計にはエッセンスがあるのでは？
- PDS(PresentationとDomainを分ける)
- import UIKit SwiftUIなどしてるところがpresentationで他はドメイン
- 依存関係がPresentation -> Domainになるようにする。Domainは単体ビルドできるようにする。
- DB Presentation NetworkなどテストしづらいものをDomainと分けてあげる。Clean Architectureでも言われている
- 基本的にどんどんPresentationにロジックが追加されるため、これをどれだけドメインにできるかが大事
- モジュールを最初に分ける方法には。Swift Package Manager, Framework Target, Framework プロジェクト + ワークスペース があり、それぞれ一長一短がある。
- EBR(Enterprise Business Rule) - アプリに依存しない汎用的なルール
- リバーシアプリならリバーシのルールそのもの。挟まれたら裏返すなど
- 例えばcellに3つの状態 .dark, .light, nilを持たせるとうまくいく
- 相手がManualやComputerを切り替えられるというのはDomainには含まない。リバーシのルールではないから
- EBRは他のリバーシアプリを作るときも再利用可能。(https://github.com/koher/swifty-reversi)
- 状態繊維の整理
- 状態遷移図を書くと良い
- プレイヤー待ちとコンピューター待ちを同一のものと考えてシンプルにしたりする
- DIP(依存性逆転の原則)
- 何も考えないとManagerなどからUIのViewController.labelなどを参照してしまう。
- DomainがPresentationに依存するので、デリゲートによるDIで解消する。
- やり方としては、PresentationでDelegate, CombineやRxSwiftを利用、値型のdidSetでキャッチ
- Swiftは値型中心の言語で活用すると良い(https://heart-of-swift.github.io/)。
- SwiftUIの
@Stateなどですぐできる。 - didSetではcount以外の変更を拾う場合があるが、SwiftUIは差分のみViewの実態に反映。SwiftUIは値型とすごく相性が良い
- 一方向のデータフロー
- reduxを参照
- 値型をmutableで扱うのはとてもswiftyになる。
- 静的型の活用
- DiskのdarkやlightはIntで表すこともできるが、enumで分けると実行次エラーが起きないようになる。
設計で参考になる部分が多かったです。また見たいです。
新規機能開発からモジュール分割を始めてみる
プロポーザルはこちら
スライドはこちら
- 機能開発と並行してモジュール分割を行った話
- 最近1つのアプリが多機能化している。
- Embeded Frameworkなどを利用しマルチモジュール化することで、差分ビルドでのビルド時間の短縮と責任分離による影響範囲の縮小を実現したい。
- 既存アプリは複雑でどこから切り出せば良いかわからないため、新規機能からモジュールの分割をするようにした。
- 責務を決めるときにどうしても既存機能を使いたい場合はフレームワークにinterfaceを切ってアプリから注入
- frameworkの作成はTargetの追加でframeworkを選択するだけ
- マルチモジュールのメリットとして、アプリ側のExtensionで使いたいものがある場合、それをさらなる共通モジュールにすれば良いとわかる
- 既存コードの汚さによるモチベーション低下を防げるのもメリット
- プロジェクトファイルのコンフリクト解消でやらかしたのでXcodeGenを使うと良い
- どこに実装があるかわかりにくくなる。コードに触れる全員が知識を共有しておく必要がある。
実際の体験を元に話されているので、メリットデメリットや失敗しやすい部分がわかりやすかったです。
ベジェ曲線の知らない世界
プロポーザルはこちら
Qiitaはこちら
- めっちゃ数式変換
- ベジェ曲線をフリーハンドで描くやり方教えてくれた。
- 第一次部分係数と第二次部分係数が一致しないと、ポリベジェ曲線は滑らかにならない
- 手書き文字を滑らかにするアプリで、制御点は4点得る必要があり、2点はアプリからもう2点は計算から求める。
- 発表の声は声優さんの卵の方に原稿を読んでもらって吹き替え
声優さんに吹き替えてもらって発表はリモートならではだなと思いました！よかったです！
ベジェ曲線もイラレなどで触れることがあったので、少し理解が深まってよかったです。数式には完全に置いて行かれましたが、ニコ生のコメントもあり楽しめました!
GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス
プロポーザルはこちら
スライドはこちら
- CIの良さは、リモートリポジトリに問題がないことが保証される、手間がかからない、環境に依存しない。
- CIのデメリットはCI環境構築の学習コスト、ワークフロー作成、CIサービスの選定
- CIに必要なのはmakeなどのタスクランナーと、CIツール(github actions)
- テストと静的解析はトリガーを分けたいのでワークフローを別にする
- あとはハンズオン!(https://github.com/uhooi/iOSDC2020-Talk-Sample)
効率よくUIKitからSwiftUIへ移行する
プロポーザルはこちら
スライドはこちら
参考: https://twitter.com/yhkaplan/status/1307509520868941824
- なぜSwiftUIへ移行するか
- 少ないコードで多くのことができるから
- モダンなUIを少ないコードで実装できる。アクセシビリティやダークモードなど。プラットフォームごとのマージンやレイアウトにも強み
- なぜSwiftUIに移動しないか
- 若いのでバグが多く、OSのマイナーバージョンでバグが変わったりする。
- iOS12以下のバージョン対応はできない
- 低レベルの処理でハイパフォーマンスが必要な場合は使えない
- 計画なしにSwiftUIとUIKitを混ぜると辛くなる
- SwiftUIはHuman Interface Guidelineにしたがって作られているので、移行しにくい場合はそこに準拠していない可能性がある。
- ArchitectureはRedux, MVVM, TCAが考えられる。
- プロトタイプは他のアーキテクチャを試す良い機会なので、チャレンジすると良い
- 移行は依存されていないものから始めると良い
- Swift UIとCombineは予め勉強すると良い。実装する中での勉強だと目の前のことしか考えず、全体像を忘れがちになるから。
初心者のため、学習すべきところがよくわかってよかったです。
感想
とても楽しく過ごせました！
Swift UIとCombine、Redux、TCAがトレンドですね。