iOSDC Japan 2020 プロポーザル一覧

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

App Clips - Appleが本当に破壊したいもの

knchst knchst0704
先日行われたWWDC2020で発表されたApp Clipsには衝撃を受けました。今年のAppleの姿勢はとてもアグレッシブで様々な業界に乗り込んできました。
なかでも自分が大きいと思ったのが、Tencentが発明したMini Programに対して宣戦布告をしたことです。長らくこの領域で圧倒的なプレゼンスを発揮していたMini ProgramとApp Clipsの違い、そして今後どのような世界が実現されるのかお話します。
2
レギュラートーク(20分)

GraphQL API という選択肢

NAKASHIMA motoshima1150
GraphQL API を使ったことはありますか?
Facebookが主導で作られたクエリ言語で、よく REST API と比較に挙げられています。

REST APIの延長線としてキャッシュ、エンドポイント、スキーマ設計など考えると苦労することが多いと思います。
GraphQL APIには明確に得意なシチュエーションのある仕組みだと思っています。

実際に使って得た経験をもとに、iOSとGraphQLとの付き合い方やどうあるべきかを私なりにまとめてみましたので
GraphQL API をよく知らない、使ったことがない方へ、WebAPIの選択肢を一つ増やすことができればと思っています。

このセッションでは、Github v4 API を用いて以下の内容を説明いたします。
・GraphQLの特性
・快適に開発を行うための準備
・iOS向けライブラリApolloを利用した実装
・テストについて考える
4
他イベントOK レギュラートーク(20分)

明日から使える多機能デバッグメニューTip

皆さんのアプリにはデバッグメニューはありますか?
デバッグ中や配布後のアプリでFirebase環境や、ログイン連携先のSNS環境を切り替えることができるデバッグメニューを作ることで、
dev1, dev2, ...stg, prdと環境を変えるごとにビルドし直す必要がなくなり、開発効率を大幅に向上することができます。

また、APIの通信結果、Gitのブランチ名などの情報をアプリ内で見れるようにすることでテスターとの連携、問題の切り分けが簡単になります。

このトークでは、下記のようなデバッグメニューTipsと、実際に運用上効果の高かった機能を紹介します。
- API通信の結果を監視する
- Gitの現在のブランチ名、コミットハッシュを確認する
- Facebookログイン環境をビルドせずに切り替える
- Firebaseのプロジェクトをビルドせずに切り替える
- その他運用上効果の高かった機能
3
他イベントOK レギュラートーク(20分)

CIのキャッシュをできるだけ生かしてワークフローを高速化する

CIを導入したものの、ビルド時のワークフローが遅いなと思った経験はないでしょうか?
どうしてもCI環境ではローカル環境に比べ、マシンパワーによりビルド速度の制限は受けてしまいます。
しかし、それ以外のあらゆる環境構築はキャッシュ機能を生かす事で過去のビルドから引き継ぐことができます。

このトークでは、実際のプロジェクトで運用されていたBitriseのワークフローを 40%〜50% ほどの高速化に成功した話を題材に、
明日から使えるキャッシュを活かしたワークフローの高速化についてお話しします。

- CIのキャッシュ機能の制限
- 周辺ツールでキャッシュを生かす
- Ruby Gems
- CocoaPods
- Firebase App Distribution
- キャッシュのヘルスチェック
2
他イベントOK レギュラートーク(40分)

400種類のアプリを毎日申請する自動化の技術

Kishikawa Katsumi k_katsumi
株式会社ヤプリではプログラミング不要で高品質なネイティブアプリケーションを作成・配信できるサービスを提供しています。

CMSの設定にしたがってそれぞれ異なるプロジェクトを生成し、アプリケーションをビルド、コード署名をして、連携されているアカウントからAppStore(またはGoogle Play ストア)にアップロードします。

この一連の工程は今でこそ高度に自動化されていますが、最初からそうだったわけではありません。

アプリケーションの内容によっては、最初に手作業でプロジェクト構成やソースコードを編集する必要があったり、バンドルIDやバージョンを事前に適切に設定しておかなければならなかったり、コード署名やPush通知の署名に必要なリソースをあらかじめ決まった位置に配置しなければならかったりする時代がありました。

