トーク

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

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

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

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

おかわりは自由です。

え？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を学習しようと思っている

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やデザイナーも巻き込んだ、プロダクト開発チームとしてのマクロな改革を行いました。
そえぞれ何を軸にして行なっていくか、目的も異なってきます。どのような課題感から、何を思い、どのような変革を行なっていったか、是非リーダーやマネージャーを担っているエンジニアの方々だけでなく、これからリーダーやマネージャを目指す方に聞いてもらいたいです。

巷では正しい設計、正しい実装、正しいアーキテクチャなど……強迫観念に近い「正しさ」を求めるがあまり、プロジェクトの後半になってなぜ私たちは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プロジェクトの変遷をお話しします。

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導入によるコードの変化、型によるクライアントとの強固な連携などを紹介していきます。

Xcode 13最大の新機能と言えばVimキーバインドの登場ですね！
多くの開発者が利用しているVim/NeovimのキーバインドがとうとうXcode標準で使えるようになりました。

Xcode 12まで、多くのVim好きの開発者はVimキーバインドを利用するために、
Pluginの形式で提供していたXVimというソフトウェアを利用していました。

このトークではそんなXVimないしXcode Plugin業界に襲いかかってきた
macOS, Xcode, Swift, AppleSiliconの様々な技術的ハードルについてメンテナーが振り返って供養します。

シェーダアートとはシェーダと呼ばれるGPUで実行されるプログラムを記述することで様々なイメージをスクリーン上に表現する手法のことです。
シェーダでは各ピクセルの座標値と共通のデータを入力として色を出力する関数を記述するだけですが、その手法は様々で驚くべき表現が可能となります。

3年前のiOSDC2019「めくるめくシェーダアートの世界」ではシェーダアートの原理を細かく説明しました。
しかし原理や基礎から丁寧に説明することに重きを置いたため、「レイマーチングを使用した3D表現」に関してはあまり時間を割くことができませんでした。
レイマーチングを駆使してからがめくるめく世界への入り口であるというのに！

そこで本トークではレイマーチングを使用した3D表現の解説に重きを置いて再びシェーダアートの原理とその魅力を語ります。

依存性の注入(DI)によりコンポーネント間の結合度を低めるのは良いことですが、コンポーネントの再利用にかかる依存関係解決のコードはボイラープレートになりがちです。この問題を解決する手段として、依存関係およびそれらのライフタイムを管理するコンテナクラスであるDI Containerの導入が考えられます。

本トークでは、SwiftUIで開発されたiOSアプリにDI Containerを段階的に導入しながら、各ステップでどのような問題が解決されていくかについてお話しします。

アジェンダ
・DIおよびDI Containerについて
・DIの導入
・DI Containerの導入
・動的な依存関係の解決
・静的な依存関係の解決
・コードの自動生成による静的な依存関係の解決
・DI Containerでのスコープ管理
・マルチモジュールにおけるDI Container

macOSやiOSのアプリケーションアイコンは強いスタイルがが存在します。「立体的に」とか「シンプルに」とかHIGでも書かれているけど、書くは易し。実際には何をどう描けばその立体感は実現するのでしょうか。特にmacOSのアイコンは物体のリアリズムが求められ、リッチな陰影表現が必要となります。大丈夫です。3Dモデリングをせずとも、ぼかしやグラデーションなどの組み合わせでこう言った表現は実現できるのです。
このセッションでは、CotEditorやSparkleフレームワークなどのアプリケーションアイコンを手掛けた1024jpが、Illustratorを使ってmacOSアプリケーションアイコンを解説しながら実際に時間内でイチから描きます。これはライブです。

近年、Human computer interaction（HCI）の研究分野では機械学習を利用しスマートフォンのインタラクションをより豊かにする研究が多く行われています。

・音声認識を利用しスマホで叩いた物体を認識
・画像認識を利用しApple Pencilの機能を拡張
・イヤホンのセンサを活用した行動認識

これらの研究を応用することで例えば、スマホで欲しい物を叩くだけでECサイトでその物を注文できるようになったり、非接触でモバイル端末の操作ができたりと今までのアプリに無いようなインタラクションを実現できます。本セッションではそのような研究事例を紹介し、実際にCreateML/CoreMLでモデル構築、デモアプリの実装を行います。CreateML/CoreMLや機械学習に興味がある方、既存のアプリにはない面白い機能を実装したい方などに興味を持っていただける内容です。

abceedアプリにおけるiPad対応の経緯と現在の方針について詳らかにします。
abceedは学習アプリとしてtoB向けにも展開していますので通常よりもiPadユーザーの割合が多く、広い画面で気持ちよく学習できるようデザインの最適化を積極的に行っています。
今回は私からアダプティブレイアウトのひとつのやり方としていろいろなトピックを共有し、みなさんのなにか議論のきっかけとなれば嬉しいと思っています！
以下のようなことを話す予定です。

• 基準とする画面サイズの決め方
• SizeClassを使わない理由
• SplitView対応のポイント
• ハードウェアキーボードとキーボードショートカット
• 工数の見積もり
• 品質担保(QA)

iOSのSwiftUI、AndroidのJetpack Compose、そしてマルチプラットフォームのFlutter…

モバイル開発は宣言的UIの時代に突入しました。
このセッションではこれら3つのフレームワークの特徴や考え方、具体的な実装方法を比較します。

他フレームワークの技術から得られる新しい発見、全てのフレームワークに共通する重要な概念を明らかにします。

昨今話題のFlutter。
実はFlutter内部ではUIKitやMetalといったiOS技術が使われています。
このセッションではUIKitやMetalの解説と共に、Flutterの内部の仕組みを紐解きます。

「タッチイベントはどのように処理されてる？」
「どうやってレンダリングしてる？」

そこが分かればもう怖くない！