トーク

アンカンファレンスで講演された内容です。

デジタル化粧は、映像を加工することで実際にメイクをしているように見せる技術です。
昨今では物理的なメイクを再現するだけでなく骨格や目の大きさを調整したりすることも出来るようになり、セルフィーを投稿する敷居を下げている技術の一つでもあります。
そんな「顔のAR」とも呼べるデジタル化粧はソーシャルライブでは無くてはならない存在となりました。

このセッションではソーシャルライブサービスの実例を通して、デジタル化粧機能の需要の傾向や仕組みを学びます。
また、高価なデジタル化粧SDKを利用せずにMLやMetalを使って実装するにはどうすれば良いかを紹介します。

iPhoneやスマートフォンにおける「カメラ」という機能。
写真を撮る、という日常的に行われている行動ではありますが、その実撮影という機能を実現するために様々な技術的処理が使われています。

このセッションでは、「カメラが光を取り込む仕組み」から「iOSで取り込んだデータを画像化する」という所を深掘りし
写真撮影という技術を皆さんと一緒に紐解いていければと思います。

以下、アジェンダ(仮)

1. そもそもの「写真撮影」における仕組み
2. 写真の表現を決める3つの値 F値・シャッタースピード・ISO感度
3. iPhoneにおける「被写界深度撮影」とは
4. iOSでマニュアル撮影アプリを作る
5. RAW画像とは
6. iOSでRAWを加工してみる

Apple Watchが登場し、WatchKitフレームワークが発表された当時は各社こぞって対応アプリ（実態はApp Extension）をリリースしたものでした。しかしApple Watchのデバイスとしての性能はとても貧弱でできることは非常に限られており、また開発環境は著しく不安定だったこともあり、watchOS 2の頃には開発者の間でのwatchOSアプリ開発ブームは去っていきました。

しかしそれから数年経ち、Apple Watchの性能は大きく向上し、watchOS 6ではついにIndependent Appも作れるようになりました。多くの機能（フレームワーク）がApple Watch側で動作することになり、「こんなアプリがウォッチ上で動いたらいいな」というアイデアの実現可能性は昔とは比べるべくもないほどに上がっています。

本トークでは、Apple Watch / watchOSリリース当初はできなかったが今ではできるようになったことを中心に、「watchOSアプリ開発の今」についてお話しします。

みなさんは音声通話機能を実装したことがありますか？

iOS 10 から導入された CallKit を使うと、純正電話アプリのような見た目の着信画面や通話中画面を表示することができます。また、割込通話や割込通話による保留と保留解除なども簡単に対応できます。

そんな素晴らしいフレームワークですが、いつまにか Apple 公式サンプルコードは提供されなくなり、ドキュメントや Web 上の記事などを頼りに試行錯誤する必要があるのが現状です。

このトークでは、バックエンドに Twilio を用いて、PushKit と CallKit を使用して通話機能を実装する過程で得た知見を共有します。
具体的には、CallKit および PushKit の概要および使い方、効率的なデバッグ方法に加え、Twilio のワークアラウンドや、気づきにくい致命的な CallKit のバグと、それにどう対処したのかについてもご紹介します。

WWDC19で発表されたCombine.frameworkはリアクティブプログラミングという言葉では発表されなかったものの、複雑になりがちなイベント処理をデータの流れとして統一的に扱い、イベントへ反応する処理を組み合わせる宣言的なコーディングを実現します。
このことによりCombine.frameworkは最近のリアクティブプログラミングのパラダイムに沿ったフレームワークと言えるでしょう。これに備え、我々はリアクティブプログラミングのパラダイムを仕組みから理解する時がやってきたのです。

このトークでは、現状のリアクティブプログラミングフレームワークであり広く普及しているRxSwiftを構成するソースコードを解説し、それを参考にテストコードを交えながら最小限の「偽・リアクティブプログラミングフレームワーク」をトークの中で作成していきます。

もちろん最小限の構成で理解を促進するものなので、非同期プログラミングのためのフレームワークとして本来は必須であるスレッドセーフ、メモリ管理、スケジューラの概念は捨てます。トキメかないので。

説明のため必須なものまで捨てられた「偽・リアクティブプログラミングフレームワーク」によって、今まで雰囲気で知っていた次のルールが心で理解できるはずです。

• Coldなストリームはなぜsubscribeされないと動作しないのか
• SubjectがObservable/Observerの性質を持つというのはどういう意味か
• ColdをHotなストリームに変換する具体的な方法
• Hotなストリームがsubscribeされても1回しかイベントを発生しないとはどういう原理か

本セッションの進行とともに、皆さんには「理解したわー。リアクティブプログラミング完全に理解したわー」という感想を持っていただければ幸いです。

多言語対応はLocalizable.stringsやXcodeのツールをうまく使うだけでは終わりません。
例えば、文字を装飾していたり、レイアウトやプレースホルダーの順番が変わるなどさまざまな課題があります。

このセッションでは実際に多言語対応するための運用フローやコーディングで気をつけるべきことを話します。