アプリケーションは一つ一つすべて内容も提供元の会社も異なるので、工程の途中でさまざまな問題が発生します。
バンドルIDを間違えて設定してしまうと、別の会社のアプリを更新してしまうかもしれません。
そのため、最近まではこの作業はデベロッパーが担当する必要がありました。

サービスを発展させていくには自動化が不可欠です。
今でこそ、ほとんどのケースで誰でも簡単にアプリケーションをビルドして申請できるようになりましたが、その道のりは簡単ではありませんでした。

この講演では、ヤプリのサービスを支える自動化の仕組みと克服してきた問題、現在も取り組んでいる技術的な課題についてお話しします。
同様の問題を抱えている人はほとんどいないと思いますが、ビルドから申請までの一連の作業を自動化するにあたって、技術選択や問題解決の一助になれば幸いです。
6
他イベントOK レギュラートーク(40分)

SourceKit LSPをブラウザでコードを読むために活用する

Kishikawa Katsumi k_katsumi
LSP(Language Server Protocol)はIDEで必要とされるソースコードのオートコンプリートやシンボルの定義元にジャンプするなどのプログラムを解析して情報を提供する機能をサービスとして実現するものです。
IDEで必要とされる機能というものは、プログラミング言語が変わってもやりたいことはほぼ同じです。LSPが登場する以前は言語ごとのIDEがそれぞれ実装して提供していました。
LSPは、このような言語が変わっても共通して求められるIDEの機能を抽象化して開発ツールから使えるようにする仕様です。

SwiftのLSP実装はSourceKitを利用して作られているのでSourceKit-LSPと名付けられています。
SourceKit-LSPを利用すると例えばVS CodeなどのXcode以外のエディタでも、LSPに対応していればXcodeが提供するような入力補完や定義元にジャンプするなどの機能を利用できます。
LSPは非常に複雑なIDEの機能を、APIを利用するように簡単に使えてしまう技術といえます。

Xcode以外のエディタでXcodeの機能が利用できることは便利ですが、コードを読むときにも必要だと思いませんか?

LSPはどんなソフトウェアからも使えます。
LSPを利用するブラウザ拡張を作成すると、GitHubでコードを読むときにも定義元へのジャンプなどXcodeを使って読み進めていくときと同じ体験を提供できます。

この講演では実際に私が作成したSourceKit LSPを利用するブラウザ拡張を用いて、GitHub上のコードをブラウザでコードジャンプを駆使しながら読み進める様子をお見せしながら、さらなる応用としてサーバーサイドからLSPを利用することで、iPadでも快適にコード読める技術の作り方を解説します。
2
他イベントOK LT(5分)

本当はこわいLLDB

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

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

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

文字列をコピーできるスクリーンショットを作る

えんどう
iOS 13からSafariなどでPDF形式でフルページのスクリーンショットができるようになりました。PDF形式のためスクリーンショットに写っている文字列もコピーすることができとても便利な機能です。
この機能はUIScreenshotServiceのdelegateを追加しスクリーンショットのPDFデータを作成し渡すことで各アプリも対応することができます。
しかし、viewやwindowのlayerをrenderしてPDFを作るとビットマップ化されたデータをPDFにするために文字列をコピーすることができません。
今回は文字列をコピーできるPDFを作るにはどうすればいいかについて話したいと思います。
4
他イベントOK レギュラートーク(20分)

4年間運用されて表示速度が低下した詳細画面を改善する過程で得た知見

marty-suzuki marty_suzuki
アプリの運用を続けていくと、成長に合わせて機能も増えていきます。
機能のリリースを優先した運用を続けた結果、月日が経過してふと気づいたときにアプリのパフォーマンスが低下していたという経験はないでしょうか?

このトークでは、4年間運用されて表示パフォーマンスが低下していった詳細画面を題材に、原因の特定から最大で表示速度が200%改善するまでを以下のような観点を踏まえて紹介します。

# 第1フェーズ(調査)
・表示速度をどのように計測するか
・何が原因で表示速度が落ちていたか
・そもそもどのようなViewの構成だったか
# 第2フェーズ(最短リリースを目標とした改善)
・どのようにViewを生成していくか
・データの受け渡しをどのように繋げていくか
# 第3フェーズ(画面回転も考慮した改善)
・改善するためにどのようなViewの構成に変えていったか
・Viewに紐づくデータはどのように定義したか

