iOSDC Japan 2020 プロポーザル一覧

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

そろそろCombine

shiz stzn3
2019年のWWDCで彗星のごとく現れたCombineフレームワーク。

RxSwiftやReactiveSwiftなどのサードパーティーライブラリが
これまで広く使われていましたが
Apple製の公式のリアクティブなフレームワークとして注目が集まりました。

私自身も注目をしており
「Combineフレームワークまとめ」というブログを書くなど
最新の動向を追ってきました。

そんなCombineも登場から1年が経過。

このタイミングで
Combineについて学び始める
あるいはもう一度学び直すのはいかがでしょうか?

このトークでは
2020年版Combineフレームワークまとめとして
Combineの基本的な使い方から
実施にどうコードを書いていくのかを中心として
皆様と一緒にCombineの使い方について一歩一歩見ていきたいと思います。

また、これで終わりにするのではなく
ここからさらに学習を進めるための有用なサイトやツールなども紹介もします。

- Combineは気になっていたけどまだ手がつけられていない方
- 去年試してみたけどもう忘れてしまったなぁと感じている方
- ある程度は知っているけど改めて基礎を復習したい方

そんな方々にご参加いただけましたら嬉しいです。

- お茶を飲みながらのんびり見る
- 家事をしながら聞き流す
- 一緒にコードを書いてみる

といった色々な方法でお気軽にご参加できる内容にしたいと思います。

そろそろCombine

ご一緒にいかがでしょうか?
9
他イベントOK LT(5分)

リモートワークでBitriseを導入したときにハマりにハマった話

tamappe tamapppe
前々からチーム内でBitriseを使ってアプリ配信をしたかったのですが、
既存アプリで設定の仕方が分からなかったのでなかなか導入することができませんでした。

大きな問題となっていたのは、弊社アプリが
- 環境別にApp IDを設定していたこと
- Build Configurationで環境別のマクロを設定していたので当然環境別の配信スキームを用意したい
- 全ての環境で同一のKeychainを使っていたが、環境別でKeychainを設定したいという要望
- AppExtentionも使っていたこと
- plistが環境別にDebugとAdhoc用とで分かれている
- ついでにAppStoreへの自動アップロードも整備したい

問題を上げたらキリがないですが、Bitriseを導入する上で上記の問題がありました。
さらに私はProvisioning Profileの知識が乏しかったので、
BitriseのAutoProvisioningがスキーム別に対応できるのかどうかもこの時は正確には把握できていませんでした。
その状況で3月下旬に社内でリモートワーク導入の連絡が入って急遽、強制的にBitrise配信をできるようにしないといけなくなり
急いでBitriseでアプリの配信をできる環境整備に取り掛かりました。

リモートワークまでにBitriseでビルドできるようにまでは設定できるようになりましたが、
なぜかアプリ起動後にクラッシュするというような問題が発生したりでその原因調査に時間がかかりました。
本セッションでは、上記の問題たちをどのように解決していったのか、そして完成した配信スキームを紹介しようと思います。
3
他イベントOK LT(5分)

iOS Custom Keyboards でできること/できないこと/やってはいけないこと

Kyome Kyomesuke
App Extensionsの一つであり、iOSのソフトウェアキーボードを自作できるCustom Keyboardsをご存知でしょうか?
昨今、自作キーボード(物理)が流行っておりますが、ソフトウェアキーボードの自作にご興味はありませんか?

本トークでは、Human Interface Guidelinesと私の経験則から、iOSカスタムキーボード開発において実現できること・できないこと・やってはいけないことなどをさっとご紹介したいと思います。

・iOS Custom Keyboardsってどんなもの?
・デフォルトのキーボードより魅力的なところ
・今のところ実装できないこと
・HIG的にやってはいけないこと
・日本語かな漢字変換について

カスタムソフトウェアキーボード開発コミュニティーの発展を願って...
10
他イベントOK レギュラートーク(20分)

