トーク

大幅リニューアル後に、放置していたクラッシュが、なんと一日数千件まで爆発してしまった！？しかもそれは再現方法も原因の手がかりもまったくつかめないクラッシュなの？

結論から書くと原因はメモリ不足でした。メモリ不足によるクラッシュは直接の原因がログやスタックトレースに現れないので再現が容易でなく調査が困難です。
このトップクラスのクラッシュに対して、クラッシュログから原因を推測し、メモリ不足と仮定して、Allocationsで調べながら、リファクタリングを行いました。そしてリリースしたバージョンを観測した結果、無事解決できていることが分かりました！
このLTでは、このような再現手段がない、特定ができない問題について、どのように仮説を立てて、解決していったのかを紹介します。

WWDCの直前に、いきなりアップルのM1チップにM1racleと名付けられた脆弱性の話が出てきました。

簡単にどんな脆弱性かを説明しますと、M1チップでは、任意の二つのアプリがCPUの管理外で、独自で秘密なチャンネルを構築し、交信できるということです。しかもこれハードウェアの脆弱性なので、そもそものハードウェアの設計を変えない限りどうにもできない、つまり既存のM1チップのMacやiPad Proは全てどうにもならない、ということです。

え？やばくね！？？どうしようどうしよう！！

このLTは、その発見者にM1racleと名付けられた脆弱性の発見や対策などについて話します。

注：大事な話なので2回言います。このトークは技術の話はしません！このトークは技術の話はしません！！

Teslaのハードウェアとソフトウェアの洗練さは、まさに車業界のAppleですよね！
エンジニアなら、誰しも憧れで一度は乗ってみたい、触ってみたいですね？
ちまみに、わたしは持ってません。
このプロポーザルが採択されたら、弊社NOT A HOTELの社長のTesla Model Xを借りて乗ってみようと思います。
Unofficialですが、Tesla APIを使ってハックして遊びます。
以前はFlutter appで自社アプリに組み込んで遊んでみました(Twitter参照)が、SwiftUI nativeなアプリへ移植を試みます。
https://twitter.com/wa_kinchan/status/1366964772894203904?s=20

ありがたいことに、ピクシブ株式会社では2年連続でデザインスポンサーをおまかせいただきました。他のスポンサー枠とは毛色が異なる「デザインスポンサー」。みなさんの企業・団体・個人でもデザインスポンサーをして、iOSDCを自分色に染めてみませんか？

このトークではデザインスポンサーをやってみたい方たちの参考になるように、

• デザインスポンサーがやること
• デザインスポンサーのスケジュール感
• デザインスポンサーを引き受ける"前"にやっておくこと
• デザインスポンサーの難しさ

についてお話します。

みなさま、notificationは利用されていますでしょうか。
私もappで提供する機能の一部として動作させる、マーケティングで活用するなど、様々な用途で利用してきました。

一方で、必要ないタイミングで通知した、あるユーザーにとって不要な情報を配信してしまったなど、
意図せずユーザー満足度を下げてしまうこともあったかと思います。

そんな中、WWDC21にて多くの新機能が発表されました。
集中モードやNotification summaryでnotificationの受け取るタイミングなどをユーザー自身が制御可能となり、
Interruption Levelにより、配信時の挙動がより細かく定義されました。

これにより、これまでの配信内容を見直す必要性が出てきており、
今までと同様では期待する効果を得るどころか、
ネガティブな印象を与えてしまい、appがアンインストールされるなどの可能性も出てくるかと思います。

本LTでは、新機能をおさらいしつつ、今後どのような影響が考えられるか、
またiOS 15以降のnotificationのあり方についてこれまで通知してきた内容を基に考察していきます。

[想定する方々]
・notificationをマーケティングなどで利用している方々

[ゴール]
・次の日からすぐにiOS 15リリース後のnotificationについて検討が行える

[アジェンダ]（検討中）
・これまでのnotificationについて
・WWDC21で追加された新機能
　　・Notification summary
　　・集中モード
　　・Interruption Level
・iOS 15リリース後に想定される影響について
・iOS 15リリース以降のnotificationの内容について考察

Safariには、設定 → Safari → 詳細 → Experimental Featuresという、そこそこ深い場所にある「実験的なWebKitの機能」に、文字通りSafariの標準機能には組み込まれていない実験段階の機能が羅列されています。普段気にしている方はそう多くないかもしれませんが、オフになっているものをオンにすることで動作するようになる機能もありますし、その逆もまた然りです。

