iOSDC Japan 2020 プロポーザル一覧

他イベントOK レギュラートーク(20分)

ML for 音声処理

堤 修一 shu223
iOSの音声処理系のフレームワークは、画像処理系のそれと比べて長らく大きな進化はしていませんでしたが、近年は機械学習の技術が取り入れられるようになり、多様な用途で役立つ可能性が飛躍的にアップしました。SoundAnalysisといったフレームワークも登場していますし、Core MLも初期の頃と比較してサポートするレイヤータイプが大幅に追加され、カスタムレイヤーも追加できるため、機械学習を用いた音声処理のかなり多くがiOSデバイス上でも動作するようになっています。

たとえば動画に対して話者識別処理を行い特定話者のフレームだけを抽出するといったことも可能ですし、マイクからの入力を利用して外界の状況をセンシングするようなこともできます。音楽データを楽器ごとに分類するような処理もかなりの精度で動くようになっています。またモデルをオンデバイスでパーソナライズすることも可能になっています。

本トークでは、機械学習を用いた音声処理について、iOSで動作可能なもの、そして実用的なものをピックアップして解説します。
3
他イベントOK レギュラートーク(20分)

実践 Adaptivity and Layout

所友太 tokorom
iPadOSのSplit ViewやSlide Overの登場で1つのデバイスの中でも数多くの画面サイズを扱う必要があります。
もちろん、iPhone SEから12.9インチiPad Proまで多くのデバイスに対応する必要もあります。

それら多種多様な画面サイズに対応するためにはSize Classを基点とし、UIデザイナーとプログラマーが共通認識を持って設計・開発をすることが重要です。
Size Classをベースに複数のiOS/iPadOSアプリを開発した経験を基に、Adaptivity and Layoutのための実践的な方法や勘所を紹介します。
3
他イベントOK LT(5分)

技術とアウトプット

堤 修一 shu223
最近、YouTubeとオンラインサロンをはじめました。完全にうさんくさいと思われそうなコンボですが、同時にブログ・Qiita・Meidum・noteの有料マガジンでの技術情報発信や、GitHubでのOSS公開、国内外の勉強会・カンファレンスでの登壇も多数行ってきました。そんな数多くのアウトプット手段を試してきた中で、各種メディア(テキスト・音声・動画・登壇)・プラットフォームの良し悪しや、得られるメリットについて整理してお伝えしたいと思います。
3
他イベントOK レギュラートーク(20分)

効率よくUIKitからSwiftUIへ移行する

josh yhkaplan
SwiftUIが出て、大きなパラダイムシフトになっています。弊社アプリのObjective-C -> Swift移行の知見を活かし、失敗せずにUIKitからSwiftUIへ移行するための計画と考察した内容を共有します。具体的には、以下のとおりです。

## Planning
- まだ移行できない段階でどう計画を立てるか

## What not to migrate (yet)
- まだまだSwiftUIに向いていない処理と画面を理解する

## Prototyping
- 移行以前に、SwiftUIの使い方と違いを理解するうえでの、prototypingの有効性

## Swift
- 値型や関数型プログラミングなど、モダンなSwiftコードにすることで、SwiftUIへ移行しやすくする

## Reactive Programming
- RxSwift/ReactiveSwiftを使っている、又はまったくリアクティブプログラミング経験のない状態から、SwiftUIでよく使われるCombineの導入方法・準備方法

## Interop
- UIKitとSwiftUIの混在と互換性
- RxSwift/ReactiveSwiftとCombineの混在と互換性

## Components
- コンポーネント化の有効性

## Architecture
- SwiftUIに適したアーキテクチャを評価し、導入する方法
5
他イベントOK レギュラートーク(20分)

いま振り返るAuto Layoutがもたらした知見

ばんじゅん🍓 banjun
Auto Layoutが最初に導入されたころ、既存のレイアウトをAuto Layoutで表現するのは難しいと感じたかもしれません。今では私たちはAuto Layoutの特性を自分なりに理解し、Auto LayoutとManual Layoutの使い分けや、Stack Viewなどのよりシンプルなソリューションを併用してアプリのレイアウトを自在に組むことができます。