「それ、自動化できますよ」: note を支えるワークフロー大全

laprasDrum
iOS 開発者はコードを書くこと以外にも様々な業務を抱えています。
みなさんはこんな依頼を受けていませんか?

「Firebase App Distribution からインストールしたいのですが UDID を登録してくださいと言われます。どうしたらいいですか?」
「今開発中の Branch の最新版って触れますか?配信お願いします。」
「現在の審査状況どうなってましたっけ?」
「リリース用の Branch の merge 忘れてませんか?」
「dSYM アップロードしてませんよ。」

メールや GitHub を見に行ったり、手元でビルドし直して fastlane を実行したり…といろんなツールを切り替えるだけでも時間は過ぎてしまいます。
これらの作業、自動化してみませんか?
同僚のように頼もしい Bot を育ててみませんか?

本トークでは私が1人チームのころから iOS 開発に関わる業務のアレコレをコツコツ自動化してきたこと、それをベースに実際に会社で運用しているワークフローを余すことなくご紹介します。
6
他イベントOK レギュラートーク(20分)

google/mediapipe で始めるARアプリ開発

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

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

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

iPadOSDC: Multiple Windows

ひろん hironytic
<これまでのあらすじ>
2019年9月、iOSが13へと進化するその傍らで、ひっそりとiPadOSは生まれた。それはiOSにない特徴的な機能「Multiple Windows」、すなわち「複数のスペースで同じアプリを開いて作業する」機能を有していた。
2020年4月、Magic Keyboardが発売され、iPadはますますノートPCへと近づいていく。「モバイル」と「PC」の境界が消えつつあるこの世界の中で、Multiple Windowsへの対応の有無がアプリの使い勝手に大きな影響を与えようとしていた——


本トークでは、iPadOSのMultiple Windowsを使ってユーザーがどのような体験を得られるのかを紹介し、その後に実際にアプリをMultiple Windowsに対応させる方法について解説します。そこでは、UISceneを始めとするScene APIを整理して段階的に説明します。

・Multiple Windows…なにそれおいしいの?
・シーンは簡単、そう、iOS 13以降のみならね
・複数のシーンをサポート!戦いの始まり
・シーン状態の保存ならオレに任せろ
・プログラムから新しいシーンを展開!
・シーンのライフサイクル(ゾンビもあるよ)
・シンクロナイズドシーン《状態の同期》
・好きなシーンを選んでね

さあ、みなさん、iPadOSDCの時間です!
11
他イベントOK レギュラートーク(20分)

Swift Argument Parserを活用して簡単にコマンドラインツールを作る

Kazumasa Shimomura s2mr_kaz
Swift Argument Parserはターミナル上で実行するコマンドの引数を型安全に解析することができるライブラリです。
元々はSwift Package Manager内で使用されていたUtility的立ち位置でしたが、先日リポジトリとして分割されてからPropertyWrapperが活用されたAPIに刷新するなど動きを見せてきました。
このトークではコマンドラインツールの開発を通して、Swift Argument Parserを使用したコマンドラインツールの開発手法についてを紹介します!
2
他イベントOK LT(5分)

SwiftUIをラップしてUIViewベースの既存アプリに簡単に組み込む

Kazumasa Shimomura s2mr_kaz
Deployment TargetがiOS13以上であれば、UIViewベースの既存アプリでもSwiftUIを使用することができます。
何年も運用してきたレガシーなアプリでも、1画面だけSwiftUIで作って、徐々に置き換えていくと言ったことも可能になります。
このLTではSwiftUIをUIViewControllerでラップして、簡単に橋渡しする方法を紹介します!
4
他イベントOK LT(5分)

SpellCheckerを組み込んでXcode上でできるだけ早くtypoに気づく