本トークでは正式版が公開されている“iOS 14.x”時点の「実験的なWebKitの機能」の概要を眺めながら、特に注目の機能について解説します。
なお、もしもiOSDC Japan 2021当日以前に“iOS 15”がリリースされた場合は、質疑応答や公開資料の中で補足します。

ちなみにAR的な観点から現時点で最も注目している実験的な機能は“HTML <model> element”です!!

皆さんSwiftUI.Text使ってますか？

SwiftUI.Textには知っていると便利な機能がいくつか存在していて、例えば

Text("iOSDC Japan")
+
Text("2021").fontWeight(.bold)

このように書いて、Textを結合することができたりします(これはSwiftUI.Textに public static func + (lhs: Text, rhs: Text) -> Text が定義されていて、Textの結合ができるようになっています。)

このLTでは、SwiftUI.Textに存在する不思議な(面白い)挙動をする機能について紹介します。

メンテナンス時や障害時など、アプリ側で500系エラーが表示されてしまう場面はあると思います。そんなとき「情報を伝えているようで、何も伝えていない画面」ではなく、ちゃんと意味のある画面を表示したいですよね。

ではどんな要素を表示したらそのような画面を作ることができるのでしょうか。私はそれを解明すべく、約半年に渡ってTweetDeckに「鯖落ち」検索タブを常設しました。「○○が鯖落ちしてる」というツイートを見かけたら該当のアプリを起動してスクショ撮影。もし未インストールのアプリだったらアプリをインストールするところから開始。そうして集めたエラー画面のスクショたちからは、様々なことが学び取れました。

そこで、本発表では次の事項について説明したいと思います。これを元に500系エラー画面を刷新すれば、きっとユーザはよりあなたのアプリを好きになってくれる、はず。

・「イケてない」500系エラー画面とは
　・なぜイケてないのか
・「親切な」500系エラー画面とは
・私達はどのような500系エラー画面を作るべきか

※発表の中では具体的なサービスのエラー画面スクショは使用せず、あくまで要素の紹介に留めます。

通販サイトの会員向けセールを物色していた時、ふと目に入った「SwitchBot」。
Apple Watchに話しかければベッドからでもエアコンが、照明が、テレビが操作できる、
そんな生活に心のどこかで憧れを抱いていた私は、半額セールの勢いで購入することにしました。

SwitchBotには専用のiOSアプリがあり、このアプリから赤外線リモコンの登録や操作、
シーンの操作などを行うことができるのですが、HomeKitには対応していません（Siriショートカットのみ対応）。

しかし、iOSエンジニアとしてはやはりホームアプリケーションから家電を操作してみたい。
SwitchBotをホームアプリケーションで操作するための記録とその結果できるようになったこと、
そしてHomeKitでもう一歩遊ぶためのヒントをご紹介します。

スタディサプリのiOS開発チームは新規サービスでSwiftUIを全面的に採用した開発を行っています。
このセッションでは、Full SwiftUIで中規模以上のアプリの機能をどのように実現したかを発表します。
技術選定でSwiftUIを導入を検討している（興味がある）方の後押しとなればと思います。

WWDC19で鮮烈に発表されたSwiftUI。発表当時は当時の最新OSのiOS 13以上のため、普及率とサポートバージョンの都合で選択肢として外れることが多かったのではと思います。
今日では、普及しているOSはiOS 14が一番のボリュームゾーンとなっており、ようやくSwiftUIを選択肢として取れるようになってきたのではないでしょうか。
我々が実際にその選択を取った時、どんな課題がありどんなメリットが見えてきたのかを説明します。

■構成環境
新規開発（既存コード無し）
Target OS: iOS 14.0
Xcode version: 12.5
Architecture: MVVM
Libraries: Combine, GraphQL(Apollo), Lottie, Nuke

■機能
複雑な画面遷移
API通信
Push通知
DeepLink
Animation
WebView
Testing

タウンワークでは、スマホユーザーに向けたiOS及びAndroidアプリのリリースを通じて、日々数多くの開発を行い、機能改善を続けています。これまでのタウンワークアプリは日本ですべての開発を行ってきましたが、より多くの機能改善を行うために、最近はオフショアチームと協業して開発を進めることに取り組んでいます。今回の取り組みで特徴的なことの1つとして、オフショアチームのエンジニアと日本チームのエンジニア同士が、共通言語である開発言語を用いてコード上で多くのコミュニケーションを直接行っていることがあげられます。これには、異なる母国語によるコミュニケーションを減らし、エンジニアが得意な開発言語でコミュニケーションを行うことで、相互理解を深めるといった狙いもあります。本セッションでは、タウンワークアプリ開発におけるオフショアチームの成り立ちや、オフショアチームと日本チームがどのように協業しているのかといったお話を、実際にオフショアチームと協業している日本のエンジニアから共有します。

