目次

Track A

  • 100人でアプリをリファクタリングして見えてきた、最強のiOSアプリ設計に求められること
  • iOSリジェクト戦記 ~リジェクトされないための課金ページ~
  • iPadOSDC: Multiple Windows

Track B

  • 4年間運用されて表示速度が低下した詳細画面を改善する過程で得た知見
  • 400種類のアプリを毎日ビルドする自動化の技術
  • デバッグメニューのメンテナンスが大変だったので、専用アプリを作りました
  • ベジェ曲線の知らない世界
  • GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス
  • 効率よくUIKitからSwiftUIへ移行する

Track C

  • キーワード多すぎ!なエンタープライズiOSの世界を概観する — 2020年版
  • Flutter移行の苦労と、乗り越えた先に得られたもの
  • 無料トライアル施策のしくじりから学ぶサブスクリプション構成 ベストプラクティス

Track D

  • そろそろCombine

Track E

  • 機械学習のブルーオーシャン、Core ML
  • Step to the stage of Conference ~スピーカーとして立つためのCfP Tips~

Track A

100人でアプリをリファクタリングして見えてきた、最強のiOSアプリ設計に求められること

元々はイベントで行われたリファクタリング大会があり, その中で得られたエッセンスをまとめて紹介されるという内容でした.
リファクタリングの超ざっくりした内容は↓です.

FatViewControllerになってしまっているリバーシ(オセロ)アプリをイケてる設計で解消しようぜ

その中で得られたエッセンスが大きく5つ

  • Presentation Domain Separation(PDS)
  • Enterprise Business Rule の分離
  • 状態遷移の整理
  • 依存関係逆転の原則(DIP)
  • 一方向のデータフロー
  • 静的型の活用

iOSだけでなく, あらゆる開発において目から鱗な内容をぎゅっとつめましたという内容で必見です.

参考

(スライド見つかりませんでした泣)

iOSリジェクト戦記 ~リジェクトされないための課金ページ~

そもそも自分は課金のあるアプリを作ったことなかったので初めてずくしで超おもしろかったです.

iOSの公式から求められる内容(利用規約)の話もおもしろかったのですが, 他社のアプリの事例も交えつつ, 課金画面の変遷を追えてすごくためになる発表でした.

実際に自分が課金のあるアプリを作る際に改めて見直したい発表です.

参考

iPadOSDC: Multiple Windows

SceneDelegateについて初級から, ちょっと込み入ったところまで発表されていました.

まず何よりも大事なのが↓です.

iOS12以下を切り捨てろ!

これ超大真面目に大事で, iOS12以下をサポートした上でMultiple Windowsに対応しようとすると, Secne Delegateへの記述とApp Delegateへの記述が混在することになってバグの元になります.
iOS12以下のサポートをするなら, そもそもMultiple Windowsの対応をしないのが良いんじゃないかなと感じました.

AppDelegate, SceneDelegate, UIViewControllerの関係性を表現した図も用いられていて超わかりやすい.
とてもしっかりと練られたスライドだと思いました.
話もテンポよくてめちゃくちゃおもしろかった(語彙力).

参考

Track B

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

4年間のアプリ運用によりViewの構成要素が増えてしまい, 表示速度の低下が問題になった画面をリファクタリングしていく過程のセッションです.
原因特定から改善方法まで丁寧に語られていてものすごくわかりやすかったです.

さらっと語られていたのですが, 改善方法で最初に大きく分けて

  • Xibを使わずコードレイアウトにする
  • Viewの表示を遅延させる

の2択があった中で後者を選んだプロセスのところで「ふーむ, なるほどー, たしかに.」と個人的には勉強になりました笑

参考

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

ノーコードでアプリを作成できるヤプリで実際に行われていたオペレーションの中で, 人力で行っていた部分をどのように自動化していったのかが詳細にわかるセッションです.