かっくん fromkk
日々開発をしている中でも様々な作業があります。
コードを書くことももちろんですがコードレビューも大事なタスクですね。
ただ、コードレビューにおいても人間がすべきものとそうでは無いものがあると思います。
コードの書き方やフォーマットはLintやFormatterを利用するだけでも治安はかなりよくなります。
次に悩まされるのがtypo(打ち間違い)の指摘ですね。
XcodeはBuild Phaseで特定の出力をするとXcode内にwarningやerrorを明示的に表示することが可能です。
そこでコードの内容を読み取り、英単語ではなさそうなコードを発見するとwarningとして表示するツールを作成しました。
本トークでは
- Xcodeでwarningやerrorを表示する方法
- typoを見つける方法
- ツールを自作するまでの流れ
をご紹介します。
世の中からtypoを少しでも減らして、人間がすべき作業に注力していきましょう。
2
他イベントOK レギュラートーク(20分)

既存アプリをCatalystに対応してリリースする時の落とし穴

かっくん fromkk
これまではmacOSのアプリケーションを開発しようと思うとAppKitというUIKitとは異なるframeworkを利用する必要がありiOSアプリの開発とは勝手が異なりました。​
そんな中WWDC 2018でmacOS Mojaveの一部のアプリケーションにUIKitをmacOSに対応したアプリケーションが搭載されることが発表されました。
さらに、翌年のWWDC 2019にてその機能が開発者向けに「Project Catalyst」として公開されました。
Catalyst対応はXcodeでチェックを一つ入れるだけで簡単にビルドをすることが可能です。
しかし、既存Firebase Firestoreを利用しているプロジェクトではうまくビルドができませんでした。
原因の例をあげると、
- 何故かCatalystの時だけTeamの設定が必要なライブラリが現れる
- Catalystに対応していないライブラリがある
- そもそもCatalystに対応していない機能がある
などです。
それらの対応をしたり機能のハンドリングをして、ようやくビルドができていざリリースしようとすると今度はArchiveに失敗します。
それでもリリースはしたかったのでFirebaseなどのGitHubのIssueを眺める日を過ごしていると、少しずつ解決の糸口が見え始め、最終的にはArchive・アップロードに成功することができました。
そこから審査を経てリリースしようとしてもすんなりとリリースさせてはくれませんでした。
連続リジェクトという壁が立ちはだかります。
本トークでは、Firebase Firestoreを利用したアプリケーションのCatalyst化のリリースの方法をご紹介し、審査に提出した際にリジェクトされた事例とその対応をご紹介します。
2
他イベントOK LT(5分)

Catalystに対応したアプリをリリースするまでのリジェクト集

かっくん fromkk
WWDC 2018でmacOS Mojaveの一部のアプリケーションにUIKitをmacOSに対応したアプリケーションが搭載されることが発表されました。
さらに、翌年のWWDC 2019にてその機能が開発者向けに「Project Catalyst」として公開されました。
しかし、既存のiOSアプリをCatalyst化してリリースしようとすると立ちはだかる難関があります。
それはiOSアプリをリリースする時と同様の審査です。
本トークでは既にiOSではリリース済みのアプリをCatalyst化してリリースしようと審査に提出した際にリジェクトされた事例とその対応をご紹介します。
2
他イベントOK LT(5分)

Firebase Firestoreを利用したiOSアプリをCatalystに対応してリリースするまで

かっくん fromkk
WWDC 2018でmacOS Mojaveの一部のアプリケーションにUIKitをmacOSに対応したアプリケーションが搭載されることが発表されました。
さらに、翌年のWWDC 2019にてその機能が開発者向けに「Project Catalyst」として公開されました。
Catalyst対応はXcodeでチェックを一つ入れるだけで簡単にビルドをすることが可能です。
しかし、Firebase Firestoreを利用しているプロジェクトではうまくビルドができませんでした。
原因の例をあげると、
- 何故かCatalystの時だけTeamの設定が必要なライブラリが現れる
- Catalystに対応していないライブラリがある
- そもそもCatalystに対応していない機能がある
などです。
それらの対応をしたり機能のハンドリングをして、ようやくビルドができていざリリースしようとすると今度はArchiveに失敗します。
それでもリリースはしたかったのでFirebaseなどのGitHubのIssueを眺める日を過ごしていると、少しずつ解決の糸口が見え始め、最終的にはリリースすることができました。
本トークでは上記のようなトラブルに見舞われながらもなんとかリリースに漕ぎ着けるまでをご紹介しFirebase Firestoreを利用したアプリケーションのCatalyst化のリリースの方法をご紹介します。
他イベントOK レギュラートーク(20分)

