皆さんiOSのサブスクリプションプランの無料トライアルを実施したいと言われたことはありませんか？
Appleは「お試しオファー」という仕組みを提供しており、一見簡単に実装できそうに思いますが、そこにはいくつもの落とし穴があります。

本トークでは僕自身が実際に無料トライアル施策を実施し、盛大にしくじった経験から叶えることのできる / できない要件、サブスクリプションプラン構成のベストプラクティスをお話しできればと思います。

• Appleの提供する無料トライアルの仕組み知ってますか？
• プランの購入導線全て知ってますか？
• Appleの「お試しオファー」で叶えることのできる / できない要件
• 今回の施策でのしくじりポイント
• しくじりから学ぶべきポイントとベストプラクティス

Swift 5.0がリリースされてから1年が経ちました。
去年のWWDCでSwift UI, Combineと共にSwift 5.1がリリースされ、今では5.3までリリースされています。（2020/06/22）

・Result
・Ordered Collection Diffing
・Opaque return types
・Property Wrapper
・.....
数多くの便利な機能が追加されていますが、Swift 4.2以降の機能を使っている方は少ないのではないでしょうか？
私もSwift UI, Combineで使用している以外では十分に使いこなせていないと感じています。

そこで今回のセッションでは、Swift 4.2以降にリリースされた機能を一から見直し、
日常使い出来るよう、ユースケース毎に紹介していきたいと思います。

[Target]
・Swift 5.xの機能を使いこなしている自身が無い方
・Swift 5.xでリリースされた機能を振り返りたい方

[Goal]
・Swift 5.xの機能を一つでも日々の業務に持ち帰れる状態

2019年、SwiftUIという新しいUI記述方法が導入されました。
SwiftUIでは宣言型シンタックスを導入し、Appleの各プラットフォームに対し、シンプルなUIコードの記述ができるようになりました。
しかしながら、SwiftUIにない機能を使いたい、あるいはサポートするOSの関係でSwiftUIの導入ができないなど、他の手段でUIを構築することはまだあるかと思います。

そのUIの構築方法の一つであるStoryboardは、GUIベースでのUIデザインツールとしてのイメージを持たれている方が多いと思いますが、UIデザインツールとしての側面だけでなく、様々な機能が盛り込まれています。

• リストア機能を使って、バックグラウンド状態からKillされても元の状態に戻し、ユーザー体験を損なわない
• FirstResponderを使って、手軽にUndo、Redoなどを実装する
• 言語だけではない、ロケールごとの画面遷移方法の設定
• コードとデザインを分離し、iPhone、iPadなどの様々な画面サイズや、tvOSなどのプラットフォームでコードを共通化する
• OSバージョン別にUIをデザインする
• Objectを使って、ViewControllerにコードをFatに書かない、あるいはViewControllerを全く用意しないアプリを作る

など、UIの作成にとどまらない、あなたのコードライティング時間をより多くビジネスロジックに回せるようなStoryboardの活用法をお伝えします。

iOSアプリ開発の大部分の時間はViewの実装に費やされます。Viewはアプリの状態によって表示内容やレイアウトが動的に変わります。そのためViewの開発中は、頻繁にiOS Simualtorを起動し、実際にアプリを操作して期待通りの表示内容になっているかを確認する必要があります。また、小さい画面の端末での表示時、ダークモード有効時、Dynamic Typeで文字を大きくした際などに、レイアウトが崩れてないかを確認する作業も面倒なものです。何か変更するたびにiOS Simulatorを起動して動作確認する必要があるので非常に大変です。

この問題を解決してくれるのが、Xcode11で導入されたXcode Previewです。Xcode Previewは、様々な状況下におけるViewの表示結果をエディタ上でプレビュー表示する機能です。

Viewの実装を変更すると即座にプレビューに反映されるため、確認のためにiOS simulatorを何度も起動する必要はありません。 そして、Xcode PreviewといえばSwiftUIのための開発支援機能というイメージがありますが、実は従来のUIKitベースのアプリ開発にも使うことができます！あなたの既存のアプリ開発を効率化するための道具として、今日からXcode Previewを使い始めることができるのです。SwiftUIの普及を待つ必要はありません。