◯ 多言語対応の基本技術(Localizable.strings)
◯ 翻訳SaaSの導入
◯ NSAttributedStringでの装飾
◯ 画像に文字が入っている場合の対処法
◯ 多言語対応のデバッグ

iOSDC 2017 でのトーク「Swift で数学のススメ」から 2年を経て、 SwiftyMath は ver 1.0 となりました。
このトークでは SwiftyMath のコードをベースに、抽象代数学の入門として

・基礎的な概念である「群・環・体」
・具体例としての数（整数・有理数・実数・複素数）・行列・多項式
・剰余類環、中国剰余定理、代数拡大

などについて解説します。これらの概念は数学専攻で学ぶもので、初学者にはハードルの高いものですが、抽象的な公理を protocol として、具体的な対象を struct として実装したコードと合わせて解説することで、Swift に慣れている人ならスンナリと理解できるようになることを目指します。

Swiftで代数学入門： https://qiita.com/taketo1024/items/bd356c59dc0559ee9a0b
SwiftyMath： https://github.com/taketo1024/SwiftyMath

あらゆる人が、あなたの提供するアプリの恩恵を受けられるように。
あらゆる人が、あなたの提供するアプリをより便利に使えるように。

アクセシビリティ対応と言うと特定の誰かのための対応だと思われ、優先度が低くなってしまいがちです。確かにアクセシビリティ対応は特定の誰かのための対応という側面もありますが、すべての人のための対応でもあります。いつも使っているアプリが、手を使わずに使えるようになったら。もっと使う手間を省けたら。夢は広がるばかりです。

「とはいえアクセシビリティ対応をしても一般ユーザは使ってくれないのでは？」そう思う方もいると思います。しかしアクセシビリティ対応で可能になることをきちんと理解して実装、広く告知をすれば、一般ユーザも便利に使えるような体験革命ができるかもしれません。

このトークでは、Appleがどのようなアクセシビリティ機能を提供しているのか、そして私たちiOSアプリ開発者はどのような実装を経て、どのような体験をユーザに提供できるのかについてお話します。

【目次】

・アクセシビリティ最新情報（WWDC2019 Keynoteより）
・設定 - 一般 - アクセシビリティから何ができるのか
・視覚のアクセシビリティ
　・文字サイズの変更に耐えうるデザイン作り
　・VoiceOverにきちんと対応するには
　・アプリデザインとコントラスト
・聴覚のアクセシビリティ
　・Siriはどこまでユーザを楽にするのか
・身体のアクセシビリティ
　・Voice Controlに見るアプリの未来

Animojiにも使われているTrueDepthカメラを使って3Dモデルの表情を動かす表情トラッカーを作りました。webカメラを用いて顔認識する他のシステムよりも精度高く、細かく、感情表現に必要な顔のパラメータを取得できるTrueDepthカメラの本気をお見せします。

表情トラッキングの精度以外にも、ARKitのおかげでバーチャルYouTuberを運用するにあたって地味に嬉しい機能をたくさん獲得しているので、プロデュースの現場の目線から面白おかしく紹介できればと思います。

私が個人的に開発している# Typeというアプリには、iOS 13が発表されるより前にRxSwiftを利用せずにDark mode機能を導入しました。導入するにあたって、

• Dark mode機能の考え方
• 実装方法
• iOS 13以降への対応

を紹介します。その上で実際にアプリにDark modeを導入する際に発生した表示崩れ修正地獄についても紹介します。

このLTはコードの解説というよりは体験共有に比重を置いたLTです

Swiftの関数内でIntのような型(struct)のインスタンスを確保すると、スタックのメモリ領域に格納されるということは過去のWWDCセッションでも語られています。「スタック」とはメインメモリ上の領域です。CPUが演算をするときには「レジスタ」という高速なデータ領域を利用します。メインメモリはCPUのレジスタに比べてとてもアクセス速度が遅いことが知られています。一般的には変数は「スタック」に確保することになっていますが、実際にはCPUレジスタを使って高速化したほうがよい気がしますよね? しているはずですよね? でも確証がありません。

決してSwiftコンパイラに詳しくない私は自分で調査するという発想になかなかならず、疑問を抱えたまま過ごしていました。
WWDC19に参加することができたので、かねてよりの疑問をのラボで聞きました。しかし直接の回答にはたどり着けません。いただいたアドバイスは「LLVM IRとかアセンブラ読むといろいろわかって面白いよ」と。
覚悟を決めて、LLVM IRやARM64のアセンブラを読みました。

雰囲気で「こう動いている気がする」と思っていたことが明確になり「Swiftわからない」という気持ちが減りました。そして、その過程はとても面白い体験となりました。

決してSwiftコンパイラに詳しくない私が、どのように結論にたどり着いたのかの体験を共有します。

GoogleやFacebookといった大規模開発では、モノレポと呼ばれる1リポジトリで複数のアプリケーションを運用するフローが取られており、実装の共通化が計れるなど、多大なメリットを享受することができます。
しかし、モノレポでの運用ではBitriseなどのCICDツールへの影響は大きな課題となります。
リリースフローのロジック、各種パラメータを分離するためには、どのアプリケーションへのリリースアクションなのかを正しくCIツール側がフックできるようにしなくてはいけません。
また、複数リリースフローが走った場合にhotfixは正しくmasterブランチに、場合によっては別のリリースフローに対しても反映させる必要があります。
本トークでは実際にチームで複数のリリースフローを同一レポジトリで共存させた経験から、その解決策を余すことなくお話しします。

