iOSDC Japan 2020 プロポーザル一覧

他イベントOK LT(5分)

try! Swift Tokyo Meetupの裏側と勉強会の運営について

ろく 66nylon_y
今年の1月にtry! Swift Tokyo 2020の事前勉強会であるMeetupを開催しました
実はこのMeetup、try! Swift本体の運営チームとは別の有志によるメンバーで集まって開催した勉強会だったんです
参加者のターゲット層の検討やトピックの選定など、開催までにメンバーと様々な議論をしました
今回はその経緯をお伝えしつつ、勉強会の運営ってどんなことをしているのかを紹介できればと思っています

iOSアプリ開発に関する勉強をする際に、実は勉強会を開いてみるという手があるんだ!という第三の手段を提案できたら嬉しいです
難しい話はしない予定なので、コーヒーブレイク感覚で聞いてもらえればと思います
3
他イベントOK LT(5分)

iPhone SE (1st generation)とAuto Layoutで殴り合う

417.72KI 417_72ki
iOS14でもiPhone SE(1st generation)のサポートが確定しました。
つまり開発者は引き続き4inchの画面サイズに対応しなければなりません。
4.7inch以上がメインとなり、画面の要素数も増えている今小さい画面に対応するのはとてもつらいです。

よくある対処法として、4.7inch以上の端末ではスクロールさせずそれ未満の画面サイズの時スクロールさせるようにすることが要求されがちです。

本トークでは、AutoLayoutを駆使してコードに手を入れることなくxib/storyboardのみで小さい画面に対応する手法をご紹介します。
4
他イベントOK レギュラートーク(20分)

新規機能開発からモジュール分割を始めてみる

Ryo Izumi izm256
最近のモバイルアプリは、1つのアプリ内で多彩な機能を持つものが一般的となってきています。
機能が増えることによってコードベースは肥大化し、ビルド時間の増加や設計の複雑化へと繋がります。

そこでマルチモジュールを採用することで、差分ビルドによるビルド時間の短縮や、モジュール間が疎結合となることでより堅牢な設計への期待が高まります。

しかしながら、長年運用しているサービスにマルチモジュールを導入しようとしても、
どこからモジュールを切り出して良いのか分からない、
既存コードの結合度が高くモジュールへの分割が難しいなど、
導入への障壁が様々考えられます。

また、サービス運営をしていく上で新規機能の開発を止めることも許されず、リファクタだけに工数を割くことも容易ではありません。

そこで我々は、新規開発する機能をモジュールとして切り出すことでマルチモジュール化への第一歩を踏み出すということを実践しました。
このトークでは、7年以上続くアプリの新規機能開発からマルチモジュール化を実践していく中で感じたメリット、デメリットや今後の展望についてお話します。
3
LT(5分)

In App Purchaseのこれからの在り方を考える

Yuki Yamamoto redryerye
6月にメールアプリHeyのアップデートをリジェクトしたApp Storeの審査についてアメリカのBasecamp社が公開した文書は多くのアプリ制作者が抱える「アップル税」の悩みを凝縮したものだと言えます。
この文書はメディアに大きく取り上げられ、議論の必需性を再提起しました。

業務でIAPについて悩んだ時期とこの一連の事件がちょうど重なり、Appleのスタンスと今までの事例について根深くリサーチする機会がありました。
このトークでは以下の点を抑えながら現在アプリに求められているガイドラインをおさらいすると同時に、理想のプラットフォームの在り方について考えます。
- 既存サービスの実例
- 私が実装した解決方法
- SaaSと共存するためのApp Sore Review Guidelines
1
他イベントOK レギュラートーク(20分)

自動テストの成果物をより活用して継続的に改善できるようにする

平田 敏之 tarappo
自動テストの成果物をどこまで利用していますか。
CI/CDサービスを通して、自動テストの成否をSlackなどを通してフィードバックするといったことはよくやっているかと思います。

自動テストがあるのであれば、その成果物をより活用するにこしたことはありません。


自動テストで得られる成果物としては、Xcode 11からResult Bundlesという形でまとめられました。
この成果物を活用することによりテストの成否だけでなく、テストログやテスト時に添付した画像やログなど、より細かい情報をフィードバックできるようになります。

また、プロダクトコードの状態をGitHub API(Commit Status APIやChecks APIなど)や外部サービスを利用することで継続的に収集し、その収集した情報を利用することができます。



これらの情報を活用することで、開発者だけでなく、プロダクトに関係するメンバーにも定期的にフィードバックすることで、それぞれのメンバーが知りたい現状のプロダクトの状態がわかるようになります。


