iOSDC2021見聞録
見出し画像

iOSDC2021見聞録

@dsxsxsxsです。滞在歴ほぼ5年、台湾人。
今年もiOSDC2021参戦。初投稿になります。
時間軸ベースで思ったことや印象に残ったセッションをここに書き残しておこうと思います。つぶやき感覚で。

開催前

ノベルティは去年よりも豪華。グラス、お菓子、軍手、などなどが入っている。

画像1

なんと大好物の羊羹も!

画像2

パンフレットに有益な記事が盛りたくさん。

いよいよ09-17当日。
仕事で前夜祭説明を見損なってそのままセッション突入でした。悔し。

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

いきなり立木文彦さんによるタイトルコールで震えた。すごい迫力。

すぐできる効果の大きい改善、そんないいことなんてなかった。とても共感します。
大きな改善を行うには計画を立てて、必要な人力、時間を確保。開発者全員には共感できる知識や価値観を確立。それが前提だという。確かにそうですね。
下準備、自動化などの工夫をして、開発者に不要な関心事を与えない。
Ex: Danger、XCodeバージョン絞り、RIBCodeGenなど。
共感できるコンテンツで勉強になりました。

SwiftUIで使ったアプリを1年運用してみてわかったこと

しっくり来るMVVMとても参考になります。

・LazyViewによるNavigationLinkの組み込み。
・SFSafariViewControllerはpushしないでpresent。

海外の開発者にもこれらに悩まされているようです。貴重な解決策を聞けてよかった。大変参考になります。

翌日、いよいよ正念場。目覚まし3つも設定して寝坊対策していた。

オープンニング

今年も盛大かつ豪華でおしゃれ。

視覚:Pixivさんによるデザイン、それをベースにした演出が華麗。
聴覚その1:iOSDC Anthem。

聴覚その2:

・セッションの合間には緒方恵美さんによる企画紹介
三石琴乃さんによるスポンサー紹介
立木文彦さんによる迫力溢れな各セッションのナレーション。名前を呼ばれるのは良いですね。

最強すぎる声優陣ですね。日本語を覚えてよかった。

Network ExtensionでiOSデバイス上で動くパケットキャプチャを作る

VPNとは何か。それからNetwork ExtensionフレームワークでゼロからVPNクライアントを作るまで勉強できて知識過剰摂取ほど満腹なセッションでした。
そしてパケット解析によるAmong Us必勝法。秀逸な実用例で盛り上がりました。

未知のファイル形式をCodableで読み書きするのに役立つテクニック 『Apple Watchの文字盤ファイル』

解析が楽しい。ものすごく分かります。
Codable + FileWrapperでディレクトリ構造までCodableで完結できちゃう。
Dynamic Coding Keyのうまい扱いなど、とても参考になります。

結局文字盤Codableで解析して良かったか?と今ふと思いました。自前でいい感じにIOロジックを設計したり、別にCodableに拘る必要はあったりするのかなっと疑問が残っていた。質問し損ねたのは悔しい。

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

アクセシビリティの必要性を改めて認識するセッションでした。Voice Overが思ったより面白いし、目の不自由のユーザーしかわからないUXをいかに検証するかとても参考になった。

Ask the Speakerにで、定期的にユーザーにアンケートなどを行い、改善の着目点など課題を汲み取ろうという進め方を聞けた。これによって正確なアクセシビリティユーザーの望んだUXを作っていけるでしょう。とても参考になります。

Combine を使ったコードのテストを Scheduler で操る方法とその仕組み

Reactive Programming中毒者である自分にとしてとて期待していたセッションで、そして期待以上となりました。
ゼロからScheduler Protocolに準拠したSchedulerを作る贅沢な話を聞けてもう感謝するしかない。
Schedulerの注入にはタイプパラメータ汚染とかの懸念があるが、AnySchedulerみたいな型消去手法が考えられると、Ask the Speakerで質問して分かりました。アイカワさんに感謝です。
そして検索したら既にTwitterにあった@inamyさん感謝です。

Swift 5.5 async/await を支えるモナド、継続、コルーチン

圏論を勉強していたので感覚捕まえた感じでしたが、途中から急にアクセル全開で追いつけられなかった。分かるつもりの範囲で自分なりの解釈を書いてみるとしよう。多分全然間違われた解釈なので参考まで。

圏論視点からしてはasync/awaitやStructured Concurrencyとは、Monad、Continuation、CallCCなどの組み合わせを言語仕様に融合することによって実現できた。よって従来OOPのConcurrency不都合を数学ベースの保証付き、より堅牢な非同期や並行プログラミングが可能。