このトークでは既存のUIKitベースのアプリ開発にXcode Previewを導入する方法とその活用方法を、デモを交えながら紹介します。

iOS 開発者はコードを書くこと以外にも様々な業務を抱えています。
みなさんはこんな依頼を受けていませんか？

「Firebase App Distribution からインストールしたいのですが UDID を登録してくださいと言われます。どうしたらいいですか？」
「今開発中の Branch の最新版って触れますか？配信お願いします。」
「現在の審査状況どうなってましたっけ？」
「リリース用の Branch の merge 忘れてませんか？」
「dSYM アップロードしてませんよ。」

メールや GitHub を見に行ったり、手元でビルドし直して fastlane を実行したり…といろんなツールを切り替えるだけでも時間は過ぎてしまいます。
これらの作業、自動化してみませんか？
同僚のように頼もしい Bot を育ててみませんか？

本トークでは私が1人チームのころから iOS 開発に関わる業務のアレコレをコツコツ自動化してきたこと、それをベースに実際に会社で運用しているワークフローを余すことなくご紹介します。

共通したコードベースを基に、複数アプリをビルドしたいことがあります。
例えばCtoCのECサービスにおいて、同プロダクトの販売者向けアプリと購入者向けアプリを実現したいときなど。
このように、機能の出し分けはあるけれど、共通部分が多いのでソースコードを分けるほどではない、といった場面が起こり得ます。

こんな時に用いる手法として、Configurationを複数作成しそれぞれにおいてマクロを定義し、
機能出し分けを行いたい箇所で「#if」という記法を使って実装コードを出し分けていく、といったものがあります。
こういった開発においてよく発生してしまうのが、コードの至るところに「#if」が発生してしまい、可読性が落ちてしまうということです。
また本来であれば購入者のみが使用できる機能であっても、誤って販売者向けアプリにおいて表示してしまう、という不具合が起こる可能性も十分あります。

そういった課題を「型定義」の力を借りることで解決することができます。
本トークではこちらについてご紹介したいと思います。

皆さんお馴染みUIColorは色データを記憶しているクラスですね。
色の名前やコンポーネント値を決定してUIViewに与えるだけの超単純なヤツ……

ではありません！UIColorがサブクラスを大量に持っているって知っていましたか？その数なんと18個（私調べ）！稀に見る大家族です。しかし我々がサブクラスを意識することはありません。UIColorのサブクラスは全てprivateで、表に出てくることはありません。

それにしても、18個もprivateなサブクラスを持つなんて、UIColorはどんな仕組みになっているのでしょうか？そもそもpublicなイニシャライザは10個だけ、メソッドも8個しかないのに何がどうなってるの？？

本セッションでは、UIColorの構成を考察したり、ドキュメントにない細かい仕様を確認したりして、UIColorともっと仲良くなります。

【対象】

• UIColorをご愛用の皆様
• UIColorは色空間とコンポーネント値を保持してるだけの単純なヤツと思っている皆様
• dynamic colorを酷使する予定の皆様

【トーク内容】

• UIColorの全体像ってどうなってるの？UIColorのヘッダを覗き見しちゃおう！
• そんなにサブクラスがあって何かメリットがあるの？
• サブクラスはそれぞれ何をしてるんだろう？
• dynamic colorの仕組みってどのように実現しているのだろう？サブクラスを自作して内部実装と仕様を考察してみよう！
• ↑dynamicなサブクラスの自作が実質不可能になっているという話も。

注：本プロポーザル中の数字はiOS13.5時点のものです。iOS14でイニシャライザが1つ増えそうだということは、つまり？

「ネイティブアプリで作ってよ」「それ、Webでよくない?」

ネイティブアプリ開発に触れることが多いエンジニアにとって「アプリを作ろう」という提案にはつい浮き足立ってしまうものですが、
一エンジニアとしては、Webとの比較を含めて適切な技術選定ができるようになっておきたいものです。