iOSには無いmacOS独自機能をCatalystで実装する

かっくん fromkk
これまではmacOSのアプリケーションを開発しようと思うとAppKitというUIKitとは異なるframeworkを利用する必要がありiOSアプリの開発とは勝手が異なりました。​
そんな中WWDC 2018でmacOS Mojaveの一部のアプリケーションにUIKitをmacOSに対応したアプリケーションが搭載されることが発表されました。
さらに、翌年のWWDC 2019にてその機能が開発者向けに「Project Catalyst」として公開されました。
Catalyst対応はXcodeでチェックを一つ入れるだけで簡単にビルドをすることが可能です。
しかし、macOSらしいアプリケーションを作ろうと思うとすべきことが色々とあります。
WWDCでもサイドバーのUIをmacOSらしくする方法などが紹介されていましたが、WWDCで紹介されなかった機能がいくつもあります。
CatalystにおいてiOSには無い機能として「メニュー」、「Touch Bar」、「Toolbar」があげられます。
本トークではCatalystに対応した2つのアプリのリリース経験とCatalystに関する本を執筆した内容を基に、
対応方法の基礎から、先述したメニューやTouch Bar、Toolbarへの対応方法をご紹介します。
2
他イベントOK 原稿(2ページ)

iOSアプリ開発あるある4コマ

uhooi the_uhooi
iOSアプリ開発でよくあること(俗にいう「あるある」)を4コママンガでめちゃくちゃ面白く表現します。

【運営の方へ】
スベる可能性が高いので、紙面が余ったらご採択くださいw
3
他イベントOK レギュラートーク(20分)

Step to the stage of Conference ~スピーカーとして立つためのCfP Tips~

フレディ ___freddi___
皆さんはカンファレンスで、スピーカーになりたいとは思いませんか?

カンファレンスにスピーカーとして参加することは楽しいです!好きなことについて、国内外の多くのエンジニアの前で話すことはとても興奮します。それだけではなく、他のすごいスピーカーとディナーを食べながら仲良くなり、議論したり‥。普通のカンファレンスの参加だけでは体験できないことが多く、一度登壇したら二度とプロポーザルを出さずに参加できなくなります。私はtry! Swift Tokyo、NYCでの登壇を通じ、それらの楽しさに目覚めました。

しかし、CfP (Call for Porposal) への応募は難しく感じてしまいます。興味や憧れがあっても「応募できるほどのiOS/Swiftの知識やバックグラウンド、技術力がない」と思い、やめてしまうかもしれません。自分の伝えたいことをうまく表現できないような、もったいないプロポーザルの書き方をしてしまうかもしれません。色々な面でCfPへの挑戦って心配ですよね?

このトークでは、それらの心配を払拭することを通じて、採択される可能性が十分にあるプロポーザルを作る方法の考察について話します。具体的には、

- あなたの今持っているiOS/Swiftの知識・技術をプロポーザルに落とし込むには?
- 「聞き手の体験」によりそうプロポーザル/ トーク内容を作るには?
- あなたが伝えたいことを「聞き手が興味を持つ内容」に昇華させるには?
- 僕が採択されたプロポーザルを書くときに「気をつけた/ 考えた/ 気づいたこと」

これらのポイントを深堀りしていき、採択されるプロポーザルに必要なことについて一緒に学んでいきます。