まだしばらくはUIKitも現役なはずなので、これから改善をやってみようという方も新規の実装をしていこうという方にも、参考になる知見を紹介できればと考えています。
2
他イベントOK レギュラートーク(20分)

快適なチーム開発を支えるコーディング以外の技術

星野恵瑠 lovee
今時のアプリは要件がどんどん複雑になっており、複数人のチームが一緒に開発することが当たり前のようになってきている。

しかし複数人で開発をすると、環境面でも気をつけないといけないことが増えてくる。

PR 出されたときどうレビューするかとか、CI/CDをどう構築するかとか、新しいメンバーが入ってきたときどうすればスムーズにプロジェクトに馴染められるかとか、意外とコーディング以外に難しいことがたくさんある。

このトークは、私がテックリードとして、開発チームにコーディング以外どんな支援を行ってきたかを紹介していく。
他イベントOK LT(5分)

CfPの出し方:出す時に「こんなもんググればすぐわかるじゃん?」で自信なくなった話

星野恵瑠 lovee
おそらく多くの参加者は私と同じ悩みを抱えたことあったでしょう:

「iOSDC で登壇したいけど、思いつく話せる内容がどれもこれもググればわかるんじゃね?のようなものばっかりだよな…」
「俺なんて大して詳しいわけじゃないし、やっぱりそれはちゃんと詳しい人が発表した方がいいよね…」

と、いろいろ悩んだ末、自信をなくして結局 CfP を出せなかった、もしくは出せても思ったほど出せていなかった。

この LT は、私がどうやってその自信を取り戻して CfP を出したかのエモい話をします〜
他イベントOK レギュラートーク(20分)

CGAffineTransformはどう働いてるのか?〜Swiftエンジニアのための線形代数〜

星野恵瑠 lovee
SwiftUI、ワクワクしますね。

ところで残念ながらら、まだまだ UIKit で戦わなくてはいけないエンジニアもたくさんいるのだ。

そしてその中に、ビューの変形に CGAffineTransform を使わなくてはいけないエンジニアもまだまだたくさんいるはず。

CGAffineTransform は微妙に分かりにくいものだ。確かに scale や rotate などの比較的に分かりやすいイニシャライザがたくさん用意されているが、それが実際どう動いてるのかがわからない。組み合わせてみたら思ってるのと挙動違うし、プロパティーを確認してみてもよくわからない a b c d tx ty しか出てこないし。設定した scale や rotate は一体どこに消えてるの?

このトークは、そんなあなたのお悩みを解決する。大丈夫難しい話ではない。必要なのは四則演算の知識だけだ。
3
他イベントOK レギュラートーク(40分)

SwiftUI で「依存性逆転の原則」を見つめ直す

星野恵瑠 lovee
「依存性逆転の原則」をご存知だろうか。

この原則によって、我々が多数のオブジェクトを疎結合で組み込み、必要に応じて置き換えることが可能になった。そして Swift の世界で言えばこれはズバリ「protocol」によって実現されたものである。

ところで SwiftUI の登場により、物事が少し変わった。

SwiftUI はこれまで通り protocol に大きく依存している。View protocol を見ればわかる。しかし同時に、SwiftUI は同じくらい Property Wrapper に大きく依存している。@State、@ObservedObject や @EnvironmentObject の他に、今年は更に @StateObject も加わった。SwiftUI はキーコンセプトの一つとして「Source of Truth」があり、これらの Property Wrapper はそのコンセプトの実装に切っても切れないものだ。

ここで問題が発生する:残念ながら、protocol に Property Wrapper の宣言ができないのだ。つまり Property Wrapper を持つオブジェクトは、そのまま protocol で抽象化できないのだ。

SwiftUI は簡潔な「宣言的 UI」を可能にしてくれた強力なツールだ。おかげで一つのアプリは最短 1 ツイートに収まるくらいシンプルなものになった。今後のトレンドも間違いなく SwiftUI だろう。しかし残念ながらこの Property Wrapper の抽象化で protocol 使えない問題が依然として残っている。

果たして、SwiftUI と依存性逆転の原則を両立できるだろうか…

このトークは、その可能性を探っていく。
2
他イベントOK レギュラートーク(20分)

SwiftUI で「依存性逆転の原則」を見つめ直す

