iOSDC Japan 2019 プロポーザル一覧

iOSDCルーキーズLT(5分)

2つのアプリを2週間でAppStoreとPlayStoreにリリースするためにしたこと

usayuki usayukisan
2つの側アプリを2週間でリリースするために行ったことを紹介します
※下準備にかかった時間は含まれません
レギュラートーク(30分)

テストケースで Ambiguous Layout を発見する

tarunon tarunon
我々の開発において「アプリケーションのパフォーマンス」というものは非常に重要であるにも関わらず、優先順位は常に最下位に位置づけられがちです。顧客の体験を最も確実に向上させる手段の一つが、パフォーマンスの改善なのですが、我々は常に新規機能を開発しています。
メモリリークやAutolayoutのエラーというものは一度発生すると永劫そこに留まり、アプリケーションのパフォーマンスを蝕んでいきます。
どのようにこれらを防ぐのでしょうか。コードレビューで発見できるでしょうか。或いは発生したそれを修正するための時間を確保出来るでしょうか。
これらの問題は、コンパイラでは発見出来ません。コンパイラで発見できないものを防ぐ最も賢い手段の一つは、テストケースを書くことです。コードレビューではありません、それでは防げない。

メモリリークに関しては"try! swift 2019"で伝説の失敗に終わった私のデモとともに追放されました。(されたはずです)
今回は最高峰の黒魔術を以て、我々の世界からAmbiguous Layoutを駆逐します。ご期待下さい。
2
技術パッション共有トーク(60分)

Kubernetesではじめる「ネイティブ」アプリケーション開発

laiso laiso
iOSエンジニアにとってこの先最も重要な技術はなんでしょうか?

そうだね、Kubernetes だね。

Kubernetes はDocker などでコンテナ化されたソフトウェアを扱うための統合的なツール群・プラットフォームです。コンテナ技術の一角として、近年急速に発展して注目を集めています。

コンテナ技術の発展の背景にはアプリケーション開発の複雑化があります。そしてコンテナ技術の仕組みや使い方を知ることは、今後より大規模化していくiOSアプリケーションのソフトウェアアーキテクチャを考えていくことになる私たちの参考にもなるはずです。

このトークではKubernetesとサーバーサイドSwiftによるアプリのバックエンド開発ガイドを通して、iOSエンジニアの皆さんへコンテナ時代のサーバーサイド開発のたのしさについてお伝えします。
3
レギュラートーク(60分)

iOS/Android両OS対応 アプリ内課金とアプリ決済・ApplePay&AndroidPay導入入門

yutaabe200 yutaabe200
当トークではiOS/Androidにアプリ内課金なりアプリ決済導入なりの手法に関して、
・これから実装しようと考えている方
・実装にハードルを感じている方
・iOS(またはAndroid)はわかるが、Android(またはiOS)はどうなっているか興味のある方
などの方を対象に「課金・決済」の判断から開発・導入、運用に関してわかった気になれることを目的としたトークです。

アプリで決済周りの導入を行う際「アプリ内課金」か「(他決済サービスによる)アプリ決済」を検討するかと思います。
In-App Purchasesでは「アプリ内のデジタルコンテンツ」に限られており、これから有料化しようとしている課金対象がそれに該当するかどうか判断しなければなりません。これらは単純な「ゲームのコイン」や「広告表示の停止」などであれば迷うこともないかと思いますが、時には判断が難しい場合もあります。
さらにIn-App Purchasesに守備範囲外だったものに対して決済導入を考えるとその時点でかなりのハードルを感じる開発者も多いでしょう。

このトークではまずiOS/Android両OSのIn-App Purchasesの概要・種類・注意点を事例と実装を用いながら説明し、アプリ決済を導入する際の決済サービスの紹介・実装、さらにはApplePay・AndroidPayの活用・実装を紹介します。
3
レギュラートーク(30分)

「型を使う」の意味について考えよう ~型安全と心理的安全を求めて~

shiz stzn3
Swiftは型を持つ言語です。
私たちはSwiftを使っている限り型を必ず使用しています。

しかし、型をいつも意識してコードを書くことはあまり多くないのではないでしょうか?

私はこれまでに仕事で複数の言語を扱ってきましたが、
型というものを当然あるものとしてあまり意識してきませんでした。

しかし、iOSエンジニアとして働くために
Swiftという言語と向き合う時間を増やしていく中で
型に関しての意識が強くなり
型を意識して使うことでより安全に安心して開発を進めることができると思うようになりました。

今回は

「型ってなんだろう?」
「型を使うことで何が良いんだろう?」
「型を意識したコードの書き方ってどういうものがあるんだろう?」