最近ではJavaScriptやブラウザの進化により、
Webページをアプリのように動作させることができたり、Apple PayなどのOS機能の一部をブラウザから動作させたり、
またiOS14ではアプリの一部をApp ClipsとしてWebから起動できるようになったりと、両者の関係はより複雑になってきました。

このトークでは非ゲームアプリを対象に、
従来ネイティブアプリでしか実現できなかった体験について現在のWebでの対応状況を整理するとともに、
App Clipsを含めたネイティブアプリとWebのそれぞれの使いどころや、組み合わせることで新たに生まれるユーザー体験について考えます。

予定しているトーク内容

• PWAの現在とiOS Safariにおける対応状況
• Safariで提供されているネイティブ機能
• App ClipsとWeb
• Webとネイティブアプリの使い分けや組み合わせ方を考える

アプリ開発における組織力学の話をします。

iOSアプリを構築する過程で、バックエンドAPIとの連携、デザインとの連携など様々なレイヤーとの相互作用が発生します。
そこには必ず人やチームが存在するため、必然的に「組織構造をどうするか」「どういう開発の流れを作っていくか」という組織構造の設計や、その中を流れる開発プロセスを同時に思考していく必要があります
アジャイル型の開発だとしても、各レイヤーの構築スピードが異なるため、結合のタイミングやMVPリリースのタイミングを計ったり、各レイヤー同士がどこまでレビューに介入するべきかなどを設計しないと、生産性のバランス崩れや意思決定の遅延、開発リードタイムにも大幅な影響を与えてしまいます。

ここを解決するためには、個々が対応するのではなく大規模な組織開発になればなるほど、根本的な組織構造から生まれる力学（バリューストリーム）を丁寧に作り上げる必要があります。
今回は、iOSアプリを開発する中で見えてきた、生産性のバランス可視化や意思決定プロセスの構築、開発体制の整備などあらゆる課題を解決するために行った取り組みについて事例を交えながらお話できればと思います。

皆さんはSwiftで書かれたソースコードを解析したことがありますか？

SwiftではSwfitLintが静的解析ツールとして有名です。
SwiftLintを導入しているプロジェクトも多いと思います。
しかし、決してSwiftLintだけが静的解析ツールではありません。

Java向けのIDEであるIntelliJはこの静的解析の技術をフルに活用しています。
IntelliJで開発をしたことがある人は、この技術がいかに我々の開発を効率化させるか実感したことだと思います。
様々な静的解析を用いたツールが提案されていますが、その恩恵の多くはJavaなど他の言語を対象にしているものが多く、Swiftを対象にした静的解析ツールはまだまだ少ないです。

この発表ではSwiftのソースコードを解析するSwiftSyntaxを用いて、実際に静的解析ツールを実装し、解説していきます。
静的解析の技術を身に付け、より発展的な静的解析に挑戦してみませんか？

SwiftUI、ワクワクしますね。

ところで残念ながらら、まだまだ UIKit で戦わなくてはいけないエンジニアもたくさんいるのだ。

そしてその中に、ビューの変形に CGAffineTransform を使わなくてはいけないエンジニアもまだまだたくさんいるはず。

CGAffineTransform は微妙に分かりにくいものだ。確かに scale や rotate などの比較的に分かりやすいイニシャライザがたくさん用意されているが、それが実際どう動いてるのかがわからない。組み合わせてみたら思ってるのと挙動違うし、プロパティーを確認してみてもよくわからない a b c d tx ty しか出てこないし。設定した scale や rotate は一体どこに消えてるの？

このトークは、そんなあなたのお悩みを解決する。大丈夫難しい話ではない。必要なのは四則演算の知識だけだ。

1年前ほど前に観たUberのエンジニアによる"Code Generation"（以後「自動生成」と記す）に関するセッションに影響を受け、みてねのiOS開発でも自動生成（Sourcery + Stencil）を取り入れました。
まずユニットテストを効率良く書けるようにするための「テストデータ」の自動生成というものを行いました。
これが思ったよりもチーム内で受け入れられて、今ではなくてはならないものになりました。
その後、チームの他のメンバーが「DI」まわりで自動生成を用いた素晴らしいアウトプットを出してくれました。
他にもまだまだ自動生成したいものがたくさんあります。

