iOSDC Japan 2019 トーク一覧

採択 2019/09/06 14:40〜 Track D WASEDA-EDGE (20分)

VLEAP.が目指し、VRがもたらす半歩先の未来

Project VLEAP. 共同代表・CTO 新保正悟 ShogoShimboVR
-
3
採択 2019/09/06 15:10〜 Track A レギュラートーク(30分)

FatViewControllerを安全に書き換える方法が見つからなかったので、どういう痛みを許容するか考えた

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

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

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

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

このトークではFatViewControllerの書き換えを「自動テストを書いてから」というお約束を守ってこなすのが難しかった話をします。
そのうえでなるべく安全に、現実的に書き換えていく方法にはどんなものがあったか、どんな部分で安全を切り捨てて痛みに耐える判断をしたのか話をします。
採択 2019/09/06 15:10〜 Track B レギュラートーク(30分)

iOSアプリのリジェクトリスクを早期に発見するための取り組み

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

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

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

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

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

iOS開発においてApp Store ReviewガイドラインとApp Storeに提出できるアプリの要件を満たすために気をつけるべき注意点と、今回紹介するチェックツールと同様のものを自作するために必要な知識を持ち帰ってもらいたいと思います。
採択 2019/09/06 15:10〜 Track D レギュラートーク(30分)

サービスにおけるデザインシステムの構築

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

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

概要
- デザインシステムの基礎
- 導入にあたって
- エンジニア側からできること
- カラー管理・自動化
- 画像管理
- インタラクション
採択 2019/09/06 15:10〜 Track E レギュラートーク(30分)

クロマキー合成を使い透過動画をAR空間に表示する

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

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

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

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

この発表では以下の内容について話す予定です:
- クロマキー合成シェーダーの実装
- 60fps音声付きでの透過動画のスムーズな表示
- リアルタイム配信映像の受信について
採択 2019/09/06 16:00〜 Track D 技術パッション共有トーク(60分)

Swiftプログラミングと論理 〜そして帰ってきた圏論〜

稲見 泰宏 inamiy
「プログラミング」と「論理」の世界には直接的な対応関係があり、
私たちが普段書いているSwiftにおいても例外ではありません。

例えば、論理の世界における命題「AかつB」はタプル型 `(A, B)` 、
「AならばB」は関数型 `A -> B` を使って書くことができます。
これらの型(命題)を組み合わせ、適用していくことで、
あたかも論理式(や数式)を証明するかのように、アプリのプログラムが完成します。

この、「型 ⇔ 命題」、「プログラム ⇔ 証明」に対応することを「Curry-Howard同型対応」と言います。
この背景を知るには、「直感主義論理」と「型付きラムダ計算」の両方を学ぶことが重要です。

そこで、この発表では、理論的基盤となる「古典命題論理・述語論理」「ラムダ計算」の基本をおさらいした後、
「直感主義命題論理」「Curry-Howard同型対応」について、実際にSwift言語を使ってお話しします。
また、Swiftがサポートする「多相型」、「Protocol (Witness)」、「Opaque Result Type」等にも触れ、
圏論の図式を使った、より手軽で簡単な解説も予定しています。

なお、今回の発表は、昨年のiOSDCの発表の続編になります。
事前の予習として、下記のスライドをご参考ください。

代数的データ型 https://speakerdeck.com/inamiy/algebraic-data-type-in-swift
圏論とSwiftへの応用 https://speakerdeck.com/inamiy/iosdc-japan-1
採択 2019/09/06 16:00〜 Track E レギュラートーク(30分)

詳解 Auto-Renewable Subscriptions

ロクネム _rockname
本トークでは、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. リジェクトについて気をつけたいポイント
採択 2019/09/06 16:10〜 Track A iOSDCルーキーズLT(5分)

日本のサマータイムに苦しめられた話

uhooi the_uhooi
みなさんは以下の4日が何の日かご存知でしょうか?
・1948年5月2日
・1949年4月3日
・1950年5月7日
・1951年5月6日

正解は「日本におけるサマータイムの開始日」です。

実は日本でも1948〜1951年の4シーズンのみ、サマータイムが実施されていたことがあります。
Appleは日本のサマータイムを忠実に再現しており、タイムゾーンをJST(日本標準時)にすることで確認できます。

実際の業務で、サマータイムの開始日の文字列が日付型に変換できず、アプリが強制終了することがありました。
原因の追求とサマータイムの仕組みの調査に苦戦したので、本セッションではそのときのできごとを実際に対応した時間軸に沿って話します。
iOSのバージョンによって挙動が異なる点も苦しめられた一つです。