星野恵瑠 lovee
「依存性逆転の原則」をご存知だろうか。

この原則によって、我々が多数のオブジェクトを疎結合で組み込み、必要に応じて置き換えることが可能になった。そして Swift の世界で言えばこれはズバリ「protocol」によって実現されたものである。

ところで SwiftUI の登場により、物事が少し変わった。

SwiftUI はこれまで通り protocol に大きく依存している。View protocol を見ればわかる。しかし同時に、SwiftUI は同じくらい Property Wrapper に大きく依存している。@State、@ObservedObject や @EnvironmentObject の他に、今年は更に @StateObject も加わった。SwiftUI はキーコンセプトの一つとして「Source of Truth」があり、これらの Property Wrapper はそのコンセプトの実装に切っても切れないものだ。

ここで問題が発生する:残念ながら、protocol に Property Wrapper の宣言ができないのだ。つまり Property Wrapper を持つオブジェクトは、そのまま protocol で抽象化できないのだ。

SwiftUI は簡潔な「宣言的 UI」を可能にしてくれた強力なツールだ。おかげで一つのアプリは最短 1 ツイートに収まるくらいシンプルなものになった。今後のトレンドも間違いなく SwiftUI だろう。しかし残念ながらこの Property Wrapper の抽象化で protocol 使えない問題が依然として残っている。

果たして、SwiftUI と依存性逆転の原則を両立できるだろうか…

このトークは、その可能性を探っていく。
2
レギュラートーク(20分)

どこまで防げる?Swiftで挑むバーコード誤読との戦い

paper_and_paper paper_and_paper
キャッシュレス決済ではQRコードが主流ですが、まだまだ一次元バーコードも廃れてはいません。ただ、誤り訂正機能を備える優秀なQRコードに比べて、バーコードスキャンでは誤読と戦う準備が少なからず必要です。このトークでは、精度良くバーコードを読み取るためのアイデアと、AVFoundationとSwiftでできることについてお話できればと思います。
2
他イベントOK LT(5分)

Swiftで分かるSOLID原則

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

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

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

そこで,このトークでは学生だった自分にSOLID原則を教えるならどうするか?という視点で,iOS開発に関わるOSSや独自のコードを用いてSOLID原則を紹介します.このトークは,SOLID原則を知らない人やSOLIDそれぞれが何を指しているかうろ覚えな人等を対象としています.
1
他イベントOK LT(5分)

簡単3ステップでできるアウトプット高速化術

AkkeyLab AkkeyLab
iOSDC JAPAN はもちろん、多くの技術系カンファレンスが開催されています。そんなカンファレンスで重要なことは主に2つです。
「インプットとアウトプット」
データの流れではありません、学ぶこととそれを外部に発信することです。オフラインやライブ配信で開催されるカンファレンスの場合、インプットのタイミングは皆さん同じです。しかし、アウトプットはそうではありません。セッションが終了するとともにブログを公開する人もいれば、数週間後にひっそりブログを公開する人もいます。早ければいいとは言いませんが、アウトプットが早いことによる利点は多いと私は考えます。
ということで、今回はこのアウトプットを質と速さにこだわって行うテクニックをご紹介します。

とは言っても人には好き・嫌い、向き・不向きがあるため、パーソナライズせずに話すと眠くなる校長先生の話一直線です。
そこで今回は、簡単3ステップでできるアウトプット高速化術を伝授いたします。

ステップ1
Apple 新製品予想屋を真似しろ!

ステップ2


気になる続きは iOSDC JAPAN 2020 で!お楽しみに!
他イベントOK レギュラートーク(20分)

リリースの手間を無くす!Botを用いるリリース作業の自動化とその運用の紹介

川口 航平 k_koheyi
開発の現場においては,Dangerを用いて定型的な内容のレビューの自動化を行ったり,CIを用いてアプリのベータ版の配布の自動化を行うことがあります.特に,fastlaneを用いてアプリをビルドし,メタデータと共にApp Store Connectへバイナリをアップロードすることがあります.これは,手間を削減してくれるだけではなく,作業ミスをなくすという面で私達を助けてくれます.