このようにみてねのiOS開発ではチームとして自動生成を絶賛活用中なので、その知見を以下のような項目で話せればと思っています。

• 実際の活用例（テスト、DI）

• 実装方法

• 1年ほど運用してみて（ハマったことや、チーム内における知見の共有など）

• 自動生成のpros/cons（例えば外部ライブラリを利用するという選択肢との比較）

• みてね = 子供の写真や動画を家族内で共有するアプリ

人工知能技術の発展、および端末の性能向上の発展により、物体の判別や自然言語処理などiOSの様々な可能性が広がってきました。これらの技術の延長線として、我々が備えているものと同等の知能をいつかiOSアプリは宿すのでしょうか？
ヒトなどの動物が備える天然の知能にあって、現状のAIに欠けているものを2つ挙げるとすると「自律性」と「汎用性」が考えられます。
自律性についてですが、現状のAIは特定の問題をヒトが設定し解決するためのツールとしての使い方が主流です。それに対して、我々動物が持つ知能は環境から独立し、相互作用する自律性を備えています。
汎用性に関してですが、限られた状況においてのみ高い能力を発揮するのが、現状のAIです。砂漠から北極圏、都市での生活まで広く適応可能なヒトの知能には、まだまだ遠く及びません。例えばクジラの消化管にのみ適応した寄生虫のように環境を限定することで生き残った動物もいますが、高度に進化した動物の知能は、様々な環境に適応できる汎用性を備えています。
iOSアプリがこのような自律性と汎用性を兼ね備えるためには、何が必要なのでしょうか。1つ考えられるのは、「内部世界」です。我々の脳は常に情報が循環し複雑に流れる内部世界を持っています。iOSDC2019ではこのような複雑な流れを簡単にシミュレートするプログラムを公開しました。もう1つ考えられるのは、「感情」です。動物は、美味しい、美しい、心地よいなどのポジティブな感情を多く得られるように、痛い、醜い、苦しいなどのネガティブな感情を避けるように行動します。AIが自律性を備えるためには行動の指針が必要なのですが、この感情のような仕組みを模倣できればそのような指針になるでしょう。今回の発表では前回の「内部世界」のシミュレーションを踏まえ、アプリへ感情のようなもの？を導入しようとする試みについて話します。

WWDC2019でSwiftUIが発表されました。WWDC2020でもSwiftUIに関するセッションがいくつもあり、AppleがSwiftUIに注力していることが伺えます。SwiftUIはiOS 13以降で利用できるということもあり、既存アプリの運用保守では現段階ではまだ導入できないでしょう。
ですが、iOS 14から導入されるWidgetがSwiftUIのみで開発できるということもあり、今後、SwiftUIに触れる方も多いと思います。

そんな中、私が担当したアプリは新規アプリということもあり、SwiftUIとCombineを採用しました。実際にSwiftUIでアプリを開発してみると、機能が不足しており、SwiftUIだけでアプリを完結させるのは難しいといいうことがわかりました。
そのため、弊アプリではSwiftUI×UIKitという選択をして、SwiftUIはUIコンポーネントの実装に利用し、画面遷移はUIKitを利用するという設計にしました。

本トークでは弊アプリで選択した設計の説明と、この設計で解決した問題について説明します。

あなたは新しい新機能を開発しているとします。

プロダクトマネージャーから「新機能を含んだアプリがインストール済みだったら、アプリを起動して、未インストールだったら、ストアのインストールページ、または、 特定の Web サイトを開いてほしい」と言われたら、どうしますか？

iOS SDK に含まれる Universal Links や URL Scheme を利用して、アプリバージョンで分岐すれば良さそうと、まず、思いつきますよね。

でも、 Universal Links には同一ドメイン上の URL 遷移では起動しないという制限があったり、 URL Scheme はセキュリティ上の懸念があります。
この 2 点の問題を解決しつつ、当初の要件を満たすことが出来るのが Firebase Dynamic Links です。

本トークでは既存アプリへの Firebase Dynamic Links の導入経験から以下を話す予定です。