※本セッションではObjective-Cのコードのみ扱います。ただし、Swiftのみ扱っている方でも理解しやすい内容となっています。

【アジェンダ】
・日本のサマータイムについて
・サマータイムによる不具合の内容
・不具合の調査結果
・対応策の検討と、実際に対応した方法

【想定する聞き手】
・日本にサマータイムが導入されていたことを知らない人
・iOSアプリ開発でサマータイムを考慮したことがない人

【ゴール】
・日本で導入されていたサマータイムの境界日時を知り、取り扱いに気をつける日時だと認識する
・iOSにおける日本のサマータイムの実装を知る


「キング・クリムゾン…1時間もの時間が消し飛び、この世には「サマータイムが発生した」という「結果」だけが残るッ!!」
採択 2019/09/06 16:10〜 Track B LT(5分)

今こそ理解しよう、輸出コンプライアンス

坂本 和大 kazu0620
iOSアプリを審査に提出するときに回答が必要となる「輸出コンプライアンス情報」についての質問。あなたは毎回、正しく理解して最適な答えを選ぶことが出来ている、と胸を張って言えますか?

HTTPSも暗号化に含まれるの?暗号化を使用しているけれど、EAR(米国輸出管理規則)の免除資格を満たしているか曖昧だ、など不安を抱えながら回答している、という方もいらっしゃるのではないでしょうか。

本トークでは5分間でフローチャートを交えながらこの「輸出コンプライアンス情報」にあなたのアプリがどう回答するべきなのかを説明します。このトークさえしっかり聞けば、明日以降のiOSアプリの申請では自信を持って「輸出コンプライアンス情報」に回答することができるようになるでしょう。
採択 2019/09/06 16:15〜 Track A iOSDCルーキーズLT(5分)

Property Delegatesがもたらす新しいSwiftプログラミング

darquro darquro
Swift 5のiOS13から使用できる機能の一つにProperty Delegates(SE-0258)というものがあります。
SwiftUIでも@StateなどすでにPropety Delegatesで実装されたものもあり、目にした方もいらっしゃると思います。

Property Delegatesはとてもユニークな機能で、これまで書いていたボイラープレートを解消できたり、アーキテクチャやコンポーネント設計を考える上でも、重要な機能の一つとなってくるのではないでしょうか?

この発表ではProperty Delegatesとはどのようなものなのかを紹介するとともに、
どのような課題を解決するのか例を踏まえて紹介します。

概要
Property Delegatesとは
実装例の紹介(State、User Defaults、Validation)
Swiftプログラミングにおける継承、抽象化、関心の分離などのこれまでの考え方などを踏まえたProperty Delegatesの役割の考察
採択 2019/09/06 16:15〜 Track B LT(5分)

5分でわかる!Xcode 11から使えるXCFrameworks

Sho Ikeda(いけしょー) ikesyo
WWDC 19で発表されたXcode 11の新機能の中でも喜ばしいものの1つは、XCFrameworksという、フレームワークの新しいバイナリ配布フォーマットです。これまでフレームワークの配布には".framework"という拡張子のフォーマット(バンドル)が使われていました。しかし".framework"のバイナリの配布では、1つのバンドルでシミューレーターとデバイス両方で使用できるようにするためのビルド手順の複雑さ、iOS用とmacOS用、tvOS用など対応プラットフォーム毎にバンドルを分離する必要(この場合は3つ)などの問題がありました。

Xcode 11から使える".xcframework"という新しいフォーマットは、まさにこれらの問題を解決しているのですが、どのように解決しているのか、またどうしてXcode 11のタイミングで導入されたのでしょうか?本LTではXCFrameworksの構造や作成方法、そしてこの形式が導入された理由(の推測)に迫っていきます。
採択 2019/09/06 16:20〜 Track A iOSDCルーキーズLT(5分)

LLDBデバッガで不具合の原因を特定して開発速度を上げよう

クウルス Qoo_Rus
アプリ開発の経験が無く、プログラミングそのものの経験も浅い、そんな初心者の困り事の一つは、不具合の原因を特定するのに多くの時間を費やしてしまうこと。
原因特定スピードを上げるにはLLDBデバッガが有効です。
Xcode10.2から登場したvコマンドについて
- vコマンドでわかること
- vコマンドの操作手順
- poコマンドとの違い
をお話します。
LLDBデバッガを活用した経験があまりない方や、poコマンドを普段使っていてvコマンドを使ったことがない方向けです。
採択 2019/09/06 16:20〜 Track B LT(5分)