2019年のSwiftUIはAuto Layoutとは異なるパラダイムを提供しますが、UIKit/AppKitの置き換えを目的としたものではなく共存を目指していました。2020年になりiOS/macOSアプリはUIKit/AppKitをimportせずに開発できるようになります。未来がSwiftUIにあるという前提においてAuto Layoutの役割はどうなっていくのでしょうか。

プログラミングにおいて過去の全ての知識が急に不要になることは稀です。これまでAuto Layoutがもたらした知見を振り返り、次の世代の開発に活かしていきましょう。UIが宣言的であるとはどういうことか、動的な性質を静的に記述するメリット、制約の局所的な記述と大域的な記述を相互に入れ替えることで見えてくるもの、Auto Layoutが不得意としていた領域をおさらいします。

きっとまだAuto Layoutの必要性が失なわれることはありませんが、振り返りをするには良いタイミングとなるでしょう。
4
レギュラートーク(20分)

iPadOSでマウス・キーボード対応アプリを作る

rokuroku 496_
iPadOS 13.4でついにマウスやトラックパッドを接続可能になったことでキーボードとマウスが揃い、iPadは以前よりもさらに作業・創作用マシンとしての真価を発揮できるようになりました。
このトークではマウス・キーボード対応アプリで抑えるべきポイントについてまとめます。

多くのアプリはマウスやキーボード対応をしていなくても大きな問題になることはありませんが、ドキュメント編集アプリなど、閲覧にとどまらない機能を提供するアプリではマウスへの対応を行うことがその使い勝手に大きく影響します。
また実際にテキストエディタでマウス対応を行った経験を踏まえて、マウス対応そのもの以外にもマウスやキーボードをフル活用するアプリで対応しておくと良いAPIについても合わせてお話しいたします。

- iPadOSにおけるマウス・キーボード
- マウス対応のための準備
- まず抑えるべき簡単な変更
- マウスカーソルの変更について
- マウス操作とタッチ操作を振り分ける
- あると嬉しいコンテキストメニュー
- iOS/iPadOSとキーボード
- シフトキーを使った範囲選択
- ショートカットコマンドなど
3
他イベントOK レギュラートーク(20分)

個人開発iOSアプリにKotlin Multiplatform Projectを採用してみて得られた知見

asmz _asmz
Kotlin Multiplatform Project(以降、Kotlin/MPP)とは、Kotlinで書かれたコードをAndroid、iOS、サーバ、ブラウザなど様々なプラットフォームで動作させることができる仕組みです。

Kotlin/MPPは、一度にプロジェクト全体を共通化するのではなく、プロジェクトの一部分だけを共通化できるという特徴があります。例えば、UIなど各プラットフォーム固有の処理が多い部分はそれぞれネイティブで実装し、ビジネスロジックなどのようにプラットフォーム依存が少ない部分のコードのみ共通化する、といったことが可能です。

私は既に個人開発のiOSアプリをリリース済みでしたが、そのAndroid版を開発するにあたり、「API通信やデータモデルの定義は結局どちらもほとんど同じなんだよなぁ。」という気持ちを抱いていました。
そこでこの点について、上記特徴に挙げた「一部コードのみ共通化」によって、既存のiOSプロジェクトは生かしつつ解決できるのではないかと考え、個人開発でKotlin/MPPを採用し、実際にリリースまで行ってみました。

その経験からこのトークでは、既存iOSアプリのKotlin/MPP構成への移行、「API通信処理」「データモデル定義」といった一部コードのみの共通化手順、それらの対応によるメリット・デメリットや使ってみて分かった所感などをお話しできればと思っています。

## 予定している内容
- Kotlin/MPPを採用するモチベーション
- Kotlin/MPP環境構築
- 既存iOSアプリのKotlin/MPP構成への移行
- コード共通化手順
- 開発中に発生した問題とその対処
- 個人開発ではなく業務での採用判断