単純なアプリリリース(ビルドしてAppStoreへ配信)は先駆者の方々の記事などを見つけやすいのですが, ここまで広範囲に渡る業務レベルで行われている自動化を一気通貫で見られることは中々ないので, 終始感動していました.

詳細な内容は実際に見ていただくのが良いと思うのですが, この考え方は常に念頭に置いておきたいなと感じたことです.

大きい問題
→ 解決するの難しそう
→ 小さい問題にする
→ 解決できそう
→ 小さい問題を解決するパーツを作る
→ 組み合わせたら中くらいの問題解決できそう
→ 更に組み合わせて大きな問題も解決しそう

参考

デバッグメニューのメンテナンスが大変だったので、専用アプリを作りました

アプリのテストをする時に便利なデバッグメニュー.
デバッグメニュー童貞の自分からすると, デバッグメニューを作っているだけでも素晴らしいと思うのですが, なんと専用アプリを作って複数アプリのデバッグメニューを管理してしまおうというセッションです.

技術的にはApp GroupsUserDefaultsを利用して作成していったようです.

また, アプリ追加やデバッグ内容追加の度に新規でViewを作っていくことがないように, それぞれを宣言的に書けるように実装されていて参考になること間違いなしです!

※ 補足

ガイドラインが更新されて, リジェクトの可能性もあるようです.

参考

ベジェ曲線の知らない世界

ベジェ曲線と仲良くなってSwiftで描いてみましょうという何ともニッチなセッションでした笑

たくさんの数式が出てきて

????

となるところも多々あったのですが, ポリベジェ曲線を滑らかにするためには, 2つの曲線の終点, 始点に於いて一時微分係数と二次微分係数が一致する必要があるというのは「あー, 傾きが一緒になる必要があるからだよねー, 傾きといえば微分だよねー.」くらいには高校生の時の知識でなんとか(たぶん)理解できました.

普段なかなか触れることがない分野なので, 大学の講義の気分で臨むと楽しいです!

参考

GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス

┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘┌|▼▼|┘

こんな感じで弾幕が流れ続けるセッションでした┌|▼▼|┘
弾幕や煽りコメントなどで我々の大好きなニコニコ動画って感じを味わえて大変楽しかったのですが, 内容自体はいたって真面目なものでした笑

そんな発表の中で出た数々の名言のうち二つほど紹介します.

┌|▼▼|┘ < CIとは, リモートリポジトリ内のソースコードに問題がないかこまめに確認することです.
by The uhooi

┌|▼▼|┘<リモートのビルド成功してるのにローカルで失敗してる場合はローカルに問題があるのだよ.

by The uhooi

録画ではありますが, ライブコーディングも行っていてとてもおもしろかったので, まだやったことがない人はこれを機にuhooi先生と一緒にCIしてみましょう!

参考

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

みんな気になるSwiftUIへの移行!

誰だって気になる, おれも気になる.
by 虹村形兆

(全然関係ないけど, ジョジョ好きな人は是非仲良くなってください.)

スピーカーのjoshさんはなんとObjective-CをSwiftUIへ移行されたとのことでした.
そんなjoshさんはSwiftUI自体のキャッチアップはもちろん大事だけど, 他にも大事なことがあるとおっしゃってました.

  • 移行計画はちゃんと立てよう
  • なぜ移行する必要があるのか(or 移行するべきでないのか)を理解しよう
  • プロトタイプで試してみよう
  • 現状のプロダクトをモダンなSwiftコードにしよう(もちろんObjective-Cからは早く脱却しよう)
  • 関数型プログラミングを理解しよう
  • 現状のプロダクトとSwiftUI移行後では適切なアーキテクチャが違うかもしれないよ!

などなど, SwiftUIは素晴らしいけど安易に見切り発車な移行をすると事故るよと警告もされていましたので, 移行検討中の方はぜひ一度ご覧になってみてはいかがでしょうか.

参考

Track C

キーワード多すぎ!なエンタープライズiOSの世界を概観する — 2020年版

