トーク

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

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

このセッションでは、公式ドキュメントを参考にしながらConsumableのネイティブ実装をした話を他の課金方式と比較しながら紹介します。

登場人物
文系卒の女子エンジニア
・エンジニア歴＝社会人歴のiOSエンジニア
・一部機能追加くらいはSwiftで開発できるようになった
・テストは業務で全く書いたこと無し

5年もののiOSアプリ
・2013年リリースで、リリース当時のコードも現役でバリバリ稼働中
・リリース当時はフルObjective-C、現在は一部Swift化
・テストコードは1行も無し

このLTではテストを書いたことないエンジニアが、年季の入ったアプリにユニットテストを導入するまでの格闘をテスト初心者視点から語ります。

まだテストを書いたことがない方、うちのアプリはレガシーすぎてテストなんて書けないと思っている方が、
テストを書いてみよう！と思ってくれることを目標としています。

入門書を読み終わり、簡単なアプリが作れるようになった！
でもこの後はどうしたらいい？とりあえずアプリを作ったらいいの？

こんなことを思った時期が少なくとも私にはありました
コードをたくさん書くこともとても重要ですが、iOSアプリ開発の世界の広げ方はこれだけではないようです

Swift上級者のコードを覗く、設計について考えてみる、技術書典で技術書を買って読んでみる、有名なライブラリやツールを導入して使ってみる、レビューをもらう、勉強会に参加する、勉強会運営にJOINしてみる、カンファレンスにスタッフとして参加してみる、などなど…

この一年間でSwift初級から中級くらいになるために私がやってきたことや、そこからどのような知見が得られたのかを素直に紹介していきたいと思います
iOSアプリ開発の世界にJOINしたばかりの方々の世界が広がると嬉しいです！

iOS12からAR Quick Look機能が搭載されました。
AR Quick LookはUSDZファイルを設置するだけでSafari等のアプリで3DモデルをAR表示することが出来ます。
ハードウェアやARKitの進化によりARの体験も確実に向上しています。
USDZファイルをサイトに設置することでその恩恵を受けつつユーザー体験やコンバージョンを向上させましょう。
このトークでは、家具ECサイトに導入した事例を元にAR Quick Lookの概要、3Dモデリング、Tips、効果等を紹介します。

WWDC19、一番始めの発表はtvOS 13でした。
マルチユーザ やコントローラーの対応で一見要点をおさえた気になりがちですが、待ってください。

TVServicesを含むフレームワークのアップデートにより、tvOS 13では、従来に比べてより充実したユーザエクスペリエンスを実装することが求められています。

このセッションでは、以下のような項目でtvOS 13の新たな機能の勘所をおさえ、より”immersive”な体験の実装手段をご紹介します。

• ストリーミングデバイス(Apple TV)の動向
• TVServices frameworkで何が変わったのか( ex. Top Shelf extension, Carousel , etc.)
• tvOS 13 でのUXのベストプラクティスとは

AppStoreを見渡すと、数え切れないほどの膨大な数のアプリが存在する。
しかしながら私たちがよく使うアプリというのはその中のほんの一部に限らている。例えば、Twitter、Instagramなど、ほとんどが大企業の開発したものだ。

それでは個人デベロッパーが開発したアプリが陽の光を浴びることはないのだろうか？

このセッションでは私が個人開発したアプリが100万DLされるまでの取り組みや改善などを中心に、プロモーションにお金を費やすことのできない個人開発のアプリをより多くの人に利用してもらうための手法やアイディアについてお伝えします。
あなたが作ったアプリをもっと多くの人たちに利用してもらい開発へのモチベーションを高めていきましょう！

• AppStore内の検索ロジック
• 今日のAppの仕組み
• 効果的なASO
• ランキングロジックの考察
• WWDC - App Store Labで得た知見

iOSエンジニアなら一度は憧れるスマホ連携IoTガジェット。
iOSとの連携が簡単なマイコンや、簡単に基板を設計、発注する方法をご紹介します。
自分だけのオリジナルIoTガジェットを作る楽しみが広がると嬉しいです！

みなさんCI環境はどうされていますか？

最近ではBitriseを使う方が多くなってきていますね！

弊社ではコード管理をGitLabで行なっているため、
GitLabRunnerをiMacで動かしてCI環境を構築しています。

