iOSで画面を収録してライブ配信を行うにはReplayKit2を利用し、Upload Extension経由で画面を配信する必要があります。
さて、そのUpload ExtensionをXcodeで追加すると BroadcastSetupViewController というUIViewControllerが追加されます。

「これ……なに……？」

なんとか謎のViewControllerの正体を暴いた後、次の壁にぶつかりました。
Upload Extensionの動作時にはiOS側の制限で約50MBのメモリ制限がかかっているため、
気楽に処理を書くとすぐにメモリが枯渇してしまうのです。

「気軽に処理書くとiOSに殺されるんだが……？」

このトークでは、将来スクリーン配信機能をつくる誰かが少しでも楽になることを主目的とし、
スクリーン配信機能の作り方をまとめながら、ハマりどころやデバッグのコツをお話します。

SwiftはUnicodeの扱いに非常に長けた言語であり、絵文字を含む文字列でも正しい文字数を計算してくれます。
その反面、Unicodeの複雑さに引きずられてしまい、直感的な操作ができない時もあります。たとえば、 string[2] と書いても3番目の文字を取得することはできません。

そんな複雑なところのあるSwiftの文字列処理ですが、複雑なものを受け入れてきちんと理解するのはそこまで難しいものではありません。

このトークでは、Unicodeとの関係を意識しながら、Swiftの文字数の扱い方とその裏にある考え方を解説します。

説明

Radiotalkは、音声配信プラットフォームで、誰でもラジオのようにトークを配信することができます。
最近、ワイヤレスイヤホンが普及などもあり、音声が注目されるようになってきました。
しかし、音声は、以下のような再生までのハードルが高い課題がありました。
・環境によっては今すぐ再生できない(音を出せる環境、ヘッドホンしているかなど)
・再生するトークを選ぶ際に、タイトルや詳細、画像などでしか判断できない(トークのテンションや声などは判断できない)

その課題を解決するために、音声の一部を書き起こして、テロップ動画でシェアできる機能を作成しました。
音声から動画を作成するまでの話と作り方をお話したいと思います。

発表内容

・開発の流れ
　・なぜ音声を動画にすることになったのか
　・動画のテンプレートを作るまでの流れ
　・実装の一連の流れ
・音声トリミング方法
・音声の解析方法
　・GoogleSpeechToTextなぜ採用したか
　・GoogleSpeechToTextの仕様
　・GoogleSpeechToText精度
・テロップ動画作成エディタのUI/UX
・静止画動画作成方法
・音声と動画の合成方法

Segueでできること、できないこと、とにかくSegue（UIStoryboardSegue）について凝縮して紹介します。
通常の使い方からUnwindSegueを使うメリット、Xcode 11から利用できるようになったIBSegueActionまで。
Segueを愛して7年の私が、これまでSegueを避けてきた皆さんにもSegueの魅力を知っていただけるようなトークができればと考えています。

~黒魔術がObjecitve-C Runtime APIだけだといつから錯覚していた？~

iOSで黒魔術といえばObjecitve-C Runtime APIが注目されがちですが、
当然それ以外にも色々な黒魔術が存在します。

ダックタイピングはオブジェクトの型を見るのではなく、オブジェクトそのものがメソッドを持つかどうかという考え方に基づいた手法です。
RubyやPythonではポリモーフィズムを実現する手段として使われている一方、iOS(特にSwift)ではあまり馴染みのない考え方だと思います。

しかし、実はObjective-Cでこのダックタイピングの考え方に基づいた設計/実装が行われています。

本セッションでは、そのダックタイピングの考え方が使われている例に触れつつ、
Obj-Cの特徴であるid型と組み合わせてUserDefaultsをテスト用のオブジェクトに差し替えた話をします。
(UserDefaultsをprotocolでラップする話ではありません)

ランチセッションで講演された内容です。

Swiftは多くのプログラミング言語の良い所を採用しており
多種多様な方法でコードを書くことが可能であるため
同じ問題に対しても人によってコードの書き方は大きく異なります。

そうした状況の中で

「これは正しい書き方なのだろうか？」
「もっと上手い書き方があるのではないだろうか？」
「いったい何が良いコードなのか？」

と悩むことは多いのではないでしょうか。

私は毎日悩み続けています。

そんな中
これが正解というものはありませんが
数あるコードの中でも
多くの方から良いコードと呼ばれている
いわゆる「クリーンコード」は存在します。

今回は
私が日々苦悩する中で出会ってきたコードを題材に

