トーク

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プロジェクトの変遷をお話しします。

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

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

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

AR表現を作る際にカメラの動きを合成用PCに送信する必要があり、その標準となっているのがFreeDというプロトコルです。

このプロトコルをSwiftで実装しiPhoneから情報送信できるようにしました。
プロトコルの概要を解説し、実装内容についてコードを見せながら説明します。

• macOSアプリとして実装したFreeD送信シミュレータ
• iPhoneから送信したデータを元にカメラを連動させたxR表現

のデモをします。

デモ、ソース解説を中心とした、ARとiPhoneの可能性を開く楽しいセッションです。

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の仕組みについて5分で紹介します。

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つ組の数字を使うことがあります。
冗長に思える要素を追加することで何が便利になるのかを解説します。