普段ToCでの業務が多めな自分としてはなかなかこういったことには触れる機会がないのでめっちゃ勉強になりました!
そもそもコーディングによるアプリ開発だけに従事していると意外と知らない気がしますね.

  • Supervised Mode
  • Apple Configurator 2
  • 構成プロファイル
  • Mobile Device Management(MDM)
  • Custom App
  • Device Enrollment Program(DEP)

何やら知らない単語がずらり…
構成プロファイルくらいはFirebase Distributionで使ったりするか何とかしってるかも…

これらの単語は, 法人でiOS端末を管理するときに使うツールや設定の名前みたいです.
セッションの中では実際に想定され得るクライアントからの依頼を例題に, これらの単語について解説されています.

本当に全然らない分野だったので, 終始「へー, ほえー, はー, なるほどー.」ってなりながら聴いてました笑

参考

Flutter移行の苦労と、乗り越えた先に得られたもの

リクルートの「じゃらん」アプリのFlutter移行のお話です.
最近はSwiftUIやJetpack Composeなどのように宣言的にUIを記述できるものが注目されていますし, そういう意味でFlutterは今後も注目されていく気がします.
またReactNativeなどに代表されるクロスプラットフォーム開発のフレームワークとしても注目されているので, 既存アプリをFlutterに移行してみようかなー, とか, 新規アプリをFlutterで開発しよう, などの声も多く見られるようになってきましたし, 実際に導入しているケースも増えましたよね.

このセッションでは実際に移行を行った際に直面した課題についてお話しされています.

  1. タブ切り替えのパフォーマンス
  2. Flutterの画面が初期化されない
  3. ネットワーク通信がproxyを経由しない
  4. Google Mapsがクラッシュする

1は自分自身もFlutter書いてて嵌ったことがあって, タブの切り替わりのタイミングでWidgetの再読み込みが走ることによるもので, Widgetツリーの構造を理解してないと嵌る罠です笑(Flutterではデバッグ中にWidgetツリーをIDE上で見られるので, そこで確認すると分かります.)

他にも2とかだと段階移行で使用しているAdd-to-appによる問題など, Flutter移行で迷われている方は, 同じことに嵌りそうな罠について解説されるので, ぜひ一度見てみることをおすすめします!

参考

無料トライアル施策のしくじりから学ぶサブスクリプション構成 ベストプラクティス

一部ユーザーを対象としたサブスクの無料トライアルにおけるしくじり先生をしてくださってます笑
(◯十万円の返金対応をすることになってしまったようです, 明日は我が身, 笑えません…笑)

セッション内では, 課金の種類や, その中でもサブスクリプション課金に関するガイドラインが丁寧に説明されています.
しかし, それだけ綿密な調査を行って実施したにもかかわらずしくじってしまったとおっしゃっていました笑

しくじりから得られる学びは大きく4つ提示されていて下記です.

  1. アプリ外の購入導線があるため, 既存グループでの新しいプランはストアに反映した瞬間から購入され得る.
  2. 別のグループに同じ内容のプランを作るとリジェクトされる.(Appleが提供しているベストプラクティスと違うため)
  3. App Storeのお試しオファー終了日は, 期間最終日の翌日に設定する必要があるため注意.
  4. (iOS14以降では)オファーコードの登場により, 対象を制限した無料トライアルの提供ができるようになるかも.

同じような条件の施策をやりたいという話題が出たら, すぐさま見直したいセッションでした笑

参考

Track D

そろそろCombine

そう, そろそろCombine学びたいなと思っていました.
簡単に言うとCombineは

連続した多種類の非同期処理などを単一の方法で扱う宣言的なAPI

と言えるようです.

この中で出てくる宣言的というワード, 最近だとSwiftUIなどでもよく聞くワードだと思いますが, これを「喉が渇いたので水を飲むこと」を例に説明されています.

  • 指示的
    「冷蔵庫からペットボトルの水を取り出して, コップに注いで, 水を飲みます.」
  • 宣言的
    「受け取った水を飲みます.」