このトークは、佐々木 と 中村2名での登壇になります。
佐々木 : GitHub, Twitter -> @omuomugin
中村 : GitHub -> @valmet

ゼクシィの iOS アプリは、2011年から開発されている歴史のあるアプリです。これまで外部の開発会社で開発をしていましたが、近年の結婚観の変化などを受けて環境の変化に柔軟に対応するために 2019年から 社内のエンジニアが開発に加わるようになりました。現在では 十数名ほどが iOSアプリの開発に関わっており、コードベースも 約20万行ある大規模なアプリとなっています。これまで様々な技術的なチャレンジを行っており、今回は Design System の導入背景や導入によるコミュニケーションの改善や開発者体験の向上について、また実装の方針などについて発表します。なおゼクシィにおける Design System は、 Figma 上でのデザインパターン一覧とそれをモバイルアプリ向けに実装したデザインライブラリの両方を含めています。
微妙に異なった定義の色が複数存在していたりなどの状況は、アプリ開発者ならば一度は遭遇したことがあるかと思います。関わってる人数が多ければ多いほどこういったことに気を遣うのは難しくなっていきます。同様なことがマージンやフォントサイズやアプリ内に繰り返し出てくるUIパターンでも発生し得ます。こういった細かいUIの一貫性を各開発者が各機能実装時に気にしなくて済むようにゼクシィでは Design System を導入し運用しています。
本トークでは、Design System の導入の背景や導入によるコミュニケーションの改善や開発者体験の向上について、また実装の方針などについて共有します。

このトークは、韮澤 と 浅井2名での登壇になります。
韮澤 : GitHub, Twitter -> @nirazo
浅井 : GitHub, Twitter -> @trsxxii

ホットペッパーグルメアプリは約20万行のソースコードから成る大規模なアプリで、10年以上の歴史の中で仕様とソースコードが複雑化し続けています。
この複雑さの解消と今後のメンテナビリティ向上のため、我々はコードリニューアル・リアーキテクチャを行う決断をしました。コードリニューアル・リアーキテクチャにあたり、iOSとAndroid間の不要な仕様差分解消や開発工数削減を狙いKotlin Multiplatforｍ Project(以下KMP)を導入することとなりました。
現在はまだ開発中ではありますが、今のところKMP導入による致命的な問題は発生せず、順調に開発が進んでいます。
本セッションでは、大規模なアプリケーションにKMPを導入した際に発生した課題やその解決方法など、iOSアプリにKMPを採用する際の知見を共有します。
初期のKMP実装はiOSエンジニア2名で行っていたため、iOSエンジニアの皆様により近い目線でお話できると思います。
ロジックの共通化に興味があるけどKotlinに手を出すことに抵抗があるiOSエンジニアの方、大規模サービスにおけるロジック共通化の事例を知りたい方、ホットペッパーグルメのアプリ開発事情を知りたい方は是非ご参加ください！

スタディサプリEnglishでは社内向けのiOSアプリをフルSwiftUIで1から開発し、去年の秋から約1年間運用しております。

ただSwiftUIはWWDC2019で登場してからまだ2年でOSのバージョンやXcode(iOS SDK)のバージョンによって挙動が大きく変わったり、Viewの書き方によって自分が触ってない子Viewにまで影響してしまうなど不安定な部分が多いです。

本トークでは不安定なSwiftUIアプリを運用していく際に直面した課題やそれらの課題をUITestを使って解決し安定的に運用することができるにした方法を話します。

開発者のあなたや、チームメンバーがadhocビルドを使うことは良く見る光景です。
全員がサービスに向かい合い、より良い体験を作ろうとします。
しかし、パフォーマンスに関してはどうでしょうか？
ネットワーク状態や、CPUの使いすぎに対しては開発者であるあなたが気にかけるしかありません。
そんな状態を打開するのが、ランタイムデバッガーです。
画面に常に情報を表示することで、アプリを使う全員がパフォーマンスに対して視覚的に関心を持ち始めます。
それはクラッシュを伴わない問題を解決する糸口にもなるでしょう。
この手法は、AppleやGoogleでも採用されています。
このセッションでは自作のランタイムデバッガーを元に、ランタイムデバッグのコツや運用の仕方を解説します。