・Monad + FreeでFreeMonadで手続き処理が實現できる。それの言語仕様化がasyncのコード部分。
・Continuationが内から外まで実行、または下から上まで実行の實現であり、Monad + ContinuationでContMonadで手続き処理の実行順序部分。それの言語仕様化がasyncの実行順序部分。
・CallCCからは同調処理部分、zipなどにSuspend.
・これ以上わからない。勉強しないと。

勉強し直してこよう。

Lighting Talks Day1

使い続けるとアプリが落ちるっというヒントからの気付き。貴重で鋭いユーザーフィードバックを見落とさないこと。
スクリーンキャプチャーはメモリーに優しくない。

三石さんに社名を読まれる。
デザインスポンサー、VIP感。

エラーハンドリングとは、エラーを誠実にユーザーに伝えることですよね。
エラーハンドリングにサボるべからず。

1日目Closing

ご飯の支度していたのであんまり聞けなかった。反省。
目覚まし設定忘れたけど、奇跡のように翌日10時頃に起きた。

2日目Today's Update

今日のLTこそ大丈夫だ!っとStaffによる保証。
フラグじゃん。不安だ。

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

debugメニューなどの開発向け機能を作ることによって得られるメリットが盛りたくさんということ、とても共感です。自分の言う現場ではむしろdebugメニューに頼りすぎ問題を抱えている。
開発向け機能の起動方法についてとても参考になります。

Ask the Speakerで
「debugメニューと隠しメニューは別概念」@noppeさんによる格言。
概念の分離。素敵。
どういう基準でデバッグ機能を作れば良いかっと質問したところ、結論としてチームや現場によって異なるし一概に言えないけど、テスト用など一時的なもの、または使い捨てなものはタイミングを改めて削除しましょうっと

プロダクション機能にデバッグ機能の依存をどう作れば副作用の少なく疎結合にできるかっという疑問を残したまま。自分なりのやり方は愚直にプロダクションで稼働しないデバッグ機能ラッパーを注入する感じです。

大規模なアプリのマルチモジュール構成の実践

とても貴重な大規模アプリ向けアーキテクチャの話 by @giginetさん。

Targetを跨いた依存をすべてCore TargetにEnvironmentというルールを作り、使う側に具像を用意してインスタンス化、それ以降は必要なところに注入するだけ。

各詳細に依存関係を作ってしまうことを防ぐには、DescriptorとResolverという依存解決仕組みを登場させ、これを介して具像を取得。
想像までだけど、様々な場面で活躍する仕組みでしょう。画面遷移やDataStore注入など、様々な依存を作ってしまう場面で活かせそうです。とても参考になる手法です。勉強になりました。
事前にここまでの設計が偉業すぎでとても真似できません。

とりあえず思いつくメリットをおさらい:

・暗黙的依存を作ってしまうハードコーディングを抑えられる。
・Environmentの具像を差し替える事によって依存を変えられる。これで依存の詳細を隠蔽できる。Legacyものこの仕組みで隠蔽可能。
・依存の変更は使う側まで波及してしまうのを防げるし、影響範囲を抑えられるし。
・使う側に依存の生成を知らない。依存はどう使われるかを知らない。

拡張しやすい、変更までする場面が少なく、各コンポーネントの責務が単純、すごくSOLIDな印象です。
このまま行くと、理想郷みたいなコードベースとかですね。

実践していくにはメンバーたちの知識共有、価値観の浸透は欠かせないこと。人の負担を軽減するのにメタプログラムなどの自動化も考えられるということ。とても共感できる話で大変参考になりました。午前セッションでもう満腹状態。

Environmentの具像などは多分AppDelegate、または他の初期のところで一括インスタンシェートだと思うが、そこは多分Composition Rootですかな。もしくはEnvironment具像のinitがComposition Rootか。という疑問が残ったまま。

感想として、理想なアーキテクチャで理想なコードベースを造るとか、やはり大変な話だ。

・一人でやるならサボりますし、そこまで設計しない。
・チームでやるならまずチームメンバー全員が納得してもらうから、人間性が問われる。

思い深いセッションでした。大半は自分の妄想だけど。
@giginetさんに感謝、Respect++です。

あらゆる情報を楽に正しく String にフォーマットする

「母国語がSwiftです。」という不意打ちを食らってトークの記憶が半分飛んだ。
Formatter盛りたくさん全網羅のトークで、こんなに沢山あるんだっとびっくりでした。
文字列ゴリゴリ組もうとする時このセッションで覚えたことを思いつけれるように心かけようと。

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

UICollectionViewがどれほど強力なのか実感できました。
まずUICollectionViewCompositionalLayoutで組めるか確かめる。
本当にDiffableDataSourceとSnapShotを使わない理由はない。使いたいですね。iOS13+だが。

App Extension のスタックトレース情報からクラッシュを解析/集計する

