トーク

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における対応と比較しながらお話しします。

MLOpsはML Operationsの略で、データ収集・前処理・学習・デプロイ・監視といった機械学習のライフサイクルの継続的な運用を効率化するための考え方や手法を総称してこう呼ばれています。たとえば、蓄積したデータを用いたモデルの再学習を定期的に自動実行し最新データに合うようモデルを改善し続ける仕組み、モデルを本番システムに自動デプロイする仕組み等が含まれます。機械学習をビジネスで本番運用するために不可欠な考え方として昨今ホットなトピックとなっています。

一方で、Core MLモデルの世界ではMLOpsという考え方はまだそれほど広がっていないように思います。多くの場合は一度学習したモデルを利用し続けるか、手運用で再学習等を行っているのではないでしょうか。Core MLにMLOpsの考え方を導入しするとどのように継続的な運用を効率化できるのか、そのパターンを解説します。

我々は平面の座標を表すのに数字のペア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を用いた計測方法について
• 計測してみてどんな気付きがあったか
• どのように保守性が改善されたか

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

SNSにおけるプロモーションや、Webのユーザーをアプリユーザーに転換させるような施策を実施したい場合にディープリンクを利用したいケースはよくあるでしょう。

ディープリンクを利用してユーザーをアプリに連れてくる際「ユーザーが文脈を理解できている状態」というのは重要で、ユーザー状態に応じたフローを組むだけでは施策の効果を十分に発揮できない可能性があります。

このセッションでは、滑らかな体験でアプリにユーザーを連れてくるために「ディープリンク」を効果的に活用する方法やその仕組みについて紹介します。

話すトピック
・概念としてのディープリンクおよび、ディープリンクを実現するための機能紹介
・アプリのインストール状況や初回設定状況などのユーザー状態に応じた適切な遷移方法
・ユーザーに文脈を理解した状態のままアプリに来てもらうために活用できる仕組み
・コンバージョンの計測方法

ここでの「行動ログ」とは、特定の画面の表示、ボタンのタップなど、ユーザー操作を起点に送信するものを指します。集めた行動ログは、サービス開発上の分析や実態把握に役立ちます。

アプリ開発者は、そのログを仕込む役割を担いますが、しばしば課題にぶつかります。

• いざ分析するとき「ログが足りない！」
  • 「QA時にログ送信、網羅した？」
  • そもそもログ要件が十分に練られていない……
• ……

本セッションでは、行動ログにまつわる悩みの種のうち、ログ実装の「仕込み」にフォーカスして、ミスを防ぐ仕組みや工夫の事例をご紹介します。

トピック

• ドキュメントをベースにした型安全なログ実装コード自動生成
• iOS 14以降で使いやすくなった Logger APIの活用
• QA作業を踏まえたログ実装網羅チェッカー

など

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

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

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

世界中のユーザーへ向けてサービス展開する場合、システムのグローバリゼーション及びローカリゼーションが必要です。

ローカリゼーションではまず「特定言語への翻訳対応」が行われますが、その結果としてアプリの開発フロー内で継続的な「翻訳データの管理」と「テキストの翻訳作業」が必要になってしまいます。

日本語、英語の2言語までは「なんとなくスプレッドシートで管理してみる」が通用しなくもないのですが、対応言語数が増えるほど翻訳データ自体と翻訳タスクの管理コストが増え、結果として運用や品質に対して悪影響が出やすくなっていきます。

本トークでは、12言語に対応している「REALITY」アプリの事例をもとに翻訳フローをどのように構築したか、対応言語を増やした結果どのような問題が起きたか、その問題にどう対処しているか、現状の課題は何で今後どうしようと考えているか、などをお話します。

高度な並行アルゴリズムを提供するSwift Async AlgorithmsにAsyncChannelというものがあります。チャネルとはスレッド間でメモリを共有する手法の1つで、特にGo言語での採用により近年一般的になっています。
本発表ではGo言語での使用例を用いてチャネルの概説を、そしてAsyncChannelとの差異に思いを馳せチャネルについて簡単な認識を持つことが目的です。
スレッド間のメモリ共有は、共有メモリを使い危険領域を排他制御等で保護する手法が一般的ですが、チャネルを使うと同期が入出力としてより素直に表現できます。Go言語にはDo not communicate by sharing memory; instead, share memory by communicatingという格言がありますが、 他方、チャネルとバグの研究を取り上げ現実についても触れたいと考えています。

SwiftUIが発表されてから約3年が経過し、最近ではプロダクトでの採用例も見られるようになってきました。
しかしながら、SwiftUI登場以前から運営しているアプリを完全にSwiftUIへ移行するのは簡単なことではありません。
そこで、小さなComponentから徐々にSwiftUI化を行っていくというのは効果的な移行戦略の1つです。
小さな単位で移行を行うことによって、SwiftUIへ移行する上での課題を素早くキャッチし、改善サイクルを徐々に回しながら移行できるというメリットなどがあります。

本トークでは

• 小さくSwiftUI移行を行う手法
• 小さく移行をする場合のメリット / デメリット
• 移行時の勘所やハマり所

について、実プロダクトで移行を続けている中で得られた知見や具体例と共に解説します。