先生のことをお母さんって呼んでも大丈夫。そうObjecive-Cならね

bannzai _bannzai_
日本ではほぼすべての人が義務教育期間を経て立派な大人になっていくと思います。そして、そんな意識が曖昧な期間の人々は大きな過ちを犯しがちです。そう。例えば「先生」に対して「お母さん」と呼んでしまう問題は鉄板の過ちと言えるでしょう。人間は過ちを犯すものです。脳内では「先生」と「お母さん」は区別はついているはずなのに呼び間違えてしまう事象が発生してしまいます。脳内に常にバグがあります。そんな我々が書くプログラムにおいてもそのようなバグが混在しないと言えるでしょうか?いいえ。発生しないなんて言い切れないです。特にSwiftのような実行前に厳格にチェックが入るシステムなら事故は減らすことができると思います。しかし、私達が普段扱っているのはSwiftで記述できますが、未だに@objcなどの存在がちらほら見えるUIKitやFoundationを支えているであろう Objective-C の存在を感じざるを得ません。Objective-Cでは非常に動的にメソッドを呼び出すことが可能です。これはつまり「先生」を「お母さん」と呼び間違える可能性が出てくるということです。Objective-Cの世界では「先生」に対して「お母さん」と呼び間違えたら自分が羞恥心でクラッシュします。

このトークではObjective-Cにおいて、「先生」を「お母さん」と呼び間違えてしまった場合の復帰策についてお話していきます。
採択 2019/09/06 16:25〜 Track A iOSDCルーキーズLT(5分)

Core MLで実現する爆速のARサイズ計測

Kohei Arai kokoheia
iOS12から搭載されたAR Measureアプリは、ARKitの精度を証明するとともに、現実のものを何でもスマホで測ることができるという世界を実現しました。しかし、AR Measureの操作には慣れが必要だったり、自分でスマホを持った状態で動き回らなくてはいけないという課題が存在します。そんな課題をCore ML、すなわち「機械学習」を使って解決することができます。例えばフリマアプリなどで服を売りたい時、服の着丈、身幅、肩幅、袖丈などを載せたいと思う人がいると思います。このようにあらかじめ測定したい場所・指標が決まっている場合、機械学習でそれらを測るために必要な点群の位置を推定することができます。点群の位置さえ推定できれば、ユーザーがわざわざARで測らなくても、平面認識と深度推定によって自動的に現実物のサイズを得ることができます。つまり、機械学習で「どこを測るか」を決めて、ARで「それが現実世界でどのくらいの長さなのか」を決めます。今回はTシャツを例に、その着丈、身幅、肩幅、袖丈をARKitとCore MLを使って一瞬でサイズ測定するプロトタイプをお見せします。今回のプロトタイプを応用すれば、インテリアや人の身長など、様々なものを一瞬で測ることができるようになります。この発表では、機械学習によっていかにARのサイズ計測が簡単かつ速くなるか、というお話と、それによって実現できた精度とその改善方法、その過程で使用したモデルなど技術的な知見を共有します!
採択 2019/09/06 16:25〜 Track B LT(5分)

iPhone 設定をアプリから操作してらくらく環境構築

Kuniwak orga_chem
iOS の設定は Configuration Profile という形式のファイルをインストールすると変更できることは、意外と知られていません。
もし、これをアプリを通してインストールできれば、iOS 11 未満でも Wi-Fi を QR コードで繋げるなど様々な可能性が広がります。

この LT では、Configuration Profile によってできること、そしてアプリから Configuration Profile をインストールする方法を解説し、皆さんの iPhone 環境構築体験を豊かにするための知識を披露いたします。
採択 2019/09/06 16:30〜 Track A iOSDCルーキーズLT(5分)

1ヶ月半でプッシュ通知許諾率を17%から40%にあげた話

akutsu sky_83325
マーケチームから来る「あくつ〜。プッシュ通知許諾率あげてくれないとリテンション施策打てないよ〜」という声。

平均30%と言われる承諾率だが、何故か僕たちのアプリは17%・・。

プッシュ通知承諾パネルを表示するタイミングは、熟考された上に以下の2つのタイミング。
- お気に入りにアイテムを追加した時(新しくお気に入り商品が投稿された事を通知するため)
- 商品の購入が完了し、取引が始まった時(取引のリマインドのための通知を送りたいため)

