トーク

正直なところ Core Animation は私にとって、何度も解説を見聞きしたのに、理解した気になれない技術でした。

iOS歴10年目に入ろうという昨年末、私はAppleの公式ドキュメントと対峙することが出来ました。
この技術と決着をつけるためです。

時間の許す限り調査し検証した結果である記事「詳しく知りたいCore Animation レイヤー編」「アニメーション編」を
自身のブログをに公開したところ、ツイッターなどで「わかりやすい」などのリアクションを頂くことが出来ました。

この発表では、Core Animation 紙面上の都合で記事からカットした部分、SwiftUIやUIViewでのAPIとの比較、基礎知識や応用例など、よりブラッシュアップした内容をお届けしたいと思います。

おかわりは自由です。

SwiftUIでViewを構築するのは難しいです。

何も考えずに書くとクソデカViewになります。
複数のViewに分割する場合も、プロパティやメソッドに切り出すのがいいか、構造体を定義するのがいいか迷います。

Viewの命名も迷います。
Atomic Designに沿うのもいいですが、iOSと馴染めない気がします。
UIKitに近い命名はわかりやすいですが、SwiftUIではスマートでないと感じます。

「いきなりぐちってごめんなさい。ウーニャほんとはSwiftUIとなかよくしたいです…！」

このトークは、ウーニャ（私）とみんながSwiftUIのViewの分割と命名について一緒に考えます。
まずはウーニャがViewの分割や命名の考え方を話すので、それについてコメントを頂き、議論してよりいいViewの構築を考えます。

かなりふあんですが、だいじょうぶます。がんばるます。

え？Swift以外使わないのは当たり前じゃね？って思ってるあなた、環境構築やCI/CDのこと忘れてるかな？

そう、これまで我々は周辺技術としてRubyやZshをたくさん使ってきました。でも安全性が高いSwiftに慣れてきた我々は、やはりSwift使いたいですよね！

というわけで、この発表はSwiftだけで環境構築やCI/CDスクリプトを書く方法をお伝えします！

開発期間に余裕がないとき、細かいアニメーションはバッサリ切り捨てられることが多いかと思います。そして、チケットには「2次リリースで対応」なんてメモを残して実装されることはなかった…なんて現象に遭遇したことはありませんか？
このような経験を元に、新機能を3ヶ月という短期間で集中開発した際に培ったノウハウを伝授いたします。

・Moya 利用時の Stub 活用術
・XcodePreviews 活用術
・アニメーション処理の共通化術

まずは、バックエンド開発待ちという状態ゼロを実現させます。次に、XcodePreviews を利用することで、頻度高くレイアウト・アニメーションをデザイナー確認できる環境が整います。
最後に、共通化によってアプリ全体で統一した操作感に仕上げることが可能となります。

AkkeyLab の原稿ともリンクしていますので、明日からでも実践・成果を実感していただけます！

SwiftUIでAtomic Designを使った特の責務分担の考え方と役割について説明していきます。

1. Atimic Designとはなにか？
   • Atomic Designの説明
2. なぜSwiftUIでAtomic Designを利用するメリットの説明
   • SwiftUIでAtomic Designを使用すると解決できる問題
3. SwiftUIでAtomic DesignにUIを切り分ける実例
   • SwiftUIで実際のコードを見ながら切り分ける実例を紹介していきます。

• ターゲット
  1.Swiftを学び始めたけどファイルの細分化をどの単位でしていけばいいのかがわからない
  2. 同じコードをいろいろな場所で何度も書いてしまっている
  3. webフロントの開発を今までやっていてこれからSwiftを学習しようと思っている

この発表では、Swift アクターモデルと Elm Architecture を融合したフレームワーク「Actomaton」について、実用例を中心に紹介します。

https://github.com/Actomaton/Actomaton

Composable Architecture では飽き足らないマニア向けの内容を予定しています。

1. Actomaton の簡単な紹介
2. アプリの状態管理の基本的な例：「ディープリンク」「タイムトラベル」
3. 並行タスクキューを用いた副作用管理の例：「並行ダウンローダー」「並行 Web クローラー」
4. アクター（オブジェクト指向）と Elm Architecture （関数型プログラミング）の両方を用いた計算モデルの親和性について
5. （時間があれば）やはり圏論。圏論は全てを解決する。

2014年から趣味で公開し開発を継続しているiOS Webブラウザアプリ開発で溜まった知見を振り返りまとめます。
余裕があればSwiftUIでサンプルアプリを作り公開します。

この辺りの話になると思います。

• 複数のWKWebViewの扱い
• ブラウザサイドJavaScript
• 認証・セキュリティ
• コンテンツブロック
• デフォルトブラウザ申請
• App Extension
• webview内ジェスチャ
• favicon・サムネイル処理・メディア再生など

let theme = "String Interpolation"
print("(theme) deep dive")

これは多くのプログラミング言語に備わる機能、String InterpolationのSwift実装です。
一般的に変数をプレースホルダーに展開する機能ですが、Swiftでは拡張手段が提供されていて、高度で静的な文字列操作を可能にします。
さらにSwuiftUI、特にTextの機能が充実したことで、単純なStringとしての表現力を超えた活躍を期待できます。
このトークでは、SwiftにおけるString Interpolationの仕組み、実現方法を解説して理解を深め、典型的な使用方法を学びます。
次にSwiftUIを例に、Frameworkと組み合わせた応用を目指します。

String Interpolation活用の新たなアイディアに繋げましょう。