などについてお話ししたいと思います。
※コンパイラの話は出てきません。

私ようにこれまで型について何となく使っていたという方が

「型があるって良いな」
「型をもっと意識して使ってみよう」

と思えるきっかけになり
より安全に安心した開発を進めるための一助になりましたら幸いです。
1
レギュラートーク(60分)

実践 Auto-renewable subscriptions

ロクネム _rockname
iOSにおけるApp内課金には以下の4つの種類が存在します。
・消耗型(Consumable)プロダクト
・非消耗型(Non-consumable)プロダクト
・自動更新サブスクリプション(Auto-renewable subscriptions)
・非更新サブスクリプション(Non-renewable subscriptions)

本セッションではそのうちの一つ、Auto-renewable subscriptionsと呼ばれる、定期的に新しいコンテンツが配信される種類のApp内課金について、ハマりポイントや実装前に知りたかったようなノウハウを織り交ぜて説明します。
また、Auto-renewable subscriptionsを導入したプロジェクトではClean Architectureを採用しており、StoreKit frameworkの実装もRxSwiftでラップし、アーキテクチャに適用して実装しています。このような、実装に落とし込む際の工夫についても詳しくご紹介します。

【アジェンダ】
1. In-App Purchasesについて
2. Auto-renewable subscriptions導入の経緯
3. Auto-renewable subscriptionsの大まかな処理の流れ
4. StoreKit frameworkの各メソッド定義と実装方法
・Singletonパターンによる一般的な実装
・RxSwiftを用いたCleanArchitectureによる実装
5. Sandboxテスターによる動作確認方法
6. サーバーサイドの設計
・状態更新通知
・Sandboxレシートのハンドリング
・Grace Periodの実装
7. リジェクトについて気をつけたいポイント
1
レギュラートーク(30分)

詳解 Auto-renewable subscriptions

ロクネム _rockname
iOSにおけるApp内課金には以下の4つの種類が存在します。
・消耗型(Consumable)プロダクト
・非消耗型(Non-consumable)プロダクト
・自動更新サブスクリプション(Auto-renewable subscriptions)
・非更新サブスクリプション(Non-renewable subscriptions)

本セッションではそのうちの一つ、Auto-renewable subscriptionsと呼ばれる、定期的に新しいコンテンツが配信される種類のApp内課金について、実際に実装する上でハマったことや実装前に知りたかったようなノウハウを織り交ぜて説明します。

【アジェンダ】
1. In-App Purchasesについて
2. Auto-renewable subscriptions導入の経緯
3. Auto-renewable subscriptionsの大まかな処理の流れ
4. StoreKit frameworkの各メソッド定義と実装方法
5. Sandboxテスターによる動作確認方法
6. サーバーサイドの設計
・状態更新通知
・Sandboxレシートのハンドリング
・Grace Periodの実装
7. リジェクトについて気をつけたいポイント
レギュラートーク(30分)

広告配信処理のiOSアプリ機能としての実装

樋口雅拓 mahiguch1
一般的に広告はサーバから最適なものを取得し、アプリではそれを表示しています。本件では最適な広告を取得する処理をアプリ機能として実装した事について共有します。
メディアアプリの開発は簡単で退屈と思われがちです。それは多くの機能をサーバ側で実装し、アプリでは表示するだけのように見えるためです。しかし、アプリ側に機能を実装することで、より良いユーザ体験を届けることができます。

# 具体的にどんな内容を話すか
広告システムは、入稿、配信、計測、レポートの4機能で構成されています。これを順番に説明していき、アプリ機能として実装している配信と計測について以下の部分を重点的に話します。
広告は画面ごとに同じものが表示されているように見えますが、閲覧者ごとに違うものが表示されています。例えば真珠のネックレスの広告は「奈良県にいる宝飾品に興味がある50代女性」だけに表示されるよう設定されています。この制約条件の実装方法について話します。
また、Cellが表示された回数を代理店や広告主にレポートする必要があるため、計測の定義や実装について話します。

# 聴講者が得られるもの
広告メディアアプリについて理解が深まります。また、サーバ処理をアプリ機能として実装するモチベーションが湧きます。

# 聴講対象
* メディアアプリ開発は簡単で退屈だと思っている方
* メディアアプリに興味がある方
* アドテクに興味がある方
* サーバ処理をアプリ実装することでユーザ体験を向上させたい方
LT(5分)

Getting Started with Swift WebAssembly