実質Crashlyticsの作り方セッションで大変勉強になりました。
App ExtensionでもクラッシュハンドリングのAPIがあるので、それを実装すればクラッシュを拾えると。
atosコマンドを覚えれば手動でStack Trace解析が可能。これの自動化ツールを作れば楽、更にクラウド化すれば実質Crashlytics。強すぎる。大変勉強になりました。

iOSアプリのセキュリティ基礎

知っておくべき脆弱性パターンや攻撃手法を列挙し、知識過剰摂取でした。
URL Schemeの扱い、暗号化キーの保存、OAuth、OpenIDの話を聞けてよかった。信頼できるスタンダードでシステムを築き、攻撃される隙を作らないこと。勉強になりました。

このセッションで覚えたことを常に心かけようと。

オフライン編集もできる複雑なデータ構造を端末間で同期するために

オフライン編集には欠かせない分散化バージョン管理に纏わる面白い話でした。ほぼ自前Gitじゃないかっと思ってしまうほど。

コンフリクトの解決は当事者任せる。

たしかに!
コンフリクトの解決失敗したらどうするのって質問してみたところ

編集履歴で救える。

たしかにその2!愚問でした。
編集履歴をいつまで、いくら保存するかは仕様と需要次第。
各クライアントでの作成タイミングとサーバーにたどり着くタイミングの差分を考えると、バージョンをサーバーで統一管理のがおすすめ。

async/awaitやactorでiOSアプリ開発がどう変わるか Before&Afterの具体例で学ぶ

例が驚くほど理解しやすい。
紙芝居を観ているような感覚で大盛況でした。このスライドを作るのは大変でしょう。Structured Concurrencyを実用できるまでにはあと3年か〜と思わず嘆いた。
@koher さんに感謝 & Respect++

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

SceneKitとUIKitは相性抜群。基本なアニメーションによる演出はSceneKitで勝利できる。GLSLSandboxでGLサポート。
Ask the SpeakerでLottieとの比較の話:

SceneKitはXCodeで即時編集、確認可能。単純な演出はSceneKitで十分。
LottieはAFなどAdobe資源のメリットがあるが、コスト面は優しくない。
いずれにせよ、単純なEffectであってもUIKitで実装するのは無謀。

Lighting Talks Day2

Sort安定性の説明に信号機の例がわかりやすかった。

Swift5.0未満なら不安定なIntrosort。
Swift5.0以上なら安定Timsort。

Timsortは優秀、ただメモリー使用量に注意必須。

わかりやすい。広告対応の沼。先が長いですね。
立木文彦さんによるじん〜む〜が印象的だった。

アプリの状態を綺麗にするってところで死化粧のコメントが流れてきて思わず吹いた。
時間を取らないようにする→介護不要化
ユーザーに新サービスへの誘導→相続
感謝の気持を込めて幕を下ろす。
アプリの最後はこうなると良い。とてもいい話でした。まさに善終です。

配信が途切れていた。やはりフラグ...
RFC6238 TOTP(Time-Based One-Time Password Algorithm)の実装法が
とても参考になります。良くAuthenticator頼りなので、これは導入したい。

2日目Closing

Twitterもニコ生も大盛況でした。景品も豪華。
トークンチャレンジ完全圏外w。
StaffのStatistics力が優秀すぎ。結果も面白かった。


そしてStaff全員の集合写真。みんな家で乾杯していたか勝手に想像していた。「密です」って弾幕が流れてきて面白かった。
懐いエンドロールが流れ、そして番組終了と。

「また来年会おう」っとツイートが流れていた。自分もツイートしてたと。

感想など

満腹でした。去年は4セッション同時視聴だったけど、無理すぎ。今年は反省して2セッション同時、片方メインで視聴。結果としてこれがほど良いと。登壇者、Staff、関わっている皆さんに感謝です。

今年もオンライ開催という形。ニコ生配信。Discordが会場+Ask the Speakerもここで行わる。Twitterでのツイット統計なども行われた。進行全体がスムーズでした。
(Gatherも良いかも。まぁGatherはまだ難ありだね。思ったより重いですし。

オンラインもオンラインの良いところがありますね。@tomzohさんのおしゃった新生活形式の話、自分も同感です。遠方に居る人も参加可能になるし、海外からの参加希望者も少なくないよう。ある意味より多く人を繋げられる。
オフラインならできる通訳が課題が残りますけど。

オフライン開催で顔合わせて交流、After Partyで盛り上がろうというのはもはや懐かしく、今度オフラインだったら良いなという気持ちもあります。

どれも捨てがたいか。難しい。

去年のClosingで来年はあるか不安でしたが、まさか今年になってさらなる盛況まで。これからも前向きに行けそうな流れだなっという気がしてきた。

今年は不安とかじゃなく期待ですね。

さて、iOSDC2022はどうなるか。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!