どのような状況で、どのような書き方がされ、なぜそう書かれたのか

を見ていき

「クリーンコード」とはどういうものなのか？
なぜ「クリーンコード」は必要なのか？
「クリーンコード」を書くためにはどうすればよいのか？

などについて
みなさまと一緒に
コードの世界を探検する中で発見していきたいと思います。

今回の発表を通して

「こういうときはこういう理由でこうすれば良い」

といった「確かな選択」ができる回数が増え
日々の苦悩を乗り越えるための一助になりましたら幸いです。

テストコードを書いている場合、コードカバレッジを計測しているチームが多いのではないでしょうか。
私たちはXcodeの機能を使えば簡単にコードカバレッジを計測することが可能です。

一方でコードカバレッジにはいくつか種類があり、Xcodeではその一つであるステートメントカバレッジしか計測できないということをご存知でしょうか。
カバレッジの種類によりどこまで厳密網羅されているかが変わってきます。
その中でも分岐の網羅までチェックするものがブランチカバレッジと呼ばれます。

お隣を見渡せばAndroidのJaCoCoではブランチカバレッジも計測することができます。

ではなぜ私たちの扱うXcodeではブランチカバレッジを計測することができないのでしょうか？
そもそもSwiftでブランチカバレッジを計測することができないのでしょうか？

本トークではそんなXcodeでのコードカバレッジ計測でブランチカバレッジを計測できない理由はなぜなのか、本当に計測することができないのか。
それをSwiftのカバレッジ計測の仕組みから解き明かしていきます。

みなさん、iOSアプリのテスト書いていますか？どのように実行していますか？
ひと昔前と違い、今やiOSデバイスは多種多様となり、アプリを安心してユーザに届けるには出来るだけ多くのデバイスで確認する必要が出てきました。新しいデバイスが発売されるたびに買い足さねばなりませんし、チーム内で融通したり管理するのはそれだけで大変です。

AWS Device Farmを使うと、自分たちが持っていないバージョンのiOSデバイスでバグが報告された場合もリモートアクセス機能を使ってすぐに動作確認をすることができます。また、CI/CDパイプラインに組み込んで自動テストを実行することも簡単に行なえます。

このセッションではまずDevice Farmを利用するためのステップをひとつずつ分かりやすく紹介します。そして次に、iOSにおける自動テストやUIテストについて説明し、XCTestやXCUITestを実際に実行してテストのイテレーションを回す実例を解説します。

UIImage、CGImage、そしてCIImageは、いずれも画像情報を保持するためのクラス(以下、画像クラス)ですが、皆さんはこの3つのクラスの特徴を理解して使っていますか？

Web APIで取得した画像を縮小して表示できればよい、といった単純な要件であれば、何も考えずにUIImageを使うだけでも済みますが、リアルタイム処理や複雑な画像処理などのより高度な要件においては、特徴を知らずに使ってしまうと余計な処理を書いてしまって最悪性能低下を招くことになってしまいます。

本セッションでは、UIImage / CGImage / CIImageの各画像クラスの特徴を解説しながら、これら3つのクラスの画像処理における使いどころについてご紹介します。

また、OpenCVなどの画像処理ライブラリとの連携を考慮した画像クラスの使い方や、私が業務で実際に画像処理の性能改善に成功したエピソードもご紹介します。

本セッションが普段何気なく使っている画像クラスについて改めて考えるきっかけとなれば幸いです。

• 発表内容アジェンダ
  1. UIImageとCGImageとCIImageの概要や特徴
  2. 特徴を踏まえた各画像クラスの使いどころ
  3. OpenCVなどの画像処理ライブラリとの連携を踏まえた画像クラスの使い分け
  4. 業務で実装したリアルタイム画像処理の処理性能を改善した体験談

みなさん、iOSやAndroidなど、端末同士のデータ交換にはどのような方法を使っていますか？
ログインや登録を必要としない、パケット代もかからない、モバイルデバイスで広く採用されている、OSを問わない、
そんな理由でBluetoothを採用しようとした人は結構いらっしゃるのではないでしょうか。

しかし、いざ採用したとしても、一度に少量しかデータを送れない、機種によって安定しない、データを正しく受け取れない…
そんな経験から、BLEの採用を見送った方も多いのではないのでしょうか。

そんなBLEですが、
iOS、Androidの各OSで内部的に行われている処理を読み解くと、
データを送るための処理を最適化するための道筋が見えてきます。

このトークでは、BLEの処理に対して各OSで何が行われているのか？何ができるのか？
その上で最適なデータ通信を行うためには何をすればいいのか？を語りたいと思います。