タクシーアプリ「GO」は、2020年9月にリリースしました。
その頃は、iOSチームとしてアプリ開発を行なっており、日々「GO」の新機能を開発する日々でした。
しかしながら、同じ「GO」のプロダクトを開発するメンバーがPdMやデザイナーも含め40人を超えるため、
どうしても意思疎通がうまくいかなかったり、意思決定が遅かったりと、いくつかの問題を抱えていました。

そこで、2020年6月から身近なiOSチームという比較的ミクロな改革、2021年5月からは、PdMやデザイナーも巻き込んだ、プロダクト開発チームとしてのマクロな改革を行いました。
そえぞれ何を軸にして行なっていくか、目的も異なってきます。どのような課題感から、何を思い、どのような変革を行なっていったか、是非リーダーやマネージャーを担っているエンジニアの方々だけでなく、これからリーダーやマネージャを目指す方に聞いてもらいたいです。

WWDC 2019 で発表された PencilKit を利用することで、数行のコードで 標準メモアプリと同様の手描き体験をアプリに導入できます。

発表に先立ち、日本経済新聞社の紙面ビューアーアプリでは、Apple Pencil を用いた紙面画像にメモやハイライトを書き込める機能をリリースしました。

アプリの機能要件を満たすための独自拡張の実現には、様々な制約が立ちはだかりました。
たとえば、キャンバスに画像を載せる、ズームやスクロールなどビューアーとしての操作は残しつつ書き込みを一時的に無効にするなど、一見すると単純そうですが一筋縄ではいきません。

本セッションでは PencilKit の開発ノウハウを、ドキュメントと内部の動きから洞察した知見の両面から解説します。開発経験を踏まえ、紙の新聞に書き込みを行うユーザー体験をどのようにアプリへ落とし込んでいったか説明できればと思います。

SnapのCustom Landmarker、ARCoreのGeospatial API、NianticのLightship、そしてARKit 6のLocation Anchor、他にもありますが、これらはすべてVPSと呼ばれるものです。

ここで言うVPSは“Virtual Private Server”ではなく“Visual Positioning Service/System”です。

緯度経度をもとにするGPSとして馴染み深い“Global Positioning System”に対し、画像による空間情報をもとに自己位置推定する技術がVPSです。

本セッションでは、今後のARに関する要素技術として重大な位置づけになると考えられる “VPS”そのものとその周辺技術、実際のユースケースや概況に加え、いずれかのVPSソリューションを用いた「実際に動作するデモ」を交えて解説します。

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

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

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

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

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

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

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

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

我が家にはたくさんのIoTガジェットがあって、カーテンや玄関の鍵を開け閉めしたり、大活躍です。
しかしエンジニアという人種は、既存の機能では満足できず、カスタムして、色々作り込みたくなるものです!
そこで日頃お世話になっているSwift、我が家に余ってたラズパイ、そしてiPhoneの力を借りて、より便利で安全なスマートホームを目指した取り組みを共有します。
具体的には…
●ラズパイでのSwiftやServerSideSwiftフレームワークのセットアップ
●iPhoneのセンサー情報をServerSideSwiftのAPI経由でラズパイのDBに書き込む方法
●ラズパイと既存のIoTガジェットの連携方法
●SwiftでラズパイのGPIO経由でセンサーやLEDを操作する方法
などをデモを交えて紹介する予定です。

ぜひ皆さんもSwiftを使った自宅のスマートホーム化、電子工作を楽しみましょう！

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

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

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

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

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

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

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

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

宣言的UIフレームワークのSwiftUIの登場により、以前に比べUIコンポーネントが作りやすくなりました。
そこで弊社ではSwiftUIの特徴を活かし、社内のデザインシステムをパッケージとして開発・運用することで、楽に速く正確にUIを実装することを可能にしました。
また、パッケージ内のコンポーネントを一覧で確認できるカタログアプリも開発し、実装コストだけでなく、仕様検討時のコミュニケーションコストやデザインの手戻りも削減することができました。
本セッションでは、デザインシステム構築までの開発プロセスと実際に運用してみて得られた知見について紹介します！
デザインシステムを構築し、みんなで楽に速く正確にUIが作れる世界線へ！

【コンテンツ】
デザインシステム

• 概要と構築の経緯
• 実装方法と運用事例
• 構築して得られた恩恵

カタログアプリ

• 概要と活用事例
• 開発して得られた恩恵

SwiftはiOSアプリケーション開発のみならず、Linux上で動作させてWebサーバアプリケーションを立ち上げることができます。
iOSエンジニアにとって、SwiftでAPIサーバが書けることほど快適なものはありません。
書き慣れた文法で型安全な実装ができ、またリクエスト・レスポンスのモデルをクライアントと共有することまでできます。
Swift5.5で導入されたasync/await構文は、さらにクライアントコードとの親和性を強化しました。

このトークでは、Swift on serverをどのように始めていくか、開発環境からデプロイまでの基本的なステップ、ハマりどころ、async/await導入によるコードの変化、型によるクライアントとの強固な連携などを紹介していきます。

皆さん多かれ少なかれ正規表現を使ったことがあると思います。
コマンドラインツールで、エディタの検索で、そしてNSRegularExpressionで。
単純な文字列検索に比べ、正規表現はとても表現力豊かでパワフルな検索を可能にします。

Swift Evolutionにも正規表現に関する多くのproposalがあり、Regex型やRegexリテラルなどが正式に実装される日も近いでしょう。
しかしこの正規表現とは一体何者なのでしょうか？
どんなものが表現でき、どんなものが表現できないのでしょうか？

多くのメタ文字や演算子記号があるためとても複雑なものと思われがちですが、実際にはたった3つの文字列の演算ルールだけで構成されています。
本トークでは状態遷移図の一種であるオートマトンからスタートして正規表現の原理を紐解きその限界を探っていきます。