何が悪いのかさっぱりでしたが、意外なことで解決しました。
ある1つのことをしただけで、プッシュ通知許諾率が全体平均17%から40%にあがったワケとは!?
拘りの強いiOSエンジニア(デザイナー)が陥りやすい罠についてサクッと話します。
採択 2019/09/06 16:30〜 Track B LT(5分)

Amazon Pinpoint でユーザーに合わせたプッシュ通知を実現する

kiwi koga_wiwi
プッシュ通知の配信といえば Firebase を思い浮かべる方が多いと思いますが、
AWS でも Pinpoint というサービスを使うことで、プッシュ通知のセグメント送信をすることができます。
さらに、 AWS Pinpoint では AWS Lambda を使ってセグメントをカスタマイズすることができるため、
ほかの AWS リソースのユーザー情報をもとに通知内容をユーザーごとに変更することまでできます。
また、ユーザーに複数のチャネルを割り当てることができるため、プッシュメールとプッシュ通知を使い分ける、といったことも可能です。

本 LT では、 Pinpoint を用いたプッシュ通知の配信から、こうしたユーザーごとのカスタマイズまでを扱います。
特に普段のアプリのバックエンドで AWS を活用しており、通知配信も AWS 内で行いたい方の参考になれば幸いです。
採択 2019/09/06 16:35〜 Track A iOSDCルーキーズLT(5分)

完全に同じ開発環境を素早く用意できる(もしくはできない)技術

Hiroyuki Aoki Solti
開発環境の構築って面倒ですよね。
Xcodeのインストールは時間がかかるし、その他いろんなツールに関して手順書を用意しておいても、ちょっと違うバージョンがうっかり入っちゃうとかよくあります。

このLTでは、毎月数十台のMacをセットアップし続けてきた経験から、Appleの提供する標準機能だけで全く同じ構成のmacOS環境を準備するために行ってきたいくつかの方法と、それぞれの特徴についてお話しします。
また、Sierra -> High Sierra -> Mojaveと毎年バージョンアップされるに伴って利用できる技術が変わっており、現在進行形で困っていることについても話します。
採択 2019/09/06 16:35〜 Track B LT(5分)

SOLID原則を生活に適用する

takasek takasek
SOLID原則は、オブジェクト指向プログラミングにおける基本的な5つの原則です。

S - 単一責任の原則 (Single Responsibility Principle)
O - 開放/閉鎖原則 (Open/Closed Principle)
L - リスコフの置換原則 (Liskov Substitution Principle)
I - インタフェース分離の原則 (Interface Segregation Principle)
D - 依存関係逆転の原則 (Dependency Inversion Principle)

コーディングにおいて、言語化できない不吉なにおい(Code Smell)を感じたときには、これらの原則に照らし合わせることで設計の間違いを言語化し、修正の手がかりを掴むことができます。

SOLID原則はもちろん、ソフトウェア設計のための原則です。
しかしオブジェクト指向は「複雑な問題領域を分割統治する」コンセプトであり一般性を見いだせます。原則が転用できるのは、コードの中のみではないはず。
このLTでは、コーディングにまつわらない日常生活のものごとをいくつか例に挙げ、SOLID原則の視点で解釈してみます。
ドキュメンテーションから部屋掃除に至るまで、SOLID原則を適用すると、どのような「におい」をあぶり出し、改善することができるのでしょうか?
そうやってSOLID原則に慣れ親しんでみれば、コーディングでのSOLID原則の熟達にも役立つことでしょう。

30分枠でも同タイトルのプロポーザルを提出していますが、LT枠としては「こんなふうに共通の課題を見いだせる!」というアハ体験の楽しさを重視したいと思います。
採択 2019/09/06 16:50〜 Track E レギュラートーク(30分)

動画アプリの投げ銭機能における消耗型課金の仕組みと実装

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

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

このセッションでは、公式ドキュメントを参考にしながらConsumableのネイティブ実装をした話を他の課金方式と比較しながら紹介します。
  • 1
  • 2 (current)
  • 3
  • 4
iosdc-japan-2018 sponsors iosdc-japan-2018 potential-sponsors 開催後請求
ブースWL 要支払確認 要モノクロロゴ
仮採択 採択しない Rookie
仮採択 採択済 保留 情熱加点 採択しない 前夜祭 目玉 ルーキーズLT参加
Order#確認 アンケートメール不要