飲食店の予約台帳アプリであるレストランボードでは、電話応対業務をサポートする待望のCTIサービスをリリースしました。

このサービスでは、「CTI-BOX」と呼ばれる専用物理デバイスが店舗の固定電話とiOSアプリを繋ぐハブとなり、システム化を実現しています。
専用物理デバイスを採用したことで、iOSアプリとの連携や通話転送をするためのBLE/SIP/PSTNなど各種通信I/Fや、機器や設置環境の物理的な制約など、通常のアプリ開発とは異なる様々な困難がありました。

本セッションでは、CTIサービスを開発する上で発生したシステム・運用両面での課題と、それを解決するための技術的チャレンジについてお話しします。

この発表は、2016年のiOSDCで登壇した「Reactive State Machine」の続編です。
https://speakerdeck.com/inamiy/reactive-state-machine-japanese

前回お話しした Redux / Elm Architecture について簡単におさらいした後、
Swiftコミュニティが新たに開発した各種フレームワークについて紹介します。

• https://github.com/inamiy/Harvest
• https://github.com/pointfreeco/swift-composable-architecture
• https://github.com/bow-swift/bow-arch

これらのアーキテクチャを理解する上で重要な鍵となるのが「Optics」と「Comonad」です。
関数型プログラミング（とちょっとだけ圏論）の知見が、
iOSに限らずフロントエンド開発全般でどのように役立つのかを見ていきます。

また、これらの概念が Web (React) の世界でどのような類似点を持つのかについても、
合わせて比較検討を行います。

みなさんは、複数のiPhoneを、連携させたことがありますか？

一般的なアプリを作っていると、10台以上のiPhoneを同時に動かす必要はなかなかありませんよね。
そんなレアなニーズに2年以上本気でとりくんでいるフリーランスエンジニアが、実際に動く複数台同期ソルーションのすべてを解説します。

イベントなどでたくさんのiPhoneを同期させてみたい方、アプリに意外な追加要素をつけてみたい方、新しいiPhoneの使い方を考えてみたい方は必見です。

今回は録画での登壇が可能なので、実際にたくさんのiPhoneがsyncしているデモをお見せできるかもしれません。

（本セッションは、2018年のiOSDCで発表した「Synchronized iPhones」の続きですが、前回の内容を知らなくても楽しめます。）

機械学習の「画像生成」モデルもモバイルアプリ（iOS）にのせられます。これによりAI画像生成アプリをつくれます。例えばアニメキャラクターを生成したり、自撮り写真を西洋絵画に変換したりできます。
DCGAN、Pix2Pix、CycleGAN、UGATIT、これらはGANという画像生成技術の応用です。このトークでは上記モデルをモバイル用CoreML形式に変換し、iOS端末上で画像を生成する為の方法を紹介します。本番ではスムースに変換するためのTipsを盛り沢山でお話します。GANのコードを完全に理解している必要はありません。勘所をつかめば、TensorFlowやPytorchといったPythonベースのモデルをCoreML形式に変換して、アプリに組み込むことができます。
変換手順
1, トレーニング済みモデルを用意しよう
GitHubに多くの生成モデルが利用しやすいライセンスで公開されています。今回は、GoogleチュートリアルやGitHubのモデルを紹介し変換します。
2, 「Generator」を見つけよう
GANはGenerator（生成する）とDiscriminator（判別する）で構成されており、アプリで使用するのはGeneratorです。
何百行に渡るGANコードを全て理解する必要はなく、この「Generator」をソースコード内でうまく見つけるのが変換作業の勘所となります。そのコツを説明します。
3, CoreMLToolsで変換しよう
変換スクリプトはシンプルです。ただし変換オプションの指定も必要なので、元のモデルから必要なオプションを特定する方法を説明します。
4, アプリで使おう
Visionフレームワークを使用します。
画像形式の出力を取得するには、OSSを利用するか、モデル形式を少し変更する作業が必要です。その方法を説明します。

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

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

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

2020年、macOSデバイスのApple Siliconへの切り替えが発表されました。ここに至る13年間、iOSデバイスのSoCの歴史はそのままシリコンの進化の結晶、そしてそこに挑むエンジニアの血と汗と涙と涙の結晶でもあります。それを傍目に勝手に話す、そんなセッションです。

発表内容

近年音声サービスが続々と登場しています。
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%まで増えたことで実際にバグの減少につながったのかを中心に日々の開発でテストが実装されることで変わったこと・変わらなかったことをお話しいたします。

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

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