このトークを聞いてプロポーザルの書き方を学び、あなたも次のiOSDCのステージに立って好きなことを広めてみませんか?
3
他イベントOK 原稿(8ページ)

GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス

uhooi the_uhooi
※本原稿は、同様のタイトルで出したトークの原稿版です。

みなさん、iOSアプリ開発でCIを行っていますか?
なかなかCI環境を構築する時間が取れず、行っていない人も多いと思います。

でもご安心ください!
iOSアプリのCI環境は、どのような規模や種類のアプリでもだいたい同じです。
一度構築すれば他でも使い回せます。

本原稿ではFastlaneやCIサービス独自の機能をできる限り使わず、スクリプトベースでCI環境を構築する方法を紹介します。
そのため、どのようなCIサービスを使っていても取り入れやすいです。

【目次】
・ライブラリのセットアップ・ビルド・単体テストを実行するスクリプトの作成(Makefile)
・ビルド・単体テストを実行するCIの構築
・★キャッシュを使ってCIの実行時間を短縮する
「★」はGitHub Actions独自の機能を使う

【想定する読み手】
・iOSアプリ開発でCIしたことがない人
・CI環境の構築に苦戦している人

【ゴール】
・CIしたくなる
・CIの意味とメリットがわかる
・GitHub ActionsでiOSアプリをCIできる
・CIサービスにかかわらずiOSアプリをCIできる

【使っているツール・ライブラリ】
本原稿では以下のツールやライブラリを使います。
使っていなくても応用できるように説明しますが、知っていると原稿を理解しやすいです。
・Mint
・Bundler
・Carthage
・CocoaPods
・XcodeGen
・xcpretty

本原稿を読んで、実際にCI環境を構築してくださると嬉しいです!
4
他イベントOK レギュラートーク(40分)

GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス

uhooi the_uhooi
みなさん、iOSアプリ開発でCIを行っていますか?
なかなかCI環境を構築する時間が取れず、行っていない人も多いと思います。

でもご安心ください!
iOSアプリのCI環境は、どのような規模や種類のアプリでもだいたい同じです。
一度構築すれば他でも使い回せます。

本トークではFastlaneやCIサービス独自の機能をできる限り使わず、スクリプトベースでCI環境を構築する方法を紹介します。
そのため、どのようなCIサービスを使っていても取り入れやすいです。

【アジェンダ】
・CIの概要とメリット
・ライブラリのセットアップ・ビルド・単体テストを実行するスクリプトの作成(Makefile)
・ビルド・単体テストを実行するCIの構築
・★キャッシュを使ってCIの実行時間を短縮する
・★静的解析(SwiftLint)を実行するCIの構築
「★」はGitHub Actions独自の機能を使う

【想定する聞き手】
・iOSアプリ開発でCIしたことがない人
・CI環境の構築に苦戦している人

【ゴール】
・CIしたくなる
・CIの意味とメリットがわかる
・GitHub ActionsでiOSアプリをCIできる
・CIサービスにかかわらずiOSアプリをCIできる

【使っているツール・ライブラリ】
本トークでは以下のツールやライブラリを使います。
使っていなくても応用できるように説明しますが、知っているとトークを理解しやすいです。
・Mint
・Bundler
・Carthage
・CocoaPods
・XcodeGen
・SwiftLint
・xcpretty

本トークを聞いて、実際にCI環境を構築してくださると嬉しいです!
2
他イベントOK LT(5分)

みんなもっとCI/CD回して!お願いだから!

uhooi the_uhooi
みなさんお願いだからもっとCI/CDを回してください!!!

【CIのメリット】
・リモートリポジトリ内のコードをビルド・テスト・静的解析することで、アップロードされているコードをきれいに保てる
・自動で実行されるので、手間がかからず継続的にコードのきれいさが保証される

【CDのメリット】
・ボタン1つでアプリがビルドされ、TestFlightやアプリ配布サービスにアップロードされる
・CD用のサーバーでビルドされるので、誰かのローカル環境に依存しない

