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

「これ……なに……？」

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

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

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

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

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

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

皆さん、Xamarin の名前くらいは聞いた事がありますよね！

『ああ、C#で、iOSアプリが開発できるやつね。』

6年前、Objective-Cから逃げたくて手を出した、Xamarin.iOSは私に幸福をもたらすはずだった...

だがしかしそこに待ち受けていたのは底なし沼だった！

気づけばどんどん深掘りされる技術！
その底にたどり着いた時に膨大な、これ必要か⁉︎的な知識を得ている事に気づきました！

今明かされるXamarin.iOSの全貌！

●普通に書くと即メモリーリーク！
●幻の大地か！ネイティブとマネージド、2つの世界を行き来してメモリーリークのチェック！
●情報がないのでSwiftのコードを読む日々
●Swiftじゃダメだ！Objective-Cを理解せねば！
●あれ？俺何のためにXamarin.iOS始めたんだっけ？
●それでも俺はXamarin.iOSをやめない！

説明

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でラップする話ではありません)

現代のアプリ開発では、ライブラリやフレームワークをまったく使わないということはほとんどありません。
OSが提供するUIKitやSwift標準ライブラリを使用しますし、サードバーティの便利なライブラリを使用することもあります。

そして、誰もが１度はリンクエラーや重複したシンボル、パッケージマネージャが出力するエラーメッセージに悩んだことがあることでしょう。
リンクエラーの解決が難しいのは、問題の原因がプロジェクト設定、ライブラリの種類・配布方法、実行先（デバイスやシミュレータ）の環境など多岐にわたるためです。

導入したライブラリがインポートできない、リンクエラーで難しいエラーメッセージが表示されている、ビルドは成功しても起動時にクラッシュしてしまう。
誰もが一度はこのような問題に直面し、解決のために長い時間の試行錯誤をしたことがあるでしょう。

モジュールのインポート・リンクがどのように解決されるのか、リンクとはいったい何をしているのかを学ぶことで、システマチックに問題を切り分け、解決できるようになります。

この講演ではライブラリとフレームワーク、スタティックとダイナミックの違い、それぞれのメリットとデメリット、Swiftからインポートするために必要なこと
を知り、外部のライブラリがどのようにして自分のアプリから利用できるようになるかという仕組みを解説します。

リンクの仕組みを知ることで悩ましいリンクエラーを論理に解決できるようになるとともに、CocoaPods、Carthage、Swift Package Managerといったライブラリ管理ツールもより高度に使いこなせるようになります。

カラーコードとUIColor (or SwiftUI Color) さえわかれば色の話は十分だと思っていませんか？残念ながら違います！私たちが色に関するガイドラインを覗いたとき、謎の数式と用語も私たちを覗き返してくるのです。そこから逃げ出して曖昧な理解のままアプリを作ったら、きっと使いにくいものになってしまうでしょう。

本セッションでは、知っておくと心強い光と色の知識をみなさんと一緒に確認していきます。
色の決まりや仕組みを理解することで、ドキュメントやガイドラインの意図を正しく掴むことにつながり、私たちが気をつけるべき点をしっかり抑えることができるようになります。小難しい話の並んだドキュメントももう怖くありません。
もちろん、色のお話はiOSやiPhoneだけのものではありません。他のアプリやスライド資料などを作るときにも役立ちます。読みにくいスライドで聴衆のみなさんをがっかりさせてしまった……ということがないように、この機会に色への意識を変えていきましょう！

【対象】

• RGBカラーコードまではわかるぞ！という方
• 発表資料の質をワンランク上げていきたい方
• ガイドライン中の謎の用語と英語で手が止まっちゃう方
• 色に関する注意事項の丸暗記が苦手な方、卒業したい方

【取り扱うテーマ】

• で、コントラスト比って何でしたっけ？
• HIG Colorに載っている謎の虹色画像は何者？
• 色覚異常の方は何色の区別が苦手なんだっけ……？
• ダークモードっていうのが最近の流行りなの？なんで？
• イラレにiPhoneのスクショを配置したらヤバイ色になった助けて！

また、これらの問題の理解に必要となる光の仕組みや色の定義の説明、関連するガイドラインの紹介も行います。

シェーダアートとは各ピクセルの座標値と共通のデータからそのピクセルの色を決定し、様々なイメージをスクリーン上に表現する手法のことです。時にシェーダ芸と呼ばれることもあります。
これは主にシェーダと呼ばれるGPUで実行されるプログラムを記述することで実現します。

様々な手法が編み出され、そのシンプルな原理とは裏腹に実に多彩な表現が可能となっています。

Web上にはシェーダを閲覧/投稿できるGLSL SandboxやShadertoyといったサイトがあり、多くの驚くべき作品を目にすることができます。

もちろんWebに限らずiOSでもシェーダアートは実現できます。

本セッションではまずシェーダアートの動作原理を解説します。
次にstep関数やfract関数といったシェーダ用の組み込み関数をいくつか学んだ後、距離場・極座標など表現方法のヒントとなる概念に加えて、複製・ノイズなどの基本的なテクニックも紹介します。

また、共通データに時間を渡すことでアニメーションを行ったり、加速度センサーやマイクの音量を渡すことでインタラクティブな表現ができるデモも披露します。
さらにレイトレーシングの一種であるレイマーチングを用いた3次元的な表現も紹介します。

普段のプログラミングとはまた一味違う体験を、そしてあなた独自の世界を表現してみませんか？

Windows / macOS / Ubuntu / iOS / Android / UWP向けに縦書きのできるテキストエディタを趣味で開発しています。
小説や脚本などでいまだに根強い需要のある縦書きのテキスト入力を6プラットフォームに提供する唯一のプロダクトを目指しています。
（Windows / macOS / Ubuntu / Androidでリリース済み、iOS版リリース予定、UWP版プロトタイプ完成済み）

このプロダクトでは全プラットフォームで同じ描画結果を手に入れるためにテキスト描画エンジンから自前で作っています。
トークでは文字とコンピュータの関係、縦書きという特殊な書字方式とその裏側の実装、テキストエディタや組版、iOSやAndroidに限らないクロスプラットフォームなアプリ開発について話します。

内容

• テキストを表示するために必要な文字コードとフォントの知識
• コア機能をC++で作る理由
• デスクトップアプリとモバイルアプリを開発するための環境
• デスクトップアプリのテキスト入力とモバイルアプリのテキスト入力
• プラットフォームで千差万別なIMEという特異点
• iOS / Androidの標準TextViewのUIとその縦書きでの再実装

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

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にも採用される予定の技術であり、
そちらも合わせて語りたいと思います。

-