LLDBはアプリ開発時に使うデバッガーツールですが、
Mac用のアプリであれば自ら作成したアプリでなくともアタッチすることができ、
場合によってはアプリのさまざまな情報にアクセスすることができます。

アプリがデバッガーに対し無防備すぎると意図しない情報などにアクセスされるかもしれません。

この発表では、LLDBでMac用アプリのどのような情報にアクセスできるのか、
またこれを防ぐ方法があるのかを考察します。

iOS 13から、より自由度の高いSiri Shortcutsの実装ができるようになったことはご存知のかたが多いはず。
WWDC 2019の動画やサンプルコードで実装の仕方も丁寧に解説されております。

それらを眺めまして、「ここまで大それた実装をしてまでSiri越しの操作を受け入れたい機能、そこまで多くないのでは...？」と思いました。
ユーザーが繰り返しよく使う画面を表示した状態でアプリを起動するというコマンドの対応をするだけでも、十分に利便性の向上を見込めるはず。

そこで、Siri Shortcutsにおいて"特定の画面を開いた状態でアプリを起動する"というコマンドの対応方法に絞って、以下について紹介します。

• NSUserActivityを用いて、ショートカットアプリからコマンドを実行できるようにする最小実装
• 最小実装を踏まえつつ、SpotlightのSiriからの提案にてコマンドを表示させる
• 最小実装を踏まえつつ、コマンドを簡単に登録できるAdd to Siriボタンをアプリ内に配置する
• Add to Siriボタンを配置してもよい画面、配置しないほうがよい画面の考察

xcrunはCommand Line Tools Packageに付属していて、コマンドラインからXcode内の任意のツールを検索、実行できます。コマンドを入力したことがないあなたも、普段使っているツールの中で気づかない内に使っているかもしれません。
検索上位には "xcrun: error:" の声ばかりのxcrunですが、使い方を覚えると痒いところに手が届き、開発効率が上がるはずです。

実際に私が遭遇した課題とxcrunによる解決事例を紹介することで、参加者が新たな利用場面を発見できるような話をします。

対象者:

• iOSアプリ開発の中級者にステップアップしたい方
• 一歩進んだCI環境に興味がある方
• コマンドラインでの操作が好きな方

突然ですが，よく分からない専門用語ってすごくかっこよく聞こえますよね．
相対性理論，粉塵爆発，エラトステネスの篩．．．そして，SOLID原則．
このSOLID原則という言葉を初めて聞いた大学生の頃，何故かこの言葉に強く惹かれました．
それは，当時無秩序にコードを書いてはバグを量産していた自分の開発スタイルを払拭する光を，この原則から感じたのかもしれません．．．

実際に，SOLID原則に従った設計･コードは理解しやすく，かつメンテナンスしやすいと言われています．
例えば，Open Closed Principleに従った設計になっていると，あるクラスへの変更の影響はそのクラス内だけで閉じるようになっているため，何もしていないのに壊れた（汗）という事が起きにくいです．
なぜならば，原則に従うとあるクラスが壊れる要因となる変更はそのクラスに対する変更以外ではあり得ない設計となっているからです．
これはほんの一例ですが，このような恩恵があるため，SOLID原則を意識してソフトウェア開発を行うことは，常にコードに修正を加え続ける開発者にとって有益です．

しかし，当然ですがSOLID原則はiOS開発だけで用いられる概念ではありません．
より広くソフトウェア開発全般で用いらている概念です．
そのため，SOLID原則を説明する文書には，例題としてモバイル開発的なコードが取り上げられることは少なく，iOS開発者にとってその原則の活用方法がイメージしにくい課題があると思っています．

そこで，このトークでは学生だった自分にSOLID原則を教えるならどうするか？という視点で，iOS開発に関わるOSSや独自のコードを用いてSOLID原則を紹介します．このトークは，SOLID原則を知らない人やSOLIDそれぞれが何を指しているかうろ覚えな人等を対象としています．

今年のWWDCでiOS14からSwiftUIがパワーアップしてListだけでなくGridも追加されました。
ListとGridの概念は既にGoogle製クロスプラットフォームのFlutterのウィジェットに
存在していますのでよりFlutterに近づいてきたなという印象です。

実はSwiftUIの知見があればスムーズにFlutterに移行でき、
またFlutterでの開発経験があればSwiftUIに移行するコストも少ないです。
私はどちらかといえば、FlutterがiOSアプリエンジニアにもっと普及すればいいのにと思っています。