つまり, 宣言的に書くことで, コード量が減ったり, 本来の目的に集中して書くことができるなどのメリットを享受できるということです.

Combineの主要なクラスであるPublisher, Subscriberなどを図を交えて処理の順番も含めて説明されてたので非常にわかりやすく, Reactive Programming初心者の私でも理解できました.

既存実装へのCombine導入や, デバッグ方法, 更には今後の学習方法にも触れられていて超盛り沢山の内容です!

公式ドキュメントを読む前にこのセッションを見ると理解が深まるのではないかなと思います(RxSwiftなどを学ぶ前に見るのも良いと思います).

参考

Track E

機械学習のブルーオーシャン、Core ML

機械学習やってみたかったんですよね!
ただ, 僕が思ってたのは「遊び程度にやるのはまあ本とか読めばある程度いけそうだけど…」って感想でしたが, 堤さんは冒頭で

普通に機械学習やろうと思うと, 研究してたり, Kaggleで良い成績残すような専門的にやってる人たち強すぎてレッドオーシャン.
だけど俺たちiOSエンジニアにはブルーオーシャンが残ってるぜ!

と, まさに僕が思ってた悩みを吹き飛ばしてくれる文言をいただきました笑

ただここでもう一つ生まれる疑問「なんでCore ML? 他にもいろいろツールあるよね」.
これに関して, Core MLはiOSデバイスの性能を最も活かせるとおっしゃっています.
PyTorch MobileやTensor Flow for iOS(現在はdeprecated), Tensor Flow LiteはCPUやGPUで動作するものですが, Core MLは唯一Neural EngineというGPUよりもニューラルネットに最適化されたプロセッサを使えるようです.

セッションの中ではCore MLを使った実案件(を抽象化した内容)を元にCore MLの使い方や, グラフの可視化などに関する説明をされています.

また個人的には, 案件の条件によってどのような方針で進めていくかのフローチャートまで公開されているので, 実際に自身でCore MLを勉強して実案件で使う際の意思決定に大いに参考になる内容で感動でした.

※ 補足
発表後すぐにYouTubeの方に目次と字幕付きの動画を公開されていて, さすがだなと思いました(実際僕はニコ生の追っかけ再生じゃなくてYouTubeで見ましたし, 明らかに体験がよかったです).

参考

Step to the stage of Conference ~スピーカーとして立つためのCfP Tips~

カンファレンスで採択されるプロポーザルの書き方という, iOSDCの中だと変わった趣旨のセッションです.
が, これめちゃくちゃ参考になります.

「そもそもプロポーザルを書かない理由(抵抗感)ってあるよね」という内容からスタート.

  1. 知識がない
  2. 自分自身が有名じゃない
  3. 恥ずかしい

んー, たしかに, 見に覚えがあります(僕は特に1).
それぞれの悩みに対してフレディさんはこうおっしゃってます.

  1. プロポーザル通った後で付ければ良い
  2. 匿名での審査だったりするから大丈夫だよ(iOSDCもそう)
  3. それは未来の自分に丸投げしとこう

これを聴いて僕はだいぶ気楽になりました.
特に1に関して少し補足すると「自分が興味を持っているまだ習熟度の高くない知識を登壇までに習熟度を上げる」という方法を取ると良いよとおっしゃってました.
次に登壇の機会がもらえそうなことがあったら, この考え方を念頭において試してみようと思います.

そして実際にプロポーザルを書くコツを紹介されていくのですが, その内容がフレディさんのiOSDC 2020のプロポーザルに反映されています.

また, これは僕の感想でしかないですが, フレディさんの発表自体がコツを反映したコンテンツになっていると感じました.
興味を惹く, 得られる効用の提示, まとまった起承転結, これらが綺麗に反映されていて, とても気持ちよく?見られるのでぜひ一度ご覧になってみることをおすすめします.

参考

よかったらClap & Twitterフォローしてくださいー

https://twitter.com/tihimsm