iOSではたびたびバックグラウンドにいるアプリがOSによって終了させられます。
作業途中のアプリに戻ったら、途中までやっていた作業がパーになった、という経験は誰にでもあるかと思います。

こんなことを未然に防ぐために、iOSには状態を保存し、アプリが終了されていても元に戻す、リストアの機能が備わっています。
本セッションでは、あまり知られていないであろうリストアの機能について説明するセッションになります。

• Storyboardを用いたリストア
• SceneDelegateを用いたリストア
• SwiftUIでのリストア

ひょっとしたらユーザーの離脱を防げるかもしれない、リストアを実装するためのポイントについてお話しできればと思います。

LiDARという技術をご存知でしょうか？

LiDARとは、レーザー光を当てることで、対象物までの距離や方向を測定するセンサー技術のことです。自動運転の分野でも活用されている注目の技術で、高い精度でスキャンできることが特徴です。

つまり、この技術を使うと現実世界を緻密にスキャンすることができるようになるのです。そのLiDARが、昨年iPad ProやiPhone 12 Proに搭載されました！

そしてARの分野では、早くもLiDARを活用したさまざまなアプリが登場しはじめています。

私はこのLiDARを使ったアプリがさまざまな現実世界をスキャンする様子をTwitterなどで目撃し『自分もやってみたい！』と思いました。それからLiDARに取り組んで数ヶ月、LiDARを使った様々な機能を引き出すことに成功しました。

このトークでは、このLiDARを使うと何ができるのか？そして、どうやってiOSからLiDARの機能を利用するのかについて解説します。

iOS 15 の目玉機能であるSharePlay / Group Activitiesについて解説します。
SharePlayでできることを知っていただくところからはじめ、3種のSharePlayを実際にアプリに組み込む方法までを解説予定です。

Agenda

• SharePlay入門
• 実践 画面共有
• 実践 動画共有
• 実践 カスタム共有

皆さん、iOSの「スクリーンタイム」機能を使っていますか？「スクリーンタイム」では、アプリや Webサイトごとにどのくらい時間を費やしているのかレポートで確認でき、使用に制限を設けることもできます。

iOS 15 で Screen Time API にアップデートがあり、開発者にとってできることが増えました。

私は最近、自身のタスクと時間管理に課題を感じ、それを解決するためのアプリを趣味で開発しています。その中で Screen Time API にも注目し、活用できる部分を探っていました。

本トークでは、その過程で得られた知見などを以下の流れでお話しします。

• 背景：自己管理のために実現したいこと
  • スクリーンタイムあるある
  • タイムトラッキング系アプリの課題（手動・半自動・自動記録）
• Screen Time API でできること
  • あなたのアプリで対応するなら
• Screen Time API の課題・気になること
  • 「保護者ー子ども」向け……？自分自身を管理するのは？
  • macOSでは……？

近年、1つのiOSアプリケーションを複数のモジュールに分割してビルドするマルチモジュール構成を採用したプロジェクトが増えてきています。

我々のアプリでは、過去2年間で、アプリ全体を30個程度のモジュールに分離し、十数名の開発者で年間50回程度のリリースを実現しています。

この構造により、各機能が疎結合になったことや、単機能でのアプリ実行によるビルド時間の高速化、Xcodeの動作速度アップといったDX改善の恩恵を受けることができました。

しかし、その構造を実現するには、モジュール構成のデザインや、依存関係の解決といった技術上の課題も多く存在しました。
また、如何にアーキテクチャを整備できたとしても、チーム全体で日常的に利用していくために、モジュール分離を促進していくための仕組み作りも不可欠です。

本セッションでは、我々のアプリ開発を通して培った、実践的なマルチモジュール開発についての実情をお伝えします。
以下の論点について網羅的にお伝えする予定です。

• マルチモジュール化以前
  • なぜマルチモジュール化が必要だったのか
  • どのようなマルチモジュール構成に向いているか
• モジュールの構成
  • アプリ全体のプロジェクト構成をどのように分離すべきか
• 依存解決
  • 型安全なモジュール間の相互依存解決の仕組み
  • 外部ライブラリの利用や抽象化
  • テストや動作確認環境の整備
• チーム内にモジュール分離を用いた開発を浸透させるには
  • コード生成機によるモジュール分離の促進
  • ドキュメントやポリシー整備のノウハウ
  • メタプログラミングやlinter、コンパイル時チェックを利用した機械的な制約手法