CI/CDのメリットについてだいたい述べたので、ここまで読んで理解できた方は本トークを聞かなくても問題ありません。
本トークではこれらのメリットに感情を乗せ、よりみなさんがCI/CDを回す気になるよう話します。
1
他イベントOK レギュラートーク(20分)

テストコードはじめの一歩

uhooi the_uhooi
「うちのプロジェクト、テストコードはないんです」
「テストを書く時間がなくて」

勉強会の懇親会でよく耳にする言葉です。
技術力があり、アーキテクチャや設計パターンを駆使して実装している人でも、テストコードを書いていないことが多いです。

なんてもったいない!
MVCやMVVMなどのアーキテクチャを適用する理由は「テストを書きやすくするため」だと言っても過言ではありません。
設計までできたらあと一歩、テストコードを書いて効率よく品質を担保しましょう。

※本トークでは、XCTestを使ってSwiftで単体テストのコードを書きます。

【アジェンダ】
・テストコードを書くメリット
・テストしやすいメソッドの作り方
・テストクラスの分け方
・テストメソッドの命名と分け方
・テストメソッドの構成(Arrange-Act-Assert)

【想定する聞き手】
・iOSアプリ開発で単体テストコードを書いたことがない人
・他の人が読める単体テストコードを書くのが難しいと感じている人

【ゴール】
・単体テストコードが書きたくなる
・iOSアプリ開発で他の人が読める単体テストコードを書けるようになる

本トークを聞いて、明日からテストコードを書くのが楽しくなると嬉しいです!
3
他イベントOK LT(5分)

新機能をリリースするたびに不具合を連発していたアプリを全くの不具合ゼロでリリースできるようになるまでのワークフロー

tamappe tamapppe
「おーい。ここなんか不具合ぽく見えない?」
POやディレクターの人からこんな風に声を掛けられるとビクってなってビビりませんか?
「イケてる自信があったんだけどなぁ。そんなもん気のせいじゃないの・・・?」
と心の中でそう思いながら心臓バグバグになりながら一緒に挙動を確認するとやっぱりなんかおかしい。
そして、やっぱりバグでした。

アプリ開発に慣れてきてもバグ報告は開発者にとって切っても離せない存在だと思います。
しかも開発にバグは付き物です。
私も当時ビクビクしながら挙動確認していました。皆さんもバグ報告を聞いてビクッとしませんか?

そんなチームというか私が一年後に新機能の追加開発でディレクターやユーザーからバグ報告やデグレ報告が一切来なくなりました。

工夫したのは、テストフェーズに移る時に開発者目線で「テスト項目書」を作るようにしたことです。
ディレクターから指示される仕様書を元にして開発者目線でテスト項目書を作って運用するようになって
劇的にテスト後やリリース後の不具合報告の件数が一気に減りました。

開発者にとってはテスト項目書の作成はとても嫌な作業だと思います。少なくとも私は苦手でした。
ですが慣れてくるとこれも一種のプログラミングの作業と変わらないなと思えてきました。
本セッションでは開発者目線のテスト項目書の考え方と作り方、それを通してなぜ不具合ゼロに持っていけるのかについて話して
皆さんの悩みの助けになれればと思います。

## 聞いてほしい対象者

- テストなんてテスターに任せればいいじゃないかと思っている人
- 自動化テストを導入したいけど、そこまでテストにコストを掛けられない人
- 仕様書の通りに実装したはずなのに、検討漏れをよくしてしまう人
- あんまりバグ報告を聞きたくない人
1
2019 スポンサー 2019〆切後 資料請求
オンライン対応未決定 削除予定 オンライン対応検討中 要ロゴ 要PR 要支払
仮採択 採択しない スピーカー採択
仮採択(原稿) 採択済 採択しない 仮採択 要審議 ニッチ企画? LT向き加点