yamakenの呟き

【iOSDC Japan 2021】セッションの概要&感想まとめ

f:id:yamakentoc:20210920212757j:plain

今年もiOSDCに参加してきました。

去年に引き続きオンライン開催となりましたが、セッションの方は興味のあるものが多く、知見の塊でした。

ここでは、自分が見たセッションの概要と感想を軽くまとめます。やっぱりこういうのって自分の言葉で振り返らないと忘れてしまうので大事ですね。

 

Day0

大規模リファクタリングの極意

約1年間かけて大規模サービスのリファクタリングを見事成功させた時の方法や知見がまとまっていて、今後リファクタリングする際の参考になりそうです。

特に、リファクタリングをしないと負のスパイラルが生まれる、陥ってしまうというのは、日々コードを書いてて感じます...。

事業案件開発チームとリファクタリングに専念するチームに分けるのは大胆というか、1年かける大規模リファクタリングなのでそこまでやらないといけないんだな〜と。

Danger(プルリクの作法に則って自動で指摘するツール)は初知りでした。

 

SwiftUIで作ったアプリを1年間運用してみて分かったこと


普段開発しているアプリでもそろそろSwiftUIを導入したいなと思っていたので、このセッションを聞けて良かったです。

iOS13をサポートした状態でSwiftUIを導入していくにはまだ課題が地味にあって難しいというのは意外だったし知見でした。

他のトークでもiOS13の時点ではSwiftUIが未成熟なので活用するのは厳しいといった意見もあったのでiOS13のサポートを切るまで待つべきかどうか…と少し悩みそうです。

SwiftUIで実プロダクトを音速リリースした話

まず、スピーカーであるAkkeyLabさんの話し方などのプレゼンの仕方がとてもうまくてとても印象に残りました!

プロダクトでSwiftUIを95%使用しているというのは、「あ、ここまでできちゃうんだ」と少し驚きました。でも100%まではいかず、やはり残り5%はUIKitを使わないといけないんですね。

SwiftUIを用いることで、アニメーションも簡単に実装できるし、XcodePreviewsを用いることでPDCA的な感じで早くチーム間での共有ができるのは魅力的!

そのプロダクトも1人で開発したとのことだったので、スピード感重視していくならSwiftUIが良さそうですね

UIKitとSwiftUIでの装飾ボタンを作る時の比較が、圧倒的にSwiftUIの便利さを表しているのは良い例でした。

 

Initiatives in Rakuma iOS App

Compositional Layoutsで実現する疎結合な実装


Compositional Layouts : 縦にも横にもスクロールできるCollectionView

SwiftUIではCompositional Layouts的なレイアウトを現状実現できないし、画面が自動でリフレッシュされるので状態を保持できないため、プロダクトではSwiftUIを採用してないとのこと。

Compositional Layoutsはレイアウトが増えるとViewControllerの肥大化につながる。

そこで、ViewControllerからCompositional Layoutsを切り離すことで、疎結合となり、コード量が増えても肥大化に繋がらないという手法。

レイアウトの抽象化をすることでかなり簡潔にコードが書けるので、Compositional Layoutsを使用する際に参考にします!

それにしても一見複雑化しそうなコードでもここまで簡潔に書けるものなんだな..

Qiitaにまとめられていた!

Half modal comparision in iOS15

iOS14以前だとハーフモーダルを実装するのはコード量も多く手間だった。

↓関連記事に実際のコードが載っているが、確かにこれを実装するのは手間。

 https://commerce-engineer.rakuten.careers/entry/tech/0024 

iOS15からはこんなにも簡単に実装できるけど、2つのサイズしか定義されてなくてカスタマイズできないし、更に親の画面のボタンなども触れてしまうから気をつけようというお話。

確かにiOS15からお手軽に実装できるようになっているけど、痒いところに手が届かなそうだなーと思いました。

かといってiOS14以前のように大量のコードを書くべきなのか。iOS15以上サポートでハーフモーダルを実装することになったら悩みそうですね。

 

Day1

Source Editor ExtentionとSwift Syntaxでコード自動生成ツールを作る

コードの自動生成手法としてSource Editor ExtensionとSwiftSyntaxを組み合わせたものを提案していた。デモでは、DIを簡単に実装するためにツールを用いて、クラスからプロトコルを自動生成し、更にそのプロトコルからモックを自動生成していた。

ボタンをポチポチするだけで、期待するコードを生成することができるのは便利ですね。

コード自動生成ツールは複数ありますが、コードを編集しながら実行可能かつ、macOS Appとして配布可能なのが特徴らしい。

自分が作った自動生成ツールを配れるのはもちろん、他の人が作ったツールを使えば更に開発効率アップしそうで流行って欲しい…!

 

機能ごとに動作するミニアプリでプレビューサイクルを爆速にした話

大規模なアプリをビルドするとビルド時間が長くなるため、1機能に関連する画面を1モジュールとして切り出すことでビルド時間を短縮し、爆速に動作確認できるというお話。