## 対象
Kotlin/MPPをまだ触ったことが無いiOSアプリ開発者
2
他イベントOK レギュラートーク(20分)

Faster, Better, Stronger: Improving Builds 最強で最速なビルドを実現するために

josh yhkaplan
一日中Xcodeでビルドしていますね。iOSアプリでビルドの再現性向上と最適化について色々と説明します。

具体的には、以下のとおりについて紹介し、メリデメリを説明することで、導入コストと取り組むメリットを理解してもらって、みんなのアプリに合った改善方法を提案したいと思っています。

## 再現性
- ビルド設定をpbxprojファイルではなく、xcconfigファイルで管理する
- build schemeをXcodegenまたはTuistで管理する

## 最適化
- Appleからの推奨
- モジュール分割
- 依存性管理の最適化
- CIでのキャッシュなど
- Xcode PreviewsやPlaygroundsでビルドを省く
- Bazelなど、違うビルドシステムの導入
4
他イベントOK レギュラートーク(20分)

大解剖!UIColorファミリー

しもとり S_Shimotori_pub
皆さんお馴染み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つ増えそうだということは、つまり?
2
レギュラートーク(20分)

アプリの売上集計を(半)自動化する

rokuroku 496_
アプリにサブスクリプションや課金アイテムがある場合、その売上を経理処理するためには入金額を必要に応じて集計する必要があります。
このトークではiOSアプリの売上集計について、そのために必要なApp Store Connectのレポートについての概要や特殊な知識についてまとめます。

概要ではそもそも「売上とトレンドレポート」「支払レポート」「財務レポート」と幾つものレポートがある点について。
特殊な知識として例えば売り上げの振り込みはApple会計カレンダーという特殊な暦に基づいて行われていること。
またレポート集計を自動化する際の問題や困難とその解決法、タイトルに「半自動化」とあるようにどうしても自動化できない部分について。
Appleからの振込がアカウント単位でまとめて行われるためプロダクトごとの内訳を計算する際に苦労する点。

以上に加えて実際にはどういう仕組みを作ったかをお話しして、いつAppleからの振込額の内訳を計算することになっても大丈夫と思える情報を提供いたします。
また比較できる話としてAndroidアプリの売上集計を自動化する話もします。

- App Store Connectの話
- 売上とトレンドレポートの話
- 支払レポートの話
- 財務レポートの話
- Apple会計カレンダーの話
- App Store Connect APIの話
- レポートファイルのローカライズと戦う話
- BigQueryとLookerを使って売上集計を(半)自動化する
- Androidアプリの売上集計自動化と比較した話
- App Store Connect APIを運用していてつらい点
3
レギュラートーク(40分)

100人でアプリをリファクタリングして見えてきた、最強のiOSアプリ設計に求められること

Yuta Koshizawa koher
4月から5月にかけて、リバーシ(オセロ)のiOSアプリを題材に、みんなでリファクタリングに取り組んで知見を共有するオンラインイベント「Swift Zoomin' 」チャレンジを行いました。100人以上の方に参加していただき、その中から9名の方に成果を発表していただきました。

問題への取り組み方は人それぞれでしたが、それらを俯瞰して眺めるとアプリの設計に求められることが浮かび上がります。それは、

- 型を利用してエラーフローを減らす
- 依存性反転の原則を適用して
- UIやファイルI/Oに依存しないテスタブルなコードを実現
- ドメインロジックをアプリ固有のロジックから分離
- 状態遷移を書き出して整理
- データフローを制御してシンプルに

などです。これらは当たり前に言われていることですが、リバーシアプリという具体的な題材について考えることで、より現実感を伴って理解することができます。本トークでは、個々が行ったリファクタリングの結果を横断的に分析し、具体例に基づいてその効果を説明します。

【どうしてリバーシなの?】

何かを説明するときに、具体例を交えて説明することは重要です。しかし、設計というのは、アプリの持つ複雑さをどう扱うかという話なので、短時間で説明しようとすると次のような矛盾を抱えてしまいます。

