トーク

iOSアプリを審査に提出するときに回答が必要となる「輸出コンプライアンス情報」についての質問。あなたは毎回、正しく理解して最適な答えを選ぶことが出来ている、と胸を張って言えますか？

HTTPSも暗号化に含まれるの？暗号化を使用しているけれど、EAR（米国輸出管理規則）の免除資格を満たしているか曖昧だ、など不安を抱えながら回答している、という方もいらっしゃるのではないでしょうか。

本トークでは5分間でフローチャートを交えながらこの「輸出コンプライアンス情報」にあなたのアプリがどう回答するべきなのかを説明します。このトークさえしっかり聞けば、明日以降のiOSアプリの申請では自信を持って「輸出コンプライアンス情報」に回答することができるようになるでしょう。

WWDC 19で発表されたXcode 11の新機能の中でも喜ばしいものの1つは、XCFrameworksという、フレームワークの新しいバイナリ配布フォーマットです。これまでフレームワークの配布には".framework"という拡張子のフォーマット（バンドル）が使われていました。しかし".framework"のバイナリの配布では、1つのバンドルでシミューレーターとデバイス両方で使用できるようにするためのビルド手順の複雑さ、iOS用とmacOS用、tvOS用など対応プラットフォーム毎にバンドルを分離する必要（この場合は3つ）などの問題がありました。

Xcode 11から使える".xcframework"という新しいフォーマットは、まさにこれらの問題を解決しているのですが、どのように解決しているのか、またどうしてXcode 11のタイミングで導入されたのでしょうか？本LTではXCFrameworksの構造や作成方法、そしてこの形式が導入された理由（の推測）に迫っていきます。

日本ではほぼすべての人が義務教育期間を経て立派な大人になっていくと思います。そして、そんな意識が曖昧な期間の人々は大きな過ちを犯しがちです。そう。例えば「先生」に対して「お母さん」と呼んでしまう問題は鉄板の過ちと言えるでしょう。人間は過ちを犯すものです。脳内では「先生」と「お母さん」は区別はついているはずなのに呼び間違えてしまう事象が発生してしまいます。脳内に常にバグがあります。そんな我々が書くプログラムにおいてもそのようなバグが混在しないと言えるでしょうか？いいえ。発生しないなんて言い切れないです。特にSwiftのような実行前に厳格にチェックが入るシステムなら事故は減らすことができると思います。しかし、私達が普段扱っているのはSwiftで記述できますが、未だに@objcなどの存在がちらほら見えるUIKitやFoundationを支えているであろう Objective-C の存在を感じざるを得ません。Objective-Cでは非常に動的にメソッドを呼び出すことが可能です。これはつまり「先生」を「お母さん」と呼び間違える可能性が出てくるということです。Objective-Cの世界では「先生」に対して「お母さん」と呼び間違えたら自分が羞恥心でクラッシュします。

このトークではObjective-Cにおいて、「先生」を「お母さん」と呼び間違えてしまった場合の復帰策についてお話していきます。

iOS の設定は Configuration Profile という形式のファイルをインストールすると変更できることは、意外と知られていません。
もし、これをアプリを通してインストールできれば、iOS 11 未満でも Wi-Fi を QR コードで繋げるなど様々な可能性が広がります。

この LT では、Configuration Profile によってできること、そしてアプリから Configuration Profile をインストールする方法を解説し、皆さんの iPhone 環境構築体験を豊かにするための知識を披露いたします。

プッシュ通知の配信といえば Firebase を思い浮かべる方が多いと思いますが、
AWS でも Pinpoint というサービスを使うことで、プッシュ通知のセグメント送信をすることができます。
さらに、 AWS Pinpoint では AWS Lambda を使ってセグメントをカスタマイズすることができるため、
ほかの AWS リソースのユーザー情報をもとに通知内容をユーザーごとに変更することまでできます。
また、ユーザーに複数のチャネルを割り当てることができるため、プッシュメールとプッシュ通知を使い分ける、といったことも可能です。

本 LT では、 Pinpoint を用いたプッシュ通知の配信から、こうしたユーザーごとのカスタマイズまでを扱います。
特に普段のアプリのバックエンドで AWS を活用しており、通知配信も AWS 内で行いたい方の参考になれば幸いです。

SOLID原則は、オブジェクト指向プログラミングにおける基本的な5つの原則です。

S - 単一責任の原則 (Single Responsibility Principle)
O - 開放/閉鎖原則 (Open/Closed Principle)
L - リスコフの置換原則 (Liskov Substitution Principle)
I - インタフェース分離の原則 (Interface Segregation Principle)
D - 依存関係逆転の原則 (Dependency Inversion Principle)

コーディングにおいて、言語化できない不吉なにおい（Code Smell）を感じたときには、これらの原則に照らし合わせることで設計の間違いを言語化し、修正の手がかりを掴むことができます。

SOLID原則はもちろん、ソフトウェア設計のための原則です。
しかしオブジェクト指向は「複雑な問題領域を分割統治する」コンセプトであり一般性を見いだせます。原則が転用できるのは、コードの中のみではないはず。
このLTでは、コーディングにまつわらない日常生活のものごとをいくつか例に挙げ、SOLID原則の視点で解釈してみます。
ドキュメンテーションから部屋掃除に至るまで、SOLID原則を適用すると、どのような「におい」をあぶり出し、改善することができるのでしょうか？
そうやってSOLID原則に慣れ親しんでみれば、コーディングでのSOLID原則の熟達にも役立つことでしょう。

30分枠でも同タイトルのプロポーザルを提出していますが、LT枠としては「こんなふうに共通の課題を見いだせる！」というアハ体験の楽しさを重視したいと思います。

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分で実装方法をお話します！

1989年に発売したゲームボーイは、今年30周年を迎えました。
そんな今だからこそ、実機で動くゲームボーイ開発をしてみましょう！

30年の時を経て、ゲームボーイが最新の技術で蘇ります。