トーク

WWDC21 が開催されていた昨年の6月、AVKit に追加されたひとつの機能に社内がざわつきました。
PiP（ピクチャ・イン・ピクチャ）の機能を応用して、Android の画面オーバーレイのようにアプリ外に自由なコンテンツを描画できる期待感を経験のあるエンジニアは感じていましたが、既存のアプリに機能を組み込むまでには R&D 的な開発やパフォーマンスとの戦いがありました。

このトークでは、ゲーム配信アプリミラティブに実装され多くのユーザーに利用されている、視聴者からのコメントや各種配信情報をアプリ外で表示する「配信コメントバー」機能の開発の裏側と技術の詳細、また更なる応用についてご紹介します。

・「配信コメントバー」機能の概要
・実装の解説
・R&D 開発の勘所
・パフォーマンスの解決
・PiP と AVAudioSession との関係
・PiP のカスタマイズ性
・更なる応用

UIデザインツールというとFigmaとSketch二択になってきましたが、アイコンデザインなどビジュアルデザインに近い部分を除いたら、意外とSwiftUIでデザインできちゃいます。SwiftUIだと静的デザインをそのまま実装に組み込めるメリットがあり、開発効率向上にもつながります。

本トークでは、Figmaと比較してSwiftUIがどれぐらい便利かつ直感にレイアウト組めるかをご紹介します。
SwiftUIでデザインしてみませんか？

デザインをいただいて、実装しようとすると以下のように戸惑うことはありませんか。

• 部品のまとめ方
  • 新規部品
  • 既存部品のバリアント
• サイズの決め方
  • 固定サイズ
  • 余白を決める上で決める
• 1行に表示しきれない文言
  • 改行
  • 3点リーダー
  • 1行に表示しきれるように文字サイズを動的に調整
• 複数部品の揃え方
• スクロール領域
• アニメーション

デザインツールの機能不足により妥協したデザイン表現になり、直接デザイナさんにどういうデザインにしたいかを聞いて実装する場合もあると思います。しかし、デザインツールの進化により表現できるデザインが年々増えてきており、困るケースも少なくなってきました。

本トークでは、FigmaにおいてiOSエンジニア目線で、表現できるケースと表現できないケースをご紹介します。

さまざまな場面でローディングインジケータなどを使い、ユーザを待たせていると思います。
しかし、それが果たして必須な要件かというとそうではなく、実装時のコストの兼ね合いで妥協している場合が多いと思います。

本トークでは、ユーザを待たせずに済むよりよい手法とそれを実現する実装方法の具体例をご紹介します。

さまざまな場面でローディングインジケータなどを使い、ユーザを待たせていると思います。
しかし、それが果たして必須な要件かというとそうではなく、実装時のコストの兼ね合いで妥協している場合が多いと思います。

本トークでは、ユーザを待たせずに済むよりよい手法をご紹介します。

売上を最大化させるためのレジの台数といった合理的な意思決定の方法を考える学問である「オペレーションズ・リサーチ」において、数式で求めた結果が合っているのかを確かめるのは難しいものです。しかし、SceneKitで現実世界を再現することで結果の”検証”を行うことができます。SceneKitによる新しい数学の学習方法を複数の具体例とともに紹介します。

ある日、あなたはプロダクトマネージャーから「API から統計情報を提供するから、アプリでグラフを描いてくれない？」と言われたら、どうしますか？

新規アプリであれば、 WWDC 2022 で紹介される Swift Charts を Swift UI を用いて、実装すれば、 Apple から提供されるフレームワークですし、サポートされているすべての OS で適切に描画できそうです。でも、 Swift UI を導入できていない既存アプリだったら、どうしますか？

本トークでは WWDC 2022 で紹介される Swift Charts でグラフを描いた場合と Swift Charts が無かった場合のベストプラクティスを探求し、比較をします。
※ Swift Charts が開発者に提供されなかった場合は WWDC 2022 での発表内容を元に比較を行います。

紙とペンだけが数学の道具ではありません。SceneKitで現実世界を再現して求めた答えを検証してみませんか？SceneKitによる数学の学習方法を具体例とともに紹介します。

アプリの効果測定にはインプレッションの集計は有効な手段の一つです。しかし、より正確な測定結果を得るために単純に「1ptでも表示したらインプレッション発生」という訳でもなく、ユーザーに視認されることが可能と言えるインプレッションといった厳密な視認可能インプレッションの定義が必要かもしれません。
本トークではZOZOTOWNのホーム画面で対応できた独自の視認可能インプレッションの話を紹介します。
「面積のx%以上がy秒間表示し続けるとインプレッションの成立とする」、「インプレッション再記録の条件は◯にする」などインプレッションの設計から、CompositionalLayoutで対応されたホーム画面でそれを実現した際の裏話を大公開します！
・視認可能インプレッションの設計
・CompositionalLayoutでのreusableViewとcellの面積計算の問題
・パフォーマンス面の考慮

ARKitが持つ多くの機能の中でも、みなさんはフロントカメラとバックカメラを同時に使用することによるフェイストラッキングとワールドトラッキングの並走機能をご存知でしょうか？実はこの機能、Human Computer Interaction（HCI）の研究者たちの注目を集めたアツい機能なんです。この機能により、視線を向けるだけで目の前のコーヒーメーカーがコーヒーを淹れてくれるような、これまでにスマートフォン1台ではできなかった体験を実現することが可能となりました。
本トークでは、この並走機能に新たな可能性を感じた私が実際に作ったいくつかのサンプルアプリの紹介やそこで得られた知見の共有をします。

・視線を向けるだけで電気を点けたり、コーヒーを淹れられるアプリ
・目からビームを発してヴィランをやっつけるアプリ
・ユーザが暗い表情をしていると、辺りに花が咲きほこるアプリ

プロジェクトに新メンバーがjoinする際、初めに立ち塞がる壁が開発環境構築です。
また、いざ環境が出来上がったとしてもその後開発ツール(CocoaPods、SwiftLint、etc...)がアップデートされていることに気づかないとバージョン差異に起因する事故(おま環、コンフリクト、etc...)も起こりがちです。

そこで、自分の関与しているプロジェクトではgit-hooksによる開発環境の自動更新を実施しています。

本LTでは、意外と忘れられがちなgit-hooksとiOS開発における活用方法について紹介します。

サステナブルな開発環境、欲しくないですか？

WWDC2021で発表されたSwift Playground 4はiPadだけでアプリの開発からリリースまで行える機能が付き、とても話題になりました。
皆さん普段はMacBookで開発していて、私自身もその1人ですがあえてiPadだけで開発からリリースまでを行いました。
その苦難の道のりをお伝えさせて頂きます。

iOSプロジェクトでOpenAPIを採用した時に、Swiftコードの生成とその管理方法をどうすればいいのかは意外と悩みます。
そこで、Dockerを使った疎結合でシンプルなOpenAPIのコード生成と生成したSwiftコードの管理方法のベストプラクティスをご紹介します！

• Dockerを使ったOpenAPIからのSwiftコードの生成方法
• Swiftコードはどうやって管理するか
• どうやってメインアプリで利用するか

ちまたではDI（依存性の注入）が流行っているようですが、そもそもあなたのアプリで本当にDIは必要なんですかと再度問いたい！たぶん不要だよ！！
DIの種類、導入するべきかの判断、DIを使わない場合の代替方法をご紹介します。

巷では正しい設計、正しい実装、正しいアーキテクチャなど……強迫観念に近い「正しさ」を求めるがあまり、プロジェクトの後半になってなぜ私たちは1つの機能を作るのにこんなにもコードを書かなければいけないんだ…… このコンポーネントは本当に必要なのかと疑問に思いながらも、みんな現実から目を背け、迫りくるスケジュールに怯えながら無心にコードを書き続けていることも多いでしょう……

そこで私が数々のプロジェクトで遭遇した、ほんとにあったオーバーエンジニアリングをご紹介しましょう……

1. そのDIって必要！？
2. 無駄なprotocol定義
3. バケツリレーするだけのコンポーネントたち
4. なんでもリアクティブ
5. MVCで十分じゃね

• なぜ人はオーバーエンジニアリングをしてしまうのか、その傾向と対策

巷では正しい設計、正しい実装、正しいアーキテクチャなど……強迫観念に近い「正しさ」を求めるがあまり、プロジェクトの後半になってなぜ私たちは1つの機能を作るのにこんなにもコードを書かなければいけないんだ…… このコンポーネントは本当に必要なのかと疑問に思いながらも、みんな現実から目を背け、迫りくるスケジュールに怯えながら無心にコードを書き続けていることも多いでしょう……

そこで私が数々のプロジェクトで遭遇した、ほんとにあったオーバーエンジニアリングをご紹介しましょう……

1. そのDIって必要！？
2. 無駄なprotocol
3. バケツリレーするだけのコンポーネントたち
4. なんでもリアクティブ
5. 過剰なテスト
6. 無駄なデータベース
7. 始まってもいないサービスのスケーリング
8. 誰も使わない機能
9. 少人数のユーザに対するABテスト
10. MVCで十分じゃね

UITest書いてますか？
書いた方がいいとは分かってはいますが、

• SwiftコードでUIテストの実装は大変だよね…
• メンテコストもかかるよね…
• 開発スピードが落ちるよね…

などなど…様々な理由でなかなか導入に踏み込めないプロジェクトが多いと思います。

そこで、GUI操作のみでUITestを構築できるMagicPodとAutifyの実例を交えながら、ノンコードで実装するE2Eテストをご紹介します！

• E2Eテストは何をテストするべきなのか
• メンテナンス性が高いUIテストとは
• テストは誰が書くべきか
• MagicPodとAutifyの違い
• CIの記述方法

iOS開発では便利な周辺ツールが充実してきて、以前はCococaPods、Carthageくらいでしたが最近はSwiftLint、XcodeGen、SwiftGenなどを採用するケースが増えてきました。
これらはHomebrewやRubyのBundlerでインストールすることが多いと思いますが、チーム開発になるとツールのバージョンを合わせたり、Apple SiliconとIntelの両環境に対応する必要があり、環境構築自体が複雑化してきました。

そこで、これらの環境構築にまつわる様々な問題点を解決するために、環境依存に振り回されることなく確実に環境構築を行う手法をご紹介します！

• 脱！環境構築の手順書
• 脱！Homebrew
• 脱！Ruby

参考: https://zenn.dev/yusuga/articles/dc0597ea7c0b97e397af をさらに発展させる形

タイミーでは、全ての職能を1チームにまとめた職能横断型チームとしてプロダクト開発に取り組んでいます。
職能横断型チームに属する開発者は1つの専門領域に特化しながらも、他の領域も広く理解していくことが重要だとされています。
しかし、過去に職能別にチームを分けていた名残が強くあり、依然としてiOSのタスクはiOSエンジニアしか担当できない状況が続いていました。
それを打開するために、iOSのプロジェクト構成を見直しました。SwiftPMをプロジェクトの中心に据えることで環境構築のコストを限りなくゼロにしたり、他の領域でも使われつつある宣言型UIであるSwiftUIを導入することで、iOS開発へのハードルを下げてきました。結果、iOS専門外の開発者もPRを投げてくれる状況になりました。

タイミーでの事例を踏まえ、職能横断型組織へのシフトと、それに追従したiOSプロジェクトの変遷をお話しします。

タイミーでは、全ての職能を1チームにまとめた職能横断型チームとしてプロダクト開発に取り組んでいます。
職能横断型チームに属する開発者は1つの専門領域に特化しながらも、他の領域も広く理解していくことが重要だとされています。
しかし、過去に職能別にチームを分けていた名残が強くあり、依然としてiOSのタスクはiOSエンジニアしか担当できない状況が続いていました。
それを打開するために、iOSのプロジェクト構成を見直しました。SwiftPMをプロジェクトの中心に据えることで環境構築のコストを限りなくゼロにしたり、他の領域でも使われつつある宣言型UIであるSwiftUIを導入することで、iOS開発へのハードルを下げてきました。結果、iOS専門外の開発者もPRを投げてくれる状況になりました。

タイミーでの事例を踏まえ、職能横断型組織へのシフトと、それに追従したiOSプロジェクトの変遷をお話しします。