- 実際のプロダクトのような巨大かつ複雑なコードベースは短時間で理解できない
- 例示のための単純すぎるコードは理解しやすいが、業務で直面するような複雑さを扱うことが難しい

リバーシなら、誰でもルールを知っているのですぐに仕様が理解でき、それでいて相応の複雑さを持っています。リバーシを題材にすることで、「業務で直面するような複雑さ」を扱いながら、「短時間で理解」できるように説明することを試みます。
2
レギュラートーク(40分)

Bazelを利用したMicro Modular Architecture

Ryo Aoyama ra1028fe5
十分に発達した組織による開発では、本質的な機能間の疎結合化や逆コンウェイ戦略に則った組織構成への適応など、より高度な課題が様々出てきます。もちろんビルド・テスト時間の最適化といった個々の開発者の直接的な課題もその一つです。
どれだけアプリケーションアーキテクチャを洗練させ理解を進めても、これらの課題の解決は難しいでしょう。
そこでリードアーキテクトは、よりソフトウェア的なアーキテクチャを発展、また将来漸進的に進化できるように構成する必要があります。そのためには、構成要素を複数のモジュールに細分化し、組み換え容易にすることが重要です。

最近ではAndroidアプリ開発の流れか、2〜20ほどのモジュールからアプリを構築している所謂マルチモジュール化に挑戦しているチームも多くなりました。
これを更に発展させ、数百のモジュールからアプリを構築するためには通常の開発手法では無理が出てくるため、現担当プロジェクトではビルドツールにBazelを採用しています。

BazelはGoogleが開発し、iOSアプリ開発ではUberやLyft、Pinterestといったモバイルアプリに力を入れているテックカンパニーでも採用されている多言語向けのビルドツールです。
もちろんiOSアプリ開発への導入ハードルはかなり高いですが、効率的なモジュール定義や、CIマシンを含め開発者全員が同じキャッシュを共有するRemote Cacheなどの強力な機能も持っています。

このトークでは、モジュールを数百に細分化することでどのような利点があるのか、Bazelを採用することで何が可能になりどのような相乗作用があるのかをお話します。
9
他イベントOK LT(5分)

今からiOSエンジニアになるとしたら、何を知っておけばいいだろう?

danbo-tanaka ktanaka117
もともと他のプラットフォームでエンジニアをやっている人がiOSエンジニアになりたいという話を耳にすることがあります。自分のところにもそんな相談がきました。
改めて2020年の今、iOSエンジニアになるために必要なことってなんだろう?と思ったのでまとめてみました!

## 内容
- なにを勉強していくとよいのか?
- なにを参考にしたらいいのか?
- どうなったらiOSエンジニアと言えるのか?

## 対象
- もともとWebやAndroidのエンジニアで、これからiOSエンジニアになりたいと思っている人

## この発表を聞いてどうなるか
- iOS開発に関する全体的な知識の概要がわかる
- 君も明日からiOSエンジニア
2
他イベントOK レギュラートーク(40分)

Grand Central Dispatchによる並行アルゴリズム入門

Takanori Hirobe taka1068
近年のモバイルデバイスのプロセッサはマルチコア化が進んでおり、iOSデバイスも例外ではありません。たとえば、最新のiPhoneには6つのコアが搭載されています。

今後もコアが増えていくことは確実で、iOSエンジニアである私たちにとって多くのコアを活かすための知見はますます重要になっています。

そこで、このトークではGrand Central DispatchとSwiftを使ってソートや探索といった基本的なアルゴリズムを並行化する手法を学び、コアをもっと有効に使うための考え方を説明します。

このトークを観て、Grand Central Dispatchを使ったマルチスレッドプログラミングの新たな可能性に触れてみましょう。
3
他イベントOK LT(5分)

XcodeのBuild PhasesにおけるCustom Run Scriptの詳細と活用例