本トークでは、継続的にこれらの自動テストの成果物をどのように収集し、活用できるように整えたか。
そして、実際のプロジェクトのフローの中で「(主に)だれにたいして」「どのような情報を」フィードバックしたか、そしてその結果としてどのように継続的な改善活動に繋がったかについて話していきます。
4
他イベントOK LT(5分)

テストデータの準備から始める開発効率化(LT版)

埴生孝慈 gaussbeam
現代のアプリ開発において、その品質担保にユニットテストは欠かせない。
しかし、ユニットテスト自体はアプリの価値を直接高めるものではないため、極力時間を掛けずに作成したい。
そこで浮かぶ問題の1つが、テストの実行に都合が良いテストデータをいかに簡単に準備するか、である。

本トークでは、テストデータを準備しやすくするための手法や、そのためのプロジェクトファイルの構築アプローチについて説明する。
合わせて、テストデータの準備よって副次的に得られる機能開発自体の効率化について述べる。
1
他イベントOK レギュラートーク(20分)

xctemplateも共通化できる。そう、Symbolic linkを使えばね

417.72KI 417_72ki
xctemplateはXcodeでファイルを新規作成する際に使用されるテンプレートファイルで自作することができますが、
テンプレート作成時にオプション(ex: xibで作るかstoryboardで作るか)を付けてそれに応じた出し分けをしようとすると一気に面倒になります。

また、同じようなテンプレートファイルが乱立し管理がとても大変です。

実はこの問題、Symbolic linkを使えば解決できるんです。

本トークでは、xctemplateの仕様と問題点を紹介し
実際にSymbolic linkを使ったxctemplateの作り方と現在関わっているプロダクトでどのように活用しているかをお伝えします。
他イベントOK LT(5分)

xctemplateも共通化できる。そう、Symbolic linkを使えばね

417.72KI 417_72ki
xctemplateはXcodeでファイルを新規作成する際に使用されるテンプレートファイルで自作することができますが、
テンプレート作成時にオプション(ex: xibで作るかstoryboardで作るか)を付けてそれに応じた出し分けをしようとすると一気に面倒になります。

また、同じようなテンプレートファイルが乱立し管理がとても大変です。

実はこの問題、Symbolic linkを使えば解決できるんです。

本トークでは、実際にSymbolic linkを使ってxctemplateを使いまわしした例についてお話します。
1
他イベントOK レギュラートーク(20分)

アプリのパフォーマンス指標とKPI指標の関係

「アプリのパフォーマンスを上げることでプロダクトのKPI改善に貢献したい」
やりたいことはこれに尽きます。
例えばアプリの起動時間を短縮することで新規ユーザーのリテンション率を改善するとか。
(他にfirstViewの表示時間を短縮してアプリの削除率を減らすなど。。)
できることはたくさんありますが、これをやるためには仮説を立てる必要があり、
さらには根拠になるアプリのパフォーマンス指標とKPI指標の関係性を突き止めないといけません。

このトークでは実際ECアプリで
何を仮説として立て、KPI指標を上げるためにパフォーマンスをどう改善したか、
そしてその結果を共有し、「アプリのパフォーマンス指標とKPI指標の関係」についてもう一度考えるきっかけを提供します。
1
他イベントOK LT(5分)

アプリのパフォーマンス指標とKPI指標の関係

「アプリのパフォーマンスを上げることでプロダクトのKPI改善に貢献したい」
やりたいことはこれに尽きます。
例えばアプリの起動時間を短縮することで新規ユーザーのリテンション率を改善するとか。
できることはたくさんありますが、これをやるためには仮説を立てる必要があり、
さらには根拠になるアプリのパフォーマンス指標とKPI指標の関係性を突き止めないといけません。

このトークでは実際ECアプリで
何を仮説として立て、KPI指標を上げるためにパフォーマンスをどう改善したか、
そしてその結果を共有し、「アプリのパフォーマンス指標とKPI指標の関係」についてもう一度考えるきっかけを提供します。
他イベントOK レギュラートーク(20分)

継続的にアプリのパフォーマンスを計測する

kariad kariad_uu
ユーザーにアプリを快適に使ってもらうためには、機能が動くだけでなくアプリのパフォーマンスも重要です。
端末が熱くて持てない、動作がカクカクするなど快適に動かないアプリは、ユーザー体験を著しくそこなってしまい、ユーザの離脱にもつながっていきます。

このような事態にならないためにも、アプリのパフォーマンスの計測を継続的におこない、
問題がある箇所を見つけて適切に対処すること重要です。