しかし,多くの場合リリースの作業はApp Store Connectへバイナリとメタデータをアップロードするだけではありません.例えば,アプリのバージョン番号をインクリメントしたPRの作成や,そのPRを忘れずにマージする必要があります.また,当たり前ですがストアへ公開するためにはApp Store Connectからアプリをストアへ公開するボタンを押す必要があります.つまり,全てを自動化するためには,先述したアップロード以外にもやらなくてはいけない課題がまだ存在しています.

そこで,自社では機械的なリリース作業の大半をBotに任せることによってこの課題を解決しています.このBotはfastlaneを介して,App Store Connectへアップロードをするだけではなく,GitHubの操作やspaceshipの機能を使ってアプリをストアへ公開します.また,開発者の計算機の環境による影響や環境構築の手間をなくすために,チャットツールからコマンドを送信するだけでリリース作業が行えるようにしています.

このトークでは,紹介するBotに自社アプリのリリース作業を任せて半年ほど運用した経験をもとに,手動でやっていた作業をどこまで自動化することができたのか,どのように運用しているのか等を紹介します.トークはCIやfastlaneを使ったことが無い方でも聴講できるものを目指しています.
他イベントOK LT(5分)

今からでも遅くない!TestFlightを使いこなそう

haseken_dev haseken_dev
皆さんはTestFlightを仕事で利用されたことはありますでしょうか?

TestFlightはAppleが提供する、ベータ版ビルドの配信サービスになります。
TestFlightはビルドを配信できるだけではなく、様々な機能が備わっており、開発を進める上で便利なことがたくさんあります。
WWDCでも新機能が追加されることもあり、TestFlightは年々便利になっている印象を受けます。

ですが、配信方法はいくつか種類があり、配信までに行わなければならない作業も配信方法ごとに異なっています。
また、開発するappの内容次第で配信方法も最適な方法を選ぶ必要があり、個人で使ったことがある方も実際に仕事で利用するとなると、どの配信方法が良いか迷ったりすることがあるのではないでしょうか。

このトークでは、TestFlightの配信方法や便利な機能を振り返りつつ、自分がこれまで経験した業務をもとに実際にどの様にTestFlightを利用してきたかお話しできればと思っています。

仕事でFirebase App Distributionなど様々なベータ版ビルドの配信方法がある中で、TestFlightも候補として検討できる材料となれれば幸いです。
1
他イベントOK レギュラートーク(20分)

iOSアプリ開発もできるスパ/サウナを備えたコワーキング施設ランキング

今城 善矩 yimajo
みなさん、ととのっていますかー?

近年、各社ではテレワーク/リモートワークが普通になる新しい働き方というのが我々アプリ開発者にも定着することになりました。そのような今、コワーキングスペースのあるスパ/サウナ施設が新たに注目されていることはご存知でしょうか?一昔前のスパ/サウナ施設は漫画喫茶のようなリラックススペースが定番でしたがそんなイメージはもう古いのです。

今は仕事が終わればすぐにサウナに入って水風呂で冷やす、そんな時代になっています。

このトークではiOSアプリ開発もできるスパ/サウナ施設を紹介します。

ここでなぜiOSDCで話す理由があるのか整理しましょう。ひとつ目の理由として、Appleの創設者スティーブ・ジョブズが禅を学び、その哲学をもって生み出したのがApple製品だというのはご存知のとおりかと思います。

>シンプルであることは、複雑であるより難しい

彼の名言は『執着を捨てる』という禅の考えそのものです。ここで思い出してください、サウナという環境は頭を空っぽにしてひたすら自分と向き合います。やっていることは座禅でありサウナ=禅が成り立ちます。ということはApple製品のアプリをよりよく開発するため、禅としてのサウナを理解すべきなのです。

さらにもう少しトークの意味について説明を加えましょう。AppleはWWDC19でCombineフレームワークというリアクティブプログラミングのフレームワークを発表しましたね。これを使う人たちがよく言葉にする"Hot"や"Cold"という言葉、実は"Hot"というのはサウナのことで"Cold"は水風呂の事です(これも嘘です)。

この5分のトークで語りきれるかわかりませんが、ととのうコワーキングスペース施設の紹介ができればと思います。
1
2019 スポンサー 2019〆切後 資料請求
オンライン対応未決定 削除予定 オンライン対応検討中 要ロゴ 要PR 要支払
仮採択 採択しない スピーカー採択
仮採択(原稿) 採択済 採択しない 仮採択 要審議 ニッチ企画? LT向き加点