自分が普段関わっているアプリも大規模アプリの類なので、ビルド時間長いのはいつも課題に感じてるのでめちゃくちゃ魅力的な内容でした。

外部ライブラリや他のfeatureモジュールに依存しちゃいけない課題や、そもそもチームで利用してもらうための課題など、仮に自分が関わっているアプリに導入するとなれば結構難易度高いなぁ〜と思いました。。。でもその課題を解決した方が結果的にプラスになりそうですね

↓テックブログにまとまっていた!

https://techlife.cookpad.com/entry/2020/08/05/090000

それにしてもほぼ1週間に1回リリース入れてるのすごい…

 

StoreKitのこれまでとこれから

まとめるとこんな感じ↓

自分も旧StoreKitで課金機能の実装をしたことがありますが、かなり手間だったのを覚えています。追加するコード量もまあまああるが、StoreKit2ではたった1行で目的の処理が書けたりなどで劇的な進化を遂げていてワクワクしました!

ただ、今のところiOS15未満では使えないのは仕方ないというか残念ですね。

機能ごとに1つ1つ旧StoreKitとStoreKit2の比較をしていたり、購入処理フローの図を解説のたびにスライドに挟んでいたりしてめっちゃわかりやすかったです👏

 

noteのiOSアプリで実装したアクセシビリティの全て

そもそものアクセシビリティの定義や原則などに触れ、実際に受けたユーザからの問い合わせをきっかけにnoteのiOSアプリのアクセシビリティを向上させたというお話。

このセッションは知見の塊でした!自分も直近でアクセシビリティ(VoiceOver)の対応をする予定で、まだ深いところまで触れられてなかったので非常に勉強になりました!ありがとうございました!

今回の内容がnoteにもyoutubeにもまとめられていた!

https://fromkk.me/n/n2dbeb54cdf0d?gs=26eccf78b8bf

https://youtu.be/rDX_tJ7t28M

 

宣言的UIの状態管理とアーキテクチャ - SwiftUIとGraphQLによる実践

状態管理アーキテクチャの歴史を振り返りつつ、それぞれの特徴を1つのサンプルを用いて解説していてわかりやすかったです。

それぞれのアーキテクチャの細かいところまでは自分の知識では理解できなかったところもありますが、最終的にGraphQLの方が他のアーキテクチャと比較しても考慮することが少ないし、メリットもデメリットもあるというのがわかりました。

「GraphQLはいいぞ!」というのが伝わってきました!

 

Finder Sync ExtensionでMac向け便利ツールを作ろう

DropBoxやGoogleDriveのような、ローカルとリモートでファイルを同期するための拡張機能であるFinder Sync Extension。これをアプリを同期する以外に流用し、常駐型ユーティリティツールを作ろうというお話。

これには聞いた時には良い意味で発想がすごいなぁ…と思いました

実際に作ったツールとして、開発に使用する画像の@2x, @3x向けの画像を自動生成しているのを見て、これは何か作ってみたい!となりました!

 

スタディサプリ」がFull SwiftUIを選択した先に見えてきたもの。

プロダクトにSwiftUIを全面的に採用した時に得たものをまとめていた。

他のセッションでも聞きましたが、やはりSwiftUIはアニメーションに強いんですね。

デメリットとしてライブラリがまだSwiftUIに未対応なのか挙動が変になることがあるらしい。

他にも画面遷移時のTipsなど、まさにこれからSwiftUIを採用していきたい自分としてはありがたいセッションでした!

 

 

Day2

ランタイムデバッグのススメ

ランタイムデバッグ(実機デバッグ)のコツや運用方法について解説していた。

ショートカットを使用してアプリ自身を再起動させる方法を提示していて、こんなことできちゃうんだなーと。

あとはReplayKitのRPScreenRecorderを用いることで、操作の15秒前までを記録することができ、「なんか重い」などの定性的な意見を裏付けることができるというお話など。

これめちゃくちゃ便利ですね!常に裏で録画し続けていてデバッグ用のボタンなどをタップした時に録画を止めるとのこと。ただ、iOS15からしか使えないのが残念…!

DebugMenuというライブラリを作成したようで、パフォーマンスの常時表示機能や、常にデバッグメニューのランチャーを画面に表示したり、他にも便利そうなデバッグ機能があって便利そうですね

https://github.com/noppefoxwolf/DebugMenu

 

Hello, Swift Concurrency world.

Swift Concurrencyとは?から、その中の機能やルールなどについて詳細かつわかりやすく解説していた。

自分は全然async/awaitなどもあまり詳しく把握できてなかったので、今回のセッションで大体把握することができて良かったです。

スライドが綺麗にまとまっていましたし、何よりスピーカーのshizさんの解説がわかりやすかったです!

スレッドモデルや、その処理の細かい挙動など、こんなに詳細かつ丁寧に解説しているスライドはあるのか?と思うほどタメになったので、今後ここらへんを実際に使用していくときに見返したいと思います!

 

KMMを使って感じたPros/Con