iOSアプリ開発ではInstrumentsなどを用いてパフォーマンスを計測することができますが、手動で計測しつづけるのは困難です。
今回は自分たちでCPU使用率と端末温度の計測を継続的に実施する仕組みをInstrumentsを用いて作成しました。

本トークでは、実際にiOSアプリケーションのCPU使用率と端末温度を継続的に計測する仕組みをどのような形で実現したかお話します。
2
他イベントOK レギュラートーク(40分)

継続的にアプリのパフォーマンスを計測する

kariad kariad_uu
ユーザーにアプリを快適に使ってもらうためには、機能が動くだけでなくアプリのパフォーマンスも重要です。
端末が熱くて持てない、動作がカクカクするなど快適に動かないアプリは、ユーザー体験を著しくそこなってしまい、ユーザの離脱にもつながっていきます。

このような事態にならないためにも、アプリのパフォーマンスの計測を継続的におこない、
問題がある箇所を見つけて適切に対処すること重要です。

iOSアプリ開発ではInstrumentsなどを用いてパフォーマンスを計測することができますが、手動で計測しつづけるのは困難です。
今回は自分たちでCPU使用率と端末温度の計測を継続的に実施する仕組みをInstrumentsを用いて作成しました。

これらの仕組みを用意するために、CI/CDサービスをどうするか、どのように操作をし続けるかなど、様々な課題がありました。
また、運用していく中では、Instrumentsのデータの見づらさや想定外のクラッシュなどいくつもの問題が発生しました。

本トークでは、実際にiOSアプリケーションのCPU使用率と端末温度を継続的に計測する仕組みを作成し、運用している環境をどう実現したかに加えて「乗り越えた課題」、そして「残る課題と今後」についてより詳しく話をします。
2
他イベントOK レギュラートーク(20分)

iOSではじめるWebAR

ikkou ikkou
ARKitによりiOSにおけるWebAR表現が豊かなものになりました。

ネイティブアプリに比べると制限のあるWebARですが、iOSのバージョンアップに伴いできることも少しずつ増えています。

iOS 12.2でモーションセンサーまわりに大きな制限が入り、もはやiOSにおけるWebARは終わったのか…と悲しみに明け暮れた日もありましたが、iOS 13ではあるべき姿として帰ってきました。しかし、その結果としてiOSのバージョンごとの差異を吸収する対応が必要になっています。

本セッションでは、そんなiOSにおけるWebARの変遷を振り返りながら、時にAndroidにおけるWebARと比較しつつ、具体例を交えてiOSのWebARを紹介します。
3
他イベントOK レギュラートーク(20分)

オーディオ波形データ自由自在

なめき ちはる Ridwy
iPhoneは音楽プレイヤーであるiPodを先祖に持ち、実は音楽的な音の処理がとても得意です。近年のコアの性能の上昇に伴い、複雑な音声処理も軽々とこなせるようになりました。まさに自由自在と言ってよいでしょう!
このトークではオーディオ波形データから情報を取り出したり加工したりを、実際に「聴いて」いただきながら、iPhoneの持つポテンシャルの高さを感じて貰えればと思います。あなたの声が○○に?波形の加工自体もとても楽しいですよ!
3
他イベントOK レギュラートーク(20分)

J2ObjC を使って Java 資産を iOS 開発で使ってみた

うるし uakihir0
J2ObjC とは Java で書かれたコードを Objective-C に変換するコンパイラです。

マルチプラットフォーム開発として、ロジックのみを共通化する仕組みとしては、Kotlin Multiplatform Project (Kotlin/MPP) などが有名ですが、Kotlin/MPP はまだライブラリが充実しておらず、共通ロジックを書く上で他言語にはあるようなライブラリを用いて開発したい場合に、障壁が多く難しいといった課題があります。

J2ObjC では Java のコードを Objective-C に変換して用いることができるため、既存の Java の資産を用いて開発することが可能です。もちろん各種 Java の OSS ライブラリを (条件はありますが) 使う事が可能であるため、比較的自由度が高い共通ライブラリを作成することが可能です。

私の個人開発のアプリでは、共通ロジックが非常に複雑で、それを構成するために様々な既存のライブラリが使用できることが予め分かっていました。そのため、マルチプラットフォーム開発における技術策定では、いかに共通ライブラリを既存のライブラリを用いて簡潔に記述するか、が重要な要素として存在しており、J2ObjC を採用し、実際に iOS アプリをリリースまで行いました。

トークでは、採用した理由から、リリースまでの体験談、またその過程で得られた知見についてお話します。


# 予定している内容

- J2ObjC を採用した理由
- J2ObjC 環境構築
- 発生した問題とその対処

# 対象