また、iOS11より、通常のBLE通信とはまた違った選択肢「L2CAP」でのデータ通信が行えるようになりました。
こちらの方式はほぼ公式ドキュメントが存在しない状況ですが、Android Qにも採用される予定の技術であり、
そちらも合わせて語りたいと思います。

みなさん LOGO というプログラミング言語はご存知でしょうか？私は中学生の時にこの言語のタートル・グラフィックスという機能でプログラミングの楽しさを知り、現在 iOS のエンジニアをしています。

2016年7月、その LOGO とタートル・グラフィックスの生みの親であるシーモア・パパート氏の訃報をきっかけに、Swift 製タートル・グラフィックスの開発を始めました。同年の WWDC で発表された Swift Playgrounds で動かすことができれば、子どもたち（私の息子も含め）に iPad で私の中学生時代と同じ体験をしてもらえるかもしれないと思ったからです。

このトークでは、私が作っている Swift Playgrounds で動くタートル・グラフィックスについて、次のような構成でお話しする予定です。

• LOGOとタートル・グラフィックスについて、そして後世に与えた影響
• Swift, CoreGraphics, CoreAnimation によるタートルグラフィックスの実装
• Playground Book の作り方と、Subscriptions による配布方法
• Swift Playgrounds 動くタートル・グラフィックスを配布して起きたこと

安全にリファクタリングを行うには「お約束」があります。

「自動テストを書いてからリファクタリングする」

言葉にしてしまえば簡単で「プログラマであれば当然のことだ」とおっしゃる方もいらっしゃるかもしれません。
でもそれを難しくするのがヤツの存在です。そう、iOSエンジニアならば切っても切れない関係のFatViewControllerです。

前述のお約束を守るために、こんな堂々巡りに陥ったことのある方は少なくないのではないでしょうか。
・「UIテストを書いた上で書き換えを行うか？」「時間がかかりすぎる、ダメだ...！」
・「ユニットテストを充実させて設計を変更しながら書き換えを行うか？」「先にプロダクトコードの変更が発生してしまう、ダメだ...！」

このトークではFatViewControllerの書き換えを「自動テストを書いてから」というお約束を守ってこなすのが難しかった話をします。
そのうえでなるべく安全に、現実的に書き換えていく方法にはどんなものがあったか、どんな部分で安全を切り捨てて痛みに耐える判断をしたのか話をします。

iOSアプリ開発は年々複雑化しています。次々と追加される新デバイスや新しいAPIへの対応など技術的な要因はいくつかありますが、それ以外にも更新され続けているApp Store Reviewガイドラインやその他のApp Storeに提出できるアプリの要件を遵守する必要があるのもその要因の1つです。

ガイドラインや提出できるアプリの要件は日々修正、追加されているため常に最新情報を把握することは難しいです。ですがこれを怠ってしまうと、いざリリースという段階になってリジェクトされてしまい、思わぬ対応コストとスケジュールの変更を余儀なくされる可能性があります。

この問題を解決するため、ビルドされたアプリに対してガイドラインやApp Storeに提出できるアプリの要件を遵守できているか機械的にチェックするツールを作成しました。このツールはFastlaneプラグインとして提供され、Fastlaneによるビルドパイプラインに簡単に組み込むことが可能です。ツールによるチェック結果はコンソールログ以外にHTMLレポートとして出力が可能で、検証を担当されているQAチームと連携してリリース前の段階でアプリに問題が無いことを確認しています。

本発表では以下の内容をお話しします

• このツールを開発した経緯
• 実際にどのような項目をチェックしているのか
• チェック機能の実装方法
• QAチームとの連携
• ガイドラインを追い続けるための情報源

iOS開発においてApp Store ReviewガイドラインとApp Storeに提出できるアプリの要件を満たすために気をつけるべき注意点と、今回紹介するチェックツールと同様のものを自作するために必要な知識を持ち帰ってもらいたいと思います。

モバイル開発をしている上でデザインとの関係性は切手は切れない関係だとお思います。
また、プロダクト自体も成長に伴い複雑性がましてきました。そのときに私はデザインシステム
に注目して様々なアプローチしてきました。

本発表ではあまり馴染みではない「デザインシステム」はどういうものなのかという基本的な話から
ではどのようにしてプロダクトにデザインシステムを導入し、どこまで何をしていったのか
エンジニアリングを持って何を解決していったのかを解説します。

概要