・CIサービス使いたいけどお金かかるから...
・弊社はGitLabじゃないけどBamboo使ってRunner回してる！

などといった方に参考となるお話をさせていただきたいです。

・GitLabRunnerでどんな風にCIを回しているのか
　・マージリクエストを出したらテストが回る
　・ボタンポチで環境ごとにDeployGate配信
　・Releaseタスクではappstoreconnectへのアップロードを自動化
　など
・どういう設定しているか、.gitlab-ci.ymlを一部公開
・自前CIのつらみ

EightでiOSアプリを開発しているアマゾネスです。
iOS10から公開されたCallKit。自分のアプリのDBを使用し、着信電話表示を実現するためのAPIです。
Eightは名刺情報の管理をするアプリということもあり、CallKitとの相性は抜群。
実装しようという運びになったのですが、実装者はなぜEightに入ってして二ヶ月目の私。
「データの扱いどうやればいいの泣」「設定画面のぐるぐるが消えないんだけど泣」「突然の機能停止泣」
等、苦労したところをお話させていただこうと思います。

低レイヤーを触ってみたいと思いつつも今まで手が出すことができていなかった私が、今現在Swiftでファミコンエミュレータを作っています（現在進行形）
このトークでは、Swiftを使ってファミコンエミュレータを開発することの楽しさをお伝えします。
ファミコンエミュレータ開発の第一歩がなかなか踏み出せない方の背中を押すことができたら幸いです。

「API通信のデータをJSONで受け取ってEntityに変換する」、みなさんもそういったご経験はあるかと思います。
Swift4でCodableが登場してから、このようなJSONデータをより簡単に変換できるようになりました。

一方で、例えばEntityにユーザーIDや写真IDといった一意に識別する値を単純なInt型やString型で定義してしまうと、引数にユーザーIDを渡すべき関数で誤って同じ型である写真IDを渡してしまう恐れがあります。
ドメイン駆動設計(DDD)における値オブジェクト(Value Object)という戦術的設計を導入し、それぞれ異なる型として定義することで誤った代入を防ぐことができます。

しかしながら、Codableと値オブジェクトの相性は悪く、対応するには工夫が必要となります。
このトークでは、簡単なJSONデータを用いて値オブジェクトを含むEntityへのCodable対応についてお話します。

■アジェンダ
・単純な型を利用した場合のCodable対応
・単純な型を利用した場合の課題
・値オブジェクトとは？
・値オブジェクトとCodableの課題
・値オブジェクトへのCodable対応方法

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

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

アンカンファレンスで講演された内容です。

SnapshotTestingやiOSSnapshotTestCaseなど、
スクリーンショットによる差分検知フレームワークが近年注目されています。
これらは指定した画面のスクリーンショットを自動撮影し、
予期せぬ表示上のデグレを検知してくれる画期的なツールです。

一方私のプロダクトでは、状態再現の手間から来るQAコストの増加や
新しいUI作成時の仕様認識のズレなどが課題となっていました。

そこで改善のためSnapshotTestingを導入しQAコストの削減に取り組むことにました。

しかし当然ながら、単純にViewを渡すだけではうまくいきません。
なぜなら導入までに、下記のような下準備が必要なためです。

• API通信をモックする
• 必要な状態をモックできるレスポンスを考える
• アプリ内フラグやログインをモックする
• UIのモックが可能な設計にする
• 自動テストとの連携

なかなか一筋縄ではいかない導入でしたが、
結果として画面のカタログを作成しデグレ検知に成功しました。
本トークではスナップショットテストの導入にあたり、
注意すべき点や知っておくと良い点についてお話します。
導入のメリットに見合うかどうか、自身のプロダクトが抱えている課題を解決できそうか、
その参考となる情報を提供できればと思います。

Value SemanticsとProtocol-Oriented ProgrammingはSwiftの根幹をなす概念です。Swiftの言語そのものや標準ライブラリ、SwiftUIの設計とも密接に関わっており、Swiftという言語を特徴づけるHeart（心、中心）と言えます。

Value SemanticsとProtocol-Oriented Programmingについては、WWDC 2015でのSwift Core Teamメンバーによる解説がよく知られています。しかし当時はSwift 2ベータの時期で、解説に用いられたコードには現在Swift 5で動作しないものも多いです。