マルチプラットフォーム開発に興味があり、Java資産を持っており、めげない心を持っている iOS/MacOS 開発者
1
他イベントOK レギュラートーク(20分)

無料トライアル施策のしくじりから学ぶサブスクリプション構成 ベストプラクティス

皆さんiOSのサブスクリプションプランの無料トライアルを実施したいと言われたことはありませんか?
Appleは「お試しオファー」という仕組みを提供しており、一見簡単に実装できそうに思いますが、そこにはいくつもの落とし穴があります。

本トークでは僕自身が実際に無料トライアル施策を実施し、盛大にしくじった経験から叶えることのできる / できない要件、サブスクリプションプラン構成のベストプラクティスをお話しできればと思います。

- Appleの提供する無料トライアルの仕組み知ってますか?
- プランの購入導線全て知ってますか?
- Appleの「お試しオファー」で叶えることのできる / できない要件
- 今回の施策でのしくじりポイント
- しくじりから学ぶべきポイントとベストプラクティス
1
他イベントOK レギュラートーク(20分)

エラーアーキテクチャ設計について考える

きちえもん iKichiemon
みなさんは「エラー」の取り扱いをどうされていますか?

APIからのエラーレスポンス、予期せぬ操作によるエラー、JSONパースエラー、などなど、色んなところで発生するエラーを適切にハンドリングするのは難しいと感じています。

例えば、クリーンアーキテクチャなどのレイヤーが複数存在しているような場合、レイヤーをまたいだときのエラー変換がボイラープレート化し、ユースケース個別のエラー処理に悩むことが多いです。

トークでは、弊社のアプリ (iOS, Android) を事例として、実際に試行錯誤した経験談、また、その過程で得られたエラーアーキテクチャの設計への知見ついて、お話しします。
5
他イベントOK レギュラートーク(40分)

iOS のキーボードと文字入力のすべて

Yoshimasa Niwa niw
iOS の UIKit は一見、文字入力のような基本的なことはとても簡単に行えるように思えます。

しかし、一度でも文字入力を扱ったことのある方は、その難しさと期待しない動作に頭を悩ましたことが一度はあると思います。

例えば、iOS のキーボードが文字入力に被ってしまう、キーボードの位置がずれる、変更したはずの文字が反映されない、日本語が入力できない...
実のところ、一般的に文字入力はとても複雑なユーザーインタラクションであり、さらに iOS はキーボードにも様々な種類があるため、一見すると正しそうな実装であっても、ドキュメントに記載のない様々な挙動により期待しない結果に終わってしまうことが多々あります。

このセッションでは、ほぼほとんどの方が経験する iOS の文字入力に関する些細な問題からとても大きな難題について、世界中で多くのユーザーが使う iOS アプリ開発や、iOS のキーボードフレームワーク「KeyboardGuide」などの開発など、これまで長い間蓄積してきた経験に基づいて、実際におこった問題を実例を踏まえて、その原因や対策を検証していきたいと思います。

対象とする方:
- iOS アプリ開発の経験がある中・上級者
- `UITxtView` に昔年の思いがある方
- `UIKeyboardWillChangeFrameNotification` などに昔年の思いがある方

前提とする知識:
- UIKit
- Foundation
- Unicode
10
他イベントOK レギュラートーク(20分)

macOS Big Sur 時代の Catalyst

宇佐見 公輔 usamik26
iPad アプリをベースに Mac アプリを開発できる Catalyst。画期的な技術ですが、一方で iPad と Mac とではやはり異なる側面が多く、Catalyst アプリは Mac ネイティブのアプリとは少し違うものという印象もありました。

ところが、最近の iPadOS の進化、macOS Big Sur の登場によって、iPad と Mac の差は急速に埋まりつつあります。Catalyst を使って iPad と Mac の両方のアプリを開発することは、十分に考えうる選択肢になっています。

このトークでは、Catalyst について改めて知り、iPad と Mac の両方に対応するアプリの開発について考えたいと思います。
4
他イベントOK LT(5分)

着信時氏名表示させたいエンジニア vs 簡単には着信時氏名表示できない電話番号 (iOS13対応版)

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

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

本セッションでは、どういった番号が簡単に着信時表示できないのかをご紹介するとともに、Speakerboxという、かつて公開されていたサンプルアプリを使って検証を行った際の苦闘の記録、さらにはiOS13以降で注意すべき点についてもご紹介します。
3
2019 スポンサー 2019〆切後 資料請求
オンライン対応未決定 削除予定 オンライン対応検討中 要ロゴ 要PR 要支払
仮採択 採択しない スピーカー採択
仮採択(原稿) 採択済 採択しない 仮採択 要審議 ニッチ企画? LT向き加点