• デザインシステムの基礎
• 導入にあたって
• エンジニア側からできること
  • カラー管理・自動化
  • 画像管理
  • インタラクション

動画を現実の風景に重ね、その一部を透過させて再生する実装について説明します。

AR(Augmented Reality)空間でシンプルに動画再生するのはそれほど難しくありません。
しかし一部透過させようとするとリアルタイム画像加工をする必要があり難易度が高まります。

表示のガタつきを抑え、一部を透過させた動画を再生するには。
60fpsかつ音声付きで再生するにはどうしたら良いのでしょうか。

クロマキーシェーダーと再生処理の工夫により実現した実装とその他Tipsを共有します。

この発表では以下の内容について話す予定です:

• クロマキー合成シェーダーの実装
• 60fps音声付きでの透過動画のスムーズな表示
• リアルタイム配信映像の受信について

本トークでは、Auto-Renewable Subscriptionsと呼ばれる、定期的に新しいコンテンツが配信される種類のApp内課金について、実際に実装する上でハマったことや実装前に知りたかったようなノウハウを織り交ぜて説明します。
また、今年のWWDCのセッション『In-App Purchases and Using Server-to-Server Notifications』では、サーバー間通知の仕様のアップデートがアナウンスされ、レシートの取り回しの方針が今秋から大きく変わることが判明しました。本トークではそちらについてもご紹介いたします。

【アジェンダ】

1. In-App Purchasesについて
2. Auto-Renewable Subscriptions導入の経緯
3. Auto-Renewable Subscriptionsの大まかな処理の流れ
4. StoreKit frameworkの各メソッド定義と実装方法
5. Sandboxテスターによる動作確認方法
6. サーバーサイドの設計
   ・状態更新通知
   ・Sandboxレシートのハンドリング
   ・Grace Periodの実装
   ・WWDC19で発表されたサーバー間通知の新しい仕様について
7. リジェクトについて気をつけたいポイント

近年、ユーザーがクリエイターに直接お金を払ういわゆる投げ銭機能を提供しているサービスが増えてきました。
自分が開発している動画アプリでも投げ銭機能を実装することになり、それに伴い投げ銭するためのアプリ内通貨の購入機能が必要でした。
しかし、まだまだ事例は少なく参考になる情報などが少ない状況です。

プレミアム機能を使うための月額課金プランをすでにネイティブ実装していたので、レシート検証の共通化などを行うためアプリ内通貨の購入機能もネイティブ実装することになりました。
一部の処理は共通化できますが、月額課金プランはAuto-Renewable Subscriptions、アプリ内通貨の購入機能はConsumableと呼ばれる課金方式で実装するため、リトライ処理など課金トランザクションの扱いの差異などを意識して実装する必要があります。
しかしよくネイティブ実装される課金方式は、自動更新型のAuto-Renewable Subscriptionsや非消耗型のNon-Consumableです。
Auto-Renewable Subscriptionsは特定のコンテンツにアクセスできる手段として、Non-Consumableはアプリ内の特定の機能にアクセスする手段としてよく使われます。
消耗型のConsumableはゲームアプリ内の通貨などでよく用いられますが、Unityやcocos-2dxなどのフレームワークで開発されることが多く、ネイティブで実装されることは少ないです。
事実、課金のネイティブ実装を検索しても、多くヒットするのはAuto-Renewable SubscriptionsやNon-Consumableです。

このセッションでは、公式ドキュメントを参考にしながらConsumableのネイティブ実装をした話を他の課金方式と比較しながら紹介します。

我々の開発において「アプリケーションのパフォーマンス」というものは非常に重要であるにも関わらず、優先順位は常に最下位に位置づけられがちです。顧客の体験を最も確実に向上させる手段の一つが、パフォーマンスの改善なのですが、我々は常に新規機能を開発しています。
メモリリークやAutolayoutのエラーというものは一度発生すると永劫そこに留まり、アプリケーションのパフォーマンスを蝕んでいきます。
どのようにこれらを防ぐのでしょうか。コードレビューで発見できるでしょうか。或いは発生したそれを修正するための時間を確保出来るでしょうか。
これらの問題は、コンパイラでは発見出来ません。コンパイラで発見できないものを防ぐ最も賢い手段の一つは、テストケースを書くことです。コードレビューではありません。それでは世界は救えません。

メモリリークに関しては"try! swift 2019"で伝説の失敗に終わった私のデモとともに追放されました。(されたはずです)
今回は最高峰の黒魔術を以て、我々の世界からAmbiguous Layoutを駆逐します。ご期待下さい。

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