また、Swift 5.1で導入されるOpaque Result Type（ORT）や、その後を見据えて議論されているリバースジェネリクス、Generalized Existential、any修飾子との関係など、現在ではより広い視野でValue SemanticsとProtocol-Oriented Programmingを考えることができます。

iOSアプリ開発についても、WWDC 2019で発表されたSwiftUIによって、iOS 13以降状況が大きく変化しそうです。これまではUIKitを用いたクラスベースの開発が必須でした。しかし、SwiftUIではprotocolとstructが中心になり、ORTが多用されます。それらを使いこなすために、Value SemanticsとProtocol-Oriented Programmingの理解がますます重要になるでしょう。

本トークでは、それらの関係を示しながらSwift 5.1時代のValue SemanticsとProtocol-Oriented Programmingを解説し、SwiftのHeartを描き出します。

人工知能技術の発展により、端末による物体の判別や自然言語処理など、iOSの様々な可能性が広がってきました。これらのうちほとんどは、現在隆盛のディープラーニング技術をベースにしています。しかしながら、このようなディープラーニングベースの人工知能はあくまで「ツール」としての人工知能です。ヒトの知能のもっとも高度な部分は大脳が担っていますが、大脳が扱う「意識」は、例えば夢を見ているときのように入力が出力が無くても自発的な活動を続けています。むしろ、大脳への入力や出力は、そのとてつもなく高度な機能の本質ではないのかもしれません。また、ディープラーニングは出力に対応する正解が必要な教師あり学習ですが、高度な自律性、汎用性を有する実際の大脳では正解データのない教師なし学習が行われています。より自律的、より汎用的な人工知能をiOSアプリが搭載するためには、このようなより天然の知能に近い仕組みをアプリが備える必要があります。
そのために、本発表ではアプリが「意識」を備えるためには何が必要なのか、様々な可能性を示していきます。脳科学と人工知能の関係性から始めて、単純なルールから一筋縄ではいかない複雑な因果関係が生まれるカオスや複雑系、さらに意識を扱う理論である統合情報理論、グローバル・ワークスペース理論などを解説していきます。その上で、自律的な動作をする「意識のようなもの」へつながるアルゴリズムを探っていきます。
果たして、スマートフォンはヒトにとって単なる「ツール」であり続けるのでしょうか、それとも、ドラえもんのようなヒトにとって大事な「パートナー」になるのでしょうか。本発表では、従来の「ツール」として有用なディープラーニングを離れて、生き物のような自律性を持つ「パートナー」としての人工知能の可能性を探求します。

アンカンファレンスで講演された内容です。

近年、モバイル決済アプリが非常に話題になっています。
このトークではそんなモバイル決済アプリの開発現場から、様々な技術的トピックについてiOSアプリ開発者視点からみなさんに共有します。
モバイル決済アプリ開発特有のトピック、例えば

• Apple Pay In-App Provisionig を用いたiD決済の仕組み
• QRコードによるコード決済の仕組み
• 銀行口座接続や顔認証＋公的証明書による本人確認手法技術について
• 既存の巨大なアプリに対して、いかに安全・効率的にモバイル決済機能を追加するか
• お金を扱うアプリとしてのセキュリティの重要性とその実現方法
• モバイル決済アプリ開発の今後
  などについてお話します。

Instrumentsといえば、「リーク検出などに便利なのは知っているけれど、とにかく重くてまともに動かない...」なんて印象を持たれている方もいるのではないでしょうか。実はXcodeの進化の陰で、Instrumentsも10から生まれ変わったようにパフォーマンスが向上し、できることが増えました。

特にカスタムInstrumentsはとても強力です。
アプリに機能を実装し、UIが良い感じに動いているのを確認し、リリースしてみたら...ログがうまく送れていなかったり、必要以上にAPIを叩いてしまっているのが発覚、なんて経験はありませんか？カスタムInstrumentsを作ってアプリ内のイベントを可視化すれば、こうした問題も一目瞭然です！
また、見たい処理だけにフォーカスすればパフォーマンスのネックも見つけやすく、高速化にも役立つでしょう。

本トークではカスタムInstrumentsの作り方について詳しく解説します。
ちょっぴり癖はあるけれど、意外と簡単に作れますよ！あなたのアプリ専用のカスタムInstrumentsを作って、アプリをピカピカにしちゃいましょう！

ランチセッションで講演された内容です。