• Firebase Dynamic Links で実現できること
• Firebase Dynamic Links の導入方法
• 事例紹介
  　- QR コードから「新機能を含んだアプリがインストール済みだったら、アプリを起動して、未インストールだったら、ストアのインストールページへ画面遷移」させる
  　- Web サイトのリンクから「新機能を含んだアプリがインストール済みだったら、アプリを起動して、未インストールだったら、特定の Web サイトを開く」

SwiftのWebAssembly対応を進めることを目的にした、SwiftWasmというプロジェクトがあります。このプロジェクトはこの1年で大きく前進し、現在では簡単なWebアプリケーションがSwiftで開発できるようになりました。

このトークでは私がSwiftWasmプロジェクトに参加してから実際に行なってきた、Swiftへのコントリビューションとその過程についてお話します。

mediapipeはgoogleが開発しているMLパイプラインを構築するオープンソースのフレームワークです。
https://github.com/google/mediapipe

mediapipeを使うことで、簡単に映像から文字やモノの位置を推定することができます。
一見するとARKitやVisionを使えば良いように思えますが、mediapipeを使うことでそれらのフレームワークが利用できないデバイスでも利用出来るという利点があります。

また、ARKitでは出来ない高度な機能も実装することができるため、既にあるARKitアプリの表現力を広げることも出来るはずです。
このトークではそんなmediapipeを使ったARアプリの開発を通して、その導入の仕方や使い道を紹介します。

発表内容

近年音声サービスが続々と登場しています。
iOS開発でも音声の収録や再生周りの情報は見受けられますが
音声ファイルを編集したり、音声の波形の取得やUI表示になると情報が少ないように感じます。
そこでRadiotalkという音声配信サービス内にある音声編集の部分で用いている部分から
以下の方法を紹介したいと思います。
１．音声の波形の取得方法
■ 収録時に取得する方法

• AVAudioRecorder編
• AVAudioEngine編
  ■ 音声ファイルから取得する方法
• AVAudioEngine編
• AVAssetReader編
  ２．音声編集の方法
• トリミング方法
• 結合方法
  ３．音声波形の表示方法
• 簡単な波形UIの作り方
• 音声編集のUIの構成

iOSのメイン開発言語として盤石になってきたSwift.
そのSwiftを支える最も重要なコンポーネントがコンパイラ開発基盤LLVMです．
また，LLVMは，Swiftだけでなく，多くのソフトウェアにとって欠かすことができないソフトウェアとなってきました．
このトークでは，計算グラフをC++上で実装し，LLVMによるJITコンパイルで，動的にバイナリを生成し，内部的にそれを実行するソースをベースにLLVMの中身を解説します．
ほとんど解説書がなく，とっつきにくいLLVMではありますが，実際にコードを書いていくと，その技術のおもしろさが随所に感じられてきます．
LLVMを学び始めて，半年の初心者ならではの視点で，LLVMのおもしろさをお伝えできればと考えています．

みなさんも，LLVMにレッツトライ！

私たちエンジニアはバグのない世界を切望し、自身のスキルに磨きをかけながら悪戦苦闘の毎日を送っています。

こと開発においてはユーザー体験の向上やサービスのグロースに目を向け、新機能の開発や既存機能の改善に多くの時間を費やしています。

一方でテストにはどれくらいの時間を費やしているでしょうか？
テストコードの実装は本当に品質の担保につながるのでしょうか？
時間を割いてまで書く目的とはなんでしょうか？

このセッションでは、私が開発に携わっているプロダクトにおいて約1年間でテストコードカバレッジがほぼ0%の状態から60.3%まで増えたことで実際にバグの減少につながったのかを中心に日々の開発でテストが実装されることで変わったこと・変わらなかったことをお話しいたします。

品質の向上や組織としての開発の効率化につながるための考え方や手法についてお伝えできればと思います。

• テストコードを書くことでバグは減るのか
• テストコードの価値と有用性
• テストコードを実装するメリット・デメリット
• テストカバレッジが上昇したことで変わったこと
• 組織・開発体制に適したテストの選択方法