• モノレポ戦略時のGitHubFlow、GitFlow、GitlabFlowへの影響
• モノレポ戦略時に起こりうる事故
• 運用フローでどうやってそれを防ぐか

WWDC2019でSwiftUIが発表され、iOSアプリ開発の新たな時代が幕を開けようとしています。
しかしSwiftUIが使えるのはiOS13からです。では我々はiOS12が世間一般から退場するまで何も出来ないのでしょうか？
そんなことはありません。来るべきSwiftUIでの開発に向けて我々が間違いなく行うべきことが１つあります。それはリファクタリングです。
このLTでは来るべきSwiftUIでの開発に備え、我々が今から出来る既存アプリのリファクタリングを大きく分けて3つ紹介します。

• UI開発のコンポーネント思考化
• プレゼンテーションとドメインの分離
• 依存性注入の導入
  そしてなぜこれらを行うべきか、Appleが公式に一般公開しているSwiftUI Tutorialsの中から特に以下のトピックに注目しつつ、解説します。
• Use UIKit and SwiftUI Views Together
• BindableObject / EnvironmentObject
• PreviewProvider

ARKitってうまい具合に、床や壁を認識してくれるんでしょ？

そんなふうに考えていた時期が私にもありました..。

壁にARで仮想のポスターを貼るアプリを開発する際に
ぶち当たった壁。それは壁の認識。

「ほ と ん ど の 壁 は 特 徴 量 が 少 な く て 認 識 で き な い！」
※ ARKitの水平面、垂直面認識には一定以上の特徴量が必要です。

では、どうやったら壁にARでポスターを貼れるのか….。

文字通り壁の為に、壁に向き合い続けた1ヶ月間で得られた
ARKit開発にまつわるTipsや教訓を5分でまとめてご紹介します。

【対象の方】

• そろそろARKitにちょっと触れてみたい
• ARKitの床、壁認識の方法に興味がある
• ARKitのUI事情に興味がある
• ARKitで仮想の壁をつくる方法に興味がある（ニッチ）

今年もiOSDCのプロポーサルを考える季節がやってきましたね。一人でたくさん応募できるので、たくさん書くぞ！と息巻きます。かといって、たくさん出すのは骨が折れます。もし、採択されるかどうか事前にわかれば…？

このトークでは、iOSDC4年分のプロポーサルを使って、判別機を作成し、実際に採択されるか判別してみます。

iOSエンジニアが転生してブロックチェーンエンジニアになりました。
と思いきや、私はいま、暗号資産関連の法改正に向けて、法律を学び、調査報告や提言、要望を作成しています。
これは、アプリケーション開発の前の、開発環境構築の前の、社会環境構築です。
プログラムも法律も"Code"です。どちらも世界を変えるものでしょう。
Write the "code", Change the world.
日本は民主主義です。ソースコード以外にも、私達が世界を変えるためにコミットできるコードがあります。
Coinhiveやアラートループが逮捕されるこんな時代だからこそ、私達がすべきコミットがあるのではないでしょうか。

巷ではServer Side SwiftやSwift for TensorFlowが盛り上がっていますが、Swift on WebAssemblyにも大きな動きがありました。しかし、SwiftのWasm対応は、まだまだKotlin NativeやRustに遅れをとっている状態です。LLVMをバックエンドに採用しているSwiftならシュッと対応できそうですが、なぜここまで難航しているのでしょうか？
このトークではSwift on Wasmのランタイムがどのように実現されているか「軽く」お話しします。

要求通りに従順に作るエンジニアとプロジェクトをしていると、
「これってデフォルトの機能じゃないんだ..」「この動き作るのってそんなに辛いの..?」
と後からデザイナーが知る、ということがたまにあるのではないかと思います。
また、UISearchBarを使えばいいところを細かい見た目の要求を守ろうとすることでUITextFieldを使ってみたり、
UILabelじゃなくてあえてUIButtonで実装したりなども経験のあるエンジニアもいるのではないかと思います。
この辺りは認識の差をなくせば解決できる問題であり、
デザイナーにある程度周知することで、裏で変に頑張るエンジニアを減らせるのではと考えています。
このトークでは、
「（おそらく）あるあるな辛いデザイン要求」を順に見て考察しながら、技術面、コミュニケーション面含めどのように解決したのかについて話したいと思います。¥
また、それに伴って開発した、UIレシピブックアプリについても公開しようと思います

UICollectionViewやUITableViewでセルの高さが可変なフィードやチャット画面を作る機会は多いと思います。

そして作ったものを動かしてみると、スクロールが微妙にカクつきがあることに気づきます。

InstagramやFacebookアプリのフィードはなぜあんなになめらかにスクロールできるのか？

5分で実装方法をお話します！