kagemiku kagemiku_en
XcodeにはBuild Phasesに独自のRun Scriptを追加できる機能があります。Cocoapods利用時に追加される"Embed Pods Frameworks"や、Carthage利用時に実行する"copy-frameworks"などもCustom Run Scriptの好例です。

Input FileおよびOutput Fileを指定することにより、Build時にLinterを走らせたり、任意のFrameworkを生成したりすることができます。さらに、Xcode10からはInput/Output File Listsという機能も追加され、より柔軟な使い方ができるようになりました。

Custom Run Scriptは簡単に追加・使用できる一方で、注意して取り扱わないとBuild時間の増加などの問題を引き起こす原因にもなります。

本トークでは、Custom Run Scriptについて、具体的な活用例を交えつつ、正しく活用していけるよう挙動の詳細なども解説していきます。
4
LT(5分)

100人以上の中高大学生にiOSアプリ開発を教えていて感じたこと

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

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

【トークプラン】
- プログラミング初心者にプログラミングを教える上で、注意するべきこと
- やってみてうまく行ったこと
- やってみてあまりうまくいかなかったこと
- 妥協をしてはいけない点
- どの様なアプリリリースの手助けが有効なのか
2
他イベントOK レギュラートーク(20分)

Swift Package Managerの今とこれから

kagemiku kagemiku_en
Apple謹製のPackage ManagerであるSwift Package Manager。
ファーストパーティ製Package Managerということもあり、iOS/Swiftにおけるエコシステムの発展を語る上では欠かせない位置づけにあります。

SwiftによるCLIツールの開発、および配布に際しては使うことも多くなってきたと思いますが、iOS開発という場面に置いては、まだまだ登場する機会は少ないと思います。

最近では、Swift 5.3にてリソースファイルへの対応やバイナリパッケージへの対応など、Package Managerとしての進化は着実に遂げており、今後ますます注目されていくツールになると考えています。

本トークでは、そんなSwift Package Managerの現在の状況、そしてこれからの未来について、iOSエンジニアの視点から余すことなく解説していきます。
3
他イベントOK レギュラートーク(20分)

Webとネイティブアプリの付き合い方を改めて考える

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

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

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

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

予定しているトーク内容
- PWAの現在とiOS Safariにおける対応状況
- Safariで提供されているネイティブ機能
- App ClipsとWeb
- Webとネイティブアプリの使い分けや組み合わせ方を考える
4
他イベントOK レギュラートーク(20分)

Firebase Dynamic Links で既存のユーザーだけでなく、潜在的ユーザーにも体験を提供したい!

中川 泰夫 ynakagawa33
あなたは新しい新機能を開発しているとします。

プロダクトマネージャーから「新機能を含んだアプリがインストール済みだったら、アプリを起動して、未インストールだったら、ストアのインストールページ、または、 特定の 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 サイトを開く」
3
他イベントOK レギュラートーク(20分)

あなたのアプリのファンを増やすためのアクセシビリティ

日向強 coffeegyunyu
iOSは、大きなディスプレイを備え、タッチインターフェースで簡単に扱えるように設計されています。
ですが世の中には大きなディスプレイが見えない人、タッチ操作が困難で簡単に扱えない人が存在します。
また、恒久的ではないにせよ、ある日突然病気になって今まで通りのアプリの利用が困難になることも考えられるし、
運転中や子供を抱えて歩行中など、ディスプレイを見てタッチ操作する、ということが困難な、Situational disability(状況的障害)の瞬間が存在します。

そんな状況に陥った人でも使えるよう、iOSは多数のアクセシビリティ機能を用意しています。
iOSの様々なアクセシビリティの機能や使い方を説明して、あなたのアプリのファンがより増やせればと思います。
2
2019 スポンサー 2019〆切後 資料請求
オンライン対応未決定 削除予定 オンライン対応検討中 要ロゴ 要PR 要支払
仮採択 採択しない スピーカー採択
仮採択(原稿) 採択済 採択しない 仮採択 要審議 ニッチ企画? LT向き加点