KMM(Kotlin Multiplatform Mobile)は、iOSAndroidビジネスロジックを共通化できるSDKで、これをWantedlyで導入したときのお話。

UIとビジネスロジックを分離して、ネイティブ側ではUIの実装に集中できるの良いですね。ただ、型パラメータが失われる問題があって回避ためのラッパーが必要というのは実際に導入した時ハマりそう。

導入する前提として、iOSAndroidのチームがそれぞれ近い距離・存在でなければいけないのは結構壁になりそうですが、Wantedlyではそこもクリアしているので組織として素晴らしいなと思いました!

 

ケースに応じたUICollectionViewのレイアウト実装パターン

UICollectionViewを用いたレイアウトを実装する際に複数のパターンがあり、どれを選択するのがいいのか迷う。そこで、どういったケースでどのパターンを採用するのが適切なのか?というお話。

UICollectionViewLayoutの各パターンの特徴をおさらいしてからそれぞれの利用ケースを言語化し、設計例を挙げていた。

Layoutに関しては毎回実装する度に「どれがどうなんだっけ…?」と毎回調べていましたが、このセッション(スライド)でうまくまとまっていたので今後はこれを見直すことになりそうです。

他のセッションでも見ましたが、CompositionalLayoutsで大体なんでもできるからそれをまず使うのを検討した方が良さそうですね。

 

UICollectionViewの最新のAPIを使いましょう

セッションの説明欄の一行目に「UITableViewはもう捨てましょう!」と書いてるのには笑いました。セッションでも触れてるように、iOS14からはCollectionViewでUITableViewのようなList表示が可能となっており、UICollectionViewを使った方が拡張性が高く、わざわざUITableViewを使用する必要はないとのこと。

「とりあえずUITableViewで実装するのは時代遅れ」は肝に命じておきます。

ただ、UITableViewにしかないカスタマイズを行う時や、セルフサイジング(AutoLayoutによる高さの自動調整)するセルを実装する際は、動的に高さを変更するにはUICollectionViewが苦手なため、UITableViewを使用した方が良い場合もあるとのこと。

iOS15でのアップデートなどを見ると、今後Apple的にもUICollectionViewを拡張していくのかな?

UIKit DynamicsというAPIを使用することで物理学的な動作を表現できるのは初知りでした。バウンスするUICollectionViewのレイアウトに使えるとのこと。コード量が増えそうなのでOSSにも色々あるのでそっちを利用するのも良さそう。

 

Swift Package中心のプロジェクト構成とその実践

こちらは本題に入る前に前提知識を1から説明しており、本題での話もさっと入るようになりました。この前提知識の部分もなんとなくでしか理解できてなかったので助かったのと手元の方で更にまとめて理解が深まりました!圧倒的感謝です。

そして本題のSPMの話なのですが、SPMを使用するときの基礎的な話から始まり、実際にプロジェクトで使用する際の流れを1つ1つ解説しており、今までCocoaPodsとCarthageを愛用してきた身としてもめっちゃわかりやすかったです。

あとはモジュールごとに分けられていることでMini-Applicationの状態にできたり、最終的にXcode Projectで管理するファイルが数種類しかないのも魅力的ですね

 

SceneKitを使ってアプリのクオリティを劇的に上げる

SceneKitを使うとことで簡単にアニメーションやエフェクトを追加することができ、これによってアプリのクオリティを上げることができるというお話。

個人開発は自分もしていますが、確かにクオリティには悩むことがあります。ちょっと凝ったアニメーションを追加したいときはOSSをそのまま流用していました。

スピーカーの方が個人開発で累計200万DLしているというのは驚きました。。。iOSDC 2019のLTを動画で見たのですが、かなりASOに力を入れているようですね。特にリリース後のDL数のピークが下がってきた時にASOを色々と試して更にそこからDL数を伸ばしたというのは、中々できることではないので尊敬します…!

 

最後に

今年のセッションはSwiftUIに関するものが多かった気がします。おそらくiOS15が出るとともにiOS12、もしくはiOS13のサポートを切って本格的にSwiftUIをプロダクトに導入するところが多いからなのかもしれないですね。その他にも await/async関係のセッション、UICollectionView系のも比較的多かった気がします。

普段の仕事や趣味で開発している分ではカバーしきれないというか、知ることもできなさそうなことがこういったカンファレンスで得ることができるので、こういうカンファレンスに参加するのって大事だなと改めて思いました。

エンディングで来年はオンライン?オフライン?みたいな話がありましたが、自分はオフラインだと2018年の時の1回、オンラインだと去年と今年の2回参加で、両方いいなーって感じるところがあるので、ハイブリット形式で今後やっていくのもありかなとは思いました。(もちろんその分運営さんにとっては少し手間かもですが)

来年も引き続きiOSDCに参加しようと思ってます!次は登壇しているかもですね!(来年の自分に期待!)

iOSDC JAPAN 2021、今年もありがとうございました!来年もよろしくお願いします!