本セッションではサンプルアプリをSwiftUIとFlutterの両方で開発してみて、
SwiftUIとFlutterそれぞれの書き方を検証したいと思います。

それとともにFlutterの学習ロードマップを紹介しようと思います。

聞いてほしい対象者

• SwiftUIにそろそろ本腰を入れようと人
• SwiftUIの知識でFlutterの学習コストを減らしたいと思っている人
• Flutterでのアプリ開発に興味がある人

皆さんは、新卒が入ってきたタイミングでメンターになったり、いわゆる初心者の人にプログラミングを教えることはあるのではないでしょうか？

誰だって、初めはプログラミングに不慣れな初心者だったはずです。今回は、私が大学生時代に、100人以上の中高大学生にiOSアプリ開発を教え、多くのアプリのリリースをサポートしてきた経験から学んだことを紹介していこうと思います。

【トークプラン】

• プログラミング初心者にプログラミングを教える上で、注意するべきこと
• やってみてうまく行ったこと
• やってみてあまりうまくいかなかったこと
• 妥協をしてはいけない点
• どの様なアプリリリースの手助けが有効なのか

主にコンテンツを提供するアプリの開発に携わっていると、新機能をリリースしてKPIが改善した際に、コンテンツによる影響なのか新機能による影響なのか区別が困難という問題があります。
そこで一般的によく用いられている手法として、A/Bテストと呼ばれる手法があります。
自分が開発に携わっているサービスのA/Bテストは、新機能の表示の切り替えでKPIの変化を検証しています。
その表示の切り替えを管理するのが、Feature FlagやFeature Toggleと呼ばれる機能の有効・無効をコード上で切り替えるテクニックです。

A/Bテストの実施数が増えるに従って、Feature Flagの数も増えていきます。
これにより、A/Bテストを未実施、実施中、検証済みなどのFeature Flagのステータスを管理するコストが増加していきます。
ステータスを正常に管理しないと、未実施のFeature Flagが本番に露出されたり、検証済みのFeature Flagのコード上での削除漏れという問題が発生します。

そこで、検証範囲や検証期間に合わせて、Feature FlagをRelease、Ops、Permission、Experimentという4分類で管理するようにしました。
これにより、それぞれのFeature Flagの役割が明確になり、また分類に合わせて挙動を変更することで、Feature Flagの管理コストを削減することができます。
今回のトークでは、実際のサービスでのFeature Flagの分類に従った運用方針を紹介します。

WWDC20ではAppleからCarKeyが発表され、iOSの標準機能としてiPhoneをクルマの鍵として利用できるようになりました。とはいえ、CarKeyは現在BMWの最新機種でしか利用することができません。

CarKeyを利用しなくてもiOS13から追加されたCryptoKitを利用すると様々な暗号アルゴリズムを簡単に利用することができ、CoreBluetoothと組み合わせることで簡単にiPhoneを利用したスマートキーシステムを実現することができます。

このトークでは、リモコンキーすらない古いクルマにArduinoとiPhoneを利用したスマートキーシステムを構築する過程で得た様々な知見を共有します。

AppleがWWDC 2019で発表したLow-Latency HLSは、2秒未満の遅延を実現することができます。
しかし、Apple Low-Lantecy HLSはとても複雑で、現時点で採用している製品はあまり多くありません。
今回はApple Low-Latency HLSが既存のLow-Latency HLSとの違いや内部の仕組みや、AVPlayerで再生する場合にどうすればいいのか、既存の製品や新しく配信サーバを構築するときにどういったことに気をつけていけばよいのかについて解説していきます。

Call Directory Extensionをご存知でしょうか？ざっくり言うと、CallKitが提供する機能の一つで、電話番号と表示内容のペアを予めiOSに登録しておくことで、着信時に登録した内容を画面に表示させることができ、なおかつ着信履歴にも表示内容が登録されるという機能です。この機能を利用して、登録した名刺や同僚の氏名や部署/役職が着信時に表示できるようにしたところ、お陰さまでリリース以来ご好評いただいております。

そんな着信時氏名表示機能ですが、開発初期において、一部の電話番号について着信時に登録した内容が表示できない現象に悩まされました。

本セッションでは、どういった番号が簡単に着信時表示できないのかをご紹介するとともに、Speakerboxという、かつて公開されていたサンプルアプリを使って検証を行った際の苦闘の記録、さらにはiOS13以降で注意すべき点についてもご紹介します。