kateinoigakukun kateinoigakukun
巷ではServer Side SwiftやSwift for TensorFlowが盛り上がっていますが、Swift on WebAssemblyにも大きな動きがありました。しかし、SwiftのWasm対応は、まだまだKotlin NativeやRustに遅れをとっている状態です。LLVMをバックエンドに採用しているSwiftならシュッと対応できそうですが、なぜここまで難航しているのでしょうか?
このトークではSwift on Wasmのランタイムがどのように実現されているか「軽く」お話しします。
2
LT(5分)

Swiftに初めてコントリビュートしようとした人の気持ち、みなさん知りたいですよね?

ひろん hironytic
2015年の冬にAppleがSwiftをオープンソース化してから、もう3年以上が経過しました。オープンソース化によって、私たち開発者は様々なメリットを受けられるようになりました。例えば、「不具合の原因を追いかけやすい」、「多くの声を反映した改善が行われやすい」、「仕様変更の議論が外から見えるのでそれに備えやすい」などが一般に言われています。しかし、もっと単純に「私たちだって参加できる」ということも大きなメリットのひとつです。

iOSDCに参加しているお祭り好きのみなさん、当然Swiftにだって参加したいですよね?

世の中には息をするようにSwiftにコントリビュートしている人たちもいます。では、そうでない人たちはどうすればいいでしょうか。後者の一人である私は、今年、Swiftに初めてコントリビュートしようとしました。本トークではその経験をみなさんに共有します。コントリビュートの内容そのものよりも、その過程で私はどんなことを考え、どんな気持ちでいたのかという部分に重点を置き、それをドキュメンタリー風にしてお届けします。
1
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時間もの時間が消し飛び、この世には「サマータイムが発生した」という「結果」だけが残るッ!!」
3
レギュラートーク(60分)

色の難しい話に負けない体づくり60分

しもとり S_Shimotori_pub
カラーコードとUIColorさえわかれば色の話は十分だと思っていませんか?残念ながら違います!私たちが色に関するガイドラインを覗いたとき、謎の数式と用語も私たちを覗き返してくるのです。そこから逃げ出して曖昧な理解のままアプリを作ったら、きっと使いにくいものになってしまうでしょう。

本セッションでは、知っておくと心強い色の知識をみなさんと一緒に確認していきます。
色の決まりや仕組みを理解することで、ドキュメントやガイドラインの意図を正しく掴むことにつながり、私たちが気をつけるべき点をしっかり抑えることができるようになります。小難しい話の並んだドキュメントももう怖くありません。
もちろん、色のお話はiOSやiPhoneだけのものではありません。他のアプリやスライド資料などを作るときにも役立ちます。読みにくいスライドで聴衆のみなさんをがっかりさせてしまった……ということがないように、この機会に色への意識を変えていきましょう!

【対象】

- RGBカラーコードまではわかるぞ!という方
- 発表資料の質をワンランク上げていきたい方
- ガイドライン中の謎の用語で手が止まっちゃう方
- 色に関する注意事項の丸暗記が苦手な方、卒業したい方

【取り扱うテーマ】

- で、コントラスト比って何でしたっけ?
- HIG Colorに載っている謎の虹色画像は何者?
- 色覚異常の方は何色の区別が苦手なんだっけ……?
- ダークモードっていうのが最近の流行りなの?なんで?
- イラレにiPhoneのスクショを配置したらヤバイ色になった助けて!

また、これらの問題の理解に必要となる定義や仕組みの説明、関連するガイドラインの紹介も行います。
3
iOSDCルーキーズLT(5分)

FirebaseでGrowth基盤を作っちゃお

giiiita giiiita_7
FirebaseにはCloudFireStore、CloudFunctionsなど開発面で便利な機能が多くある一方でアプリの成長面を支える機能も多数あります。

本LTでは、
Analytics機能に含まれるAudiencesに着目しアプリをグロースさせていく基盤をどのように作成していくかについて説明し
Cloud MessagingやA/BTesting機能などと連携することで実現できることについてお話します!

翌日から実際手を動かしてみようと思えるよう熱をあなたに届けます!
レギュラートーク(30分)

1リポジトリで類似したアプリを同時に複数開発するための設計・運用

matsuokah matsuokah_
1リポジトリで複数アプリを並行実装する旨味や課題、開発のスケーラビリティを考慮したプロジェクト構成の設計について話します

◯ 共通部分のEmbedded Framework化
 ▷ レイヤリングを意識してフレームワークを分けることで、抽象的な実装に近づけることができます。
 ▷ また、レイヤー毎に切り出すことで再利用性が高いフレームワークを設計することができます

◯ XcodeGenによるディレクトリベースの構成管理
 ▷ 共通部の実装とそれぞれの特殊部を共存できる構成管理にすることで、それぞれの開発の行き来がスムーズになります
 ▷ また、XcodeGenにより、iOSエンジニアの7人の並行開発が円滑になります

◯ Bitriseを用いたビルドの並列化とリポジトリの運用ルール
◯ 共通アセットと特異アセットの抽出と使える仕組みをSwiftGenで実現した話
◯ xcconfigのレイヤリング
◯ 共通実装の使い回しと特殊化
6
レギュラートーク(30分)

FirebaseとAlgoliaとStripeを使って1人でiOSアプリを作る方法

ここ1年以上すべてのiOSアプリをFirebaseで作っています。なぜならフリーランスとして受ける案件が全てスタートアップで、ミニマムに高速に作ることが求められるからです。そしてデザイン意外は全て僕1人で作ってきました。しかし、Firebaseだと検索機能が弱かったり、決済機能はないですよね。でも大丈夫!AlgoliaとStripeを組み合わせればLIKE検索もできるし、決済機能もつけれます。開発者はあなた1人だけで十分です。スタートアップのエンジニアや個人開発者必見のトークとなるでしょう。
4
LT(5分)

エンジニア系YouTuberになった件ww

昨年は「KBOY@筋肉エンジニア」として「ARKitのための3D算数」という発表をした僕ですが、なんと今年はYouTuberとなってiOSDCに帰ってきました。2019年1月からスタートしたエンジニア系YouTuberですが、どんな苦悩があって、どのように成長してきたのか?5分でまとめます。「KBOYのエンジニアTV」のチャンネル登録よろしくです。
レギュラートーク(30分)

環境設定をYAMLで管理したかったのでツールを自作してみた

417.72KI 417_72ki
「AdHocビルドでは検証環境向けたいからこのURL、Releaseビルドでは本番環境向けたいからこのURLをセットする」
「Releaseビルドとそれ以外でログの出し方を変えたい」
といった設定、皆さんはどうしていますか?
このセッションではこれらの設定をYAMLファイルで管理するアプローチと、それを実現するためにCUIツールを自作した話をします。
1
LT(5分)

はじめてのこんとりびゅーと ~OSSは怖くない!~

417.72KI 417_72ki
OSSへのContributeというと始めは気が引けるものです。
しかし業務でどうしても欲しい機能があったため、勇気を出して自分で実装してPRを出してみました。
その時の体験談をお話しします。
2
レギュラートーク(30分)

雰囲気でやっていくRxSwift

ひろん hironytic
全て熟知する必要はありません。雰囲気さえ掴めば自
然とRxSwiftが使えるようになります。本トークでは、
わたしが普段思い描いているRxSwiftの動作イメージを
かんたんなポンチ絵とともにゆるく共有します。それ
らは正確性よりもイメージを優先したものですが、み
なさんの理解をきっと助けます。さあ雰囲気でやって
いきましょう!

RxSwiftというオープンソースライブラリがあります。UIとデータのバインディング機構を持たないiOSプログラミングにおいて、MVVMアーキテクチャーを実現するためによく使われているライブラリであり、今さら?と思う人がいるくらいには普及してきたと言っていいでしょう。
しかし、手続き型プログラミングに慣れた人にとってRxSwiftのリアクティブプログラミングの考え方は取っ付きづらいこともあります。その原因は、何がどう動いているのかを想像しづらい点にあると思います。
RxSwiftの人気が出始めたSwiftがまだ2〜3の頃、データの流れるストリームを川に例える話をよく見かけました。私も当初はそのようなイメージで触り始めましたが、それでは引っかかる点もあり、現在は全く違ったイメージを持っています。
本トークではRxSwiftの初心者を対象に、私の持つRxSwiftの動作イメージを紹介します。「オブザーバーパターン」や「関数型プログラミング」といったキーワードは登場しません。プログラムの動作の雰囲気をゆる〜く解説します。
3
レギュラートーク(30分)

ダックタイピングでUserDefaultsをモック化する

417.72KI 417_72ki
~黒魔術がObjecitve-C Runtime APIだけだといつから錯覚していた?~

iOSで黒魔術といえばObjecitve-C Runtime APIが注目されがちですが、
当然それ以外にも色々な黒魔術が存在します。
ここでは、ダックタイピングという手法を使ってUserDefaultsをテスト用のオブジェクトに差し替えた話をします。
1
  • 1 (current)
  • 2
iosdc-japan-2018 sponsors iosdc-japan-2018 potential-sponsors 開催後請求
ブースWL
iosdc-japan-2018 sponsors iosdc-japan-2018 potential-sponsors 開催後請求
ブースWL