トーク

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

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

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

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

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

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

1. そのDIって必要！？
2. 無駄なprotocol定義
3. バケツリレーするだけのコンポーネントたち
4. なんでもリアクティブ
5. 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プロジェクトの変遷をお話しします。

KMMやFlutterなどマルチプラットフォームな開発環境が脚光を浴びています。でもちょっと待ってください。あの人気の言語RustもiOS、Androidの両方で動くのです。Rustを使ってビジネスロジックを書いてみませんか。
このトークでは

• ネットワークアクセス
• ストレージアクセス
• モデルの共通化

など、ビジネスロジックを書くためにはiOSでRustで何ができればいいのか、検証した結果をお話しします。

Apple公式の認証システム「Sign in with Apple」。
Twitter等のサードパーティのログインサービスを提供している場合、Sign in with Appleの対応が必要となります。

そのため、Sign in with Apple対応をされたことがある方も多いのではないかと思います。
Sign in with AppleはOAuth, OpenID Connectが前提知識として必要となりますが、皆さんは理解をした上で自信を持って対応することができましたか？
特にサーバーサイドが担当する部分に関しては、公式ドキュメントだけでは理解が難しい部分もあります。

本セッションでは、前提知識として必要なOAuth, OpenID Connectの解説をしながら、Sign in with Appleの仕組みとアプリ側で必要な実装, サーバー側で必要な実装について紹介します。

ここ数年、格好良いAR表現が付いた映像が増え、皆も色々な所で目にしていると思います。
自分でも実装して実現したくないですか？

私は昨年からARを本業としてAR表現があるリアルタイム配信をいくつか実現してきました。
Unreal Engineを使いカメラとトラッキング機材を中心に連携し作成していきます。

その実現に必要な要素を解説しスキルを伝授していきます！

• ワークフロー解説
• CG原点を置きCGの空間と現実空間を一致させる方法
• カメラトラッキング方法
• Unreal Engineを使った基本的なシーン作成
• iPhoneを使う手法

デモと手法解説を軸に、AR表現に興味を持った人がさらに興味を持つようなセッションです。

2021年12月から9ヶ月（２０２２年８月発表時点で）４人体制でiOS14でComposable Architectureで開発チームの１メンバーとして開発してきました。
Composable Architectureのここが良かった悪かったという経験を主観的に話したいです。
今まではUIKitではRxSwiftでClean Architectureでの開発してきたので、
その経験と比較してどうだったかについても触れます。

これからUIKitからSwiftUI導入に向けて、アーキテクチャの変更、
SwiftUI時代のアーキテクチャの一つの選択肢としての経験談が話せたらと思います。

「アプリエンジニアが少ない……。」
皆さんも一度は口にしたことありませんか？
新卒・中途問わず、アプリエンジニアの採用に苦戦していませんか？

一口にiOSアプリ開発と言ってもUIKit・SwiftUI・Flutterなど様々な技術選択があり、最近は特に応募者と企業のミスマッチが起こりやすいと感じています。

そこで私たちは「アプリエンジニアが居ないなら育成しよう！」と考えて育成プロジェクトを立ち上げ、運用中です。

このトークでは実際にアプリエンジニア育成プロジェクトを運用している経験をもとに、
・メンターが少なくても始められる、育成プロジェクトのつくりかた
・多すぎる技術スタック！何から教えていくべきか
・育成プロジェクトの成果と課題
・アプリ開発に魅力を感じてもらうために

について話します。このトークを通して、みなさんとアプリエンジニア不足を解消する方法を考えられるとうれしいです。

ソフトウェア開発においてテストは品質を高める上で重要な作業の一つです。
ではテストとは誰がやるべき作業でしょうか。QAと呼ばれるメンバーにテストを丸投げしていませんか？

開発者でもテストとの関わりとしてユニットテストを書くことは一般的になってきたかもしません。しかしそれがどんな効果があるか理解して書けているでしょうか。
リーンやアジャイル、DevOpsが広まるにあたってスピードと品質の両立が求められる昨今のソフトウェア開発において、開発者としてもテストのやり方や考え方を変化させる必要があります。

このトークでは、開発生産性と品質を高めながら開発するために、開発者がどのようにテストと関わっていくべきかを話したいと思います。

リリース前のQAで不具合が大量に見つかってしまうと修正作業に忙殺される、リリースが遅延してしまう、時には不十分な品質でリリースしてしまうということが起こりえます。
そうならないためには早期に不具合を発見、または不具合の混入を防ぐことが重要となります。

すでに問題が起こってしまっているチームでよく実施されるのが不具合分析です。不具合は分析することで改善へのヒントに繋がります。
そうした不具合分析の中で、ODC分析という手法があります。
ODC分析では開発プロセスに着目して、その質を可視化することで改善へとつなげていきます。
私達のチームではそんなODC分析に取り組みました。

このトークでは不具合分析の中でもODC分析という分析手法について手法の説明、取り組んだ結果について話します。それにより問題を抱えているチームが不具合分析をやってみようと思うことや、やり方の参考になればと思います。

2020年8月、フォートナイトを運営するEpic Gamesは、App Storeを通してAppleが徴収する30%の手数料に対して異議を唱え、App Store以外でのアプリのインストールを可能にするサイドローディングの提供をAppleへ要求する訴訟を起こしました。

これに対しAppleはセキュリティリスクを著しく高めるとして反論し、翌年2021年9月にEpic Gamesの申し出は棄却されましたが、この訴訟を皮切りに各国で調査が行われ、Appleに対してサイドローディングやサードパーティの決済手段を認めさせようとする動きが活発化しています。

本トークでは、各国のAppleに対して求めている公平性とそれに対するApple側の対応についてまとめながら、Appleがサイドローディングを認めることにより高まるセキュリティリスクについて、Googleにおける対応と比較しながらお話しします。

我々は平面の座標を表すのに数字のペアx,yを使い、3次元プログラミングでは空間の座標を表現するためにさらに座標の要素を追加してx,y,zの3つ組みを使います。
ではsimd_float4、SCNVector4などに存在する4つめの要素wは何なのでしょう？
まさか4次元空間を扱うためのものなのでしょうか？

これらはただの4つ組のデータに過ぎないため何の情報を格納するかは自由です。
アルファ値を含んだRGBAの色情報を格納してもいいですし、回転軸の方向をx,y,zに格納し、回転角度をwに格納しても良いでしょう。実際SceneKitではそのように使用する場面もあります。

しかしこの4つ目の要素、ちゃんと3次元プログラミングにおいて図形的に重要な意味があるのです。
2次元を扱う場合にも実は同様に3つ組の数字を使うことがあります。
冗長に思える要素を追加することで何が便利になるのかを解説します。

ブログを自作するには、Hugo（Go）、Gatsby（JavaScript）、Jekyll（Ruby）などのフレームワークを使うことが多いと思います。

「ブログをSwiftで作りたい…！」

こう思ったことはありませんか？

実はPublishというSwiftでブログを作れるフレームワークがあります。
こちらを使うことで、HTMLをSwift、記事をMarkdownで書くことができます。

私は実際にPublishを使ってブログを運営しており、そこで学んだコツやノウハウを紹介します。
リポジトリをパブリックにすれば、無料でGitHub Pagesへデプロイまでできるようになります。

このトークを聞いて、ぜひSwiftでWebサイトを作ってみましょう！

SwiftUIのPreferenceKeyは子Viewが親Viewと通信する際に利用できる便利な仕組みです。
PreferenceKeyをうまく活用すれば、SwiftUIで実現できないと思っていたView が作れるようになることもあります。
しかし、PreferenceKeyに関する情報は少ないため、とっつきにくいと感じる方もいるのではないでしょうか。

このトークでは、以下の内容で発表しPreferenceKeyを今日から使えるようになることを目指します。

• PreferenceKeyの基本とその仕組み
  • 様々なAPIに触れつつ、どのようにPreferenceKeyがViewに作用するのか探ります
• 複雑なViewの開発方法から学ぶ PreferenceKey
  • 上から順に詰めていくGrid実装
  • あるViewを任意のViewの座標にアニメーションさせる実装

DocCは、Swiftプロジェクト向けのソースコードベースのドキュメント生成ツールです。
このDocCがXcode 13.3以降、アプリ開発での活用を想定して進化しました。しかし、アプリ開発におけるドキュメントは既にMarkdown等で用意しているプロジェクトも多く、DocCをわざわざ導入しようと思わないかもしれません。

そんなプロジェクトでDocCを活用するのに便利なのが、ドキュメント作成時の生成物であるDocumentation Archiveの利用です。これは、ドキュメントを生成するために必要なclass名や依存関係等の情報が構造化して詰め込まれたものです。これを用いて、プロジェクトの依存関係を自動で見える化し、リファクタリングや新メンバーへの状況共有に役立てることができます。
このトークでは、その具体的な方法とDocumentation Archiveの構成等についてお話します。

iOSアプリ開発に限らず、コードを保守しやすい状態に保つことはとても重要です。
では保守が難しい箇所を特定するにはどうすればいいでしょうか。また、リファクタリング後に何をもって保守がしやすくなったと判断すれば良いでしょうか。
その方法の一つにMaintainability Index(保守容易性指数)の計測があります。
Maintainability Indexとはその名の通り、コードがどれくらい保守しやすいかを表す指標のことであり、VS Codeでは一部の言語で計測することができます。

このトークでは以下のトピックを話します。

• Maintainability Indexとは
• SwiftSyntaxを用いた計測方法について
• 計測してみてどんな気付きがあったか
• どのように保守性が改善されたか

このトークがみなさんのコードの保守性の改善のお役に立てば幸いです。

iOSアプリの配布や、リリース作業のように、
「手作業で繰り返し、自動化が可能で、長期的な価値がない、サービスの成長に比例して増加する」作業は、SREの原則の中でToil(トイル)と呼ばれています。
Toilは、機能開発に集中していたりすると、中々手が回らなかったり、作業への慣れや習慣化によって改善が行われにくくなります。

Toilに対して、よく考えずに自動化を行ってしまうと、システムが複雑化していくことで、その自動化を行った人しか理解できずに属人化が起こります。
そのため、日頃から作業が持つ本質的な価値にフォーカスして整理し、シンプルかつ誰でもメンテナンスできるようにしておくことが大切です。

このトークでは、チームの開発者体験を向上させるために、実際に観測したToilを例に、どのようにカイゼンの試行錯誤を行っていけばよいか、また具体的にどんなカイゼンしたのかをお話しします。