トーク

みなさん LOGO というプログラミング言語はご存知でしょうか？私は中学生の時にこの言語のタートル・グラフィックスという機能でプログラミングの楽しさを知り、現在 iOS のエンジニアをしています。

2016年7月、その LOGO とタートル・グラフィックスの生みの親であるシーモア・パパート氏の訃報をきっかけに、Swift 製タートル・グラフィックスの開発を始めました。同年の WWDC で発表された Swift Playgrounds で動かすことができれば、子どもたち（私の息子も含め）に iPad で私の中学生時代と同じ体験をしてもらえるかもしれないと思ったからです。

このトークでは、私が作っている Swift Playgrounds で動くタートル・グラフィックスについて、次のような構成でお話しする予定です。

• LOGOとタートル・グラフィックスについて、そして後世に与えた影響
• Swift, CoreGraphics, CoreAnimation によるタートルグラフィックスの実装
• Playground Book の作り方と、Subscriptions による配布方法
• Swift Playgrounds 動くタートル・グラフィックスを配布して起きたこと

-

安全にリファクタリングを行うには「お約束」があります。

「自動テストを書いてからリファクタリングする」

言葉にしてしまえば簡単で「プログラマであれば当然のことだ」とおっしゃる方もいらっしゃるかもしれません。
でもそれを難しくするのがヤツの存在です。そう、iOSエンジニアならば切っても切れない関係のFatViewControllerです。

前述のお約束を守るために、こんな堂々巡りに陥ったことのある方は少なくないのではないでしょうか。
・「UIテストを書いた上で書き換えを行うか？」「時間がかかりすぎる、ダメだ...！」
・「ユニットテストを充実させて設計を変更しながら書き換えを行うか？」「先にプロダクトコードの変更が発生してしまう、ダメだ...！」

このトークではFatViewControllerの書き換えを「自動テストを書いてから」というお約束を守ってこなすのが難しかった話をします。
そのうえでなるべく安全に、現実的に書き換えていく方法にはどんなものがあったか、どんな部分で安全を切り捨てて痛みに耐える判断をしたのか話をします。

iOSアプリ開発は年々複雑化しています。次々と追加される新デバイスや新しいAPIへの対応など技術的な要因はいくつかありますが、それ以外にも更新され続けているApp Store Reviewガイドラインやその他のApp Storeに提出できるアプリの要件を遵守する必要があるのもその要因の1つです。

ガイドラインや提出できるアプリの要件は日々修正、追加されているため常に最新情報を把握することは難しいです。ですがこれを怠ってしまうと、いざリリースという段階になってリジェクトされてしまい、思わぬ対応コストとスケジュールの変更を余儀なくされる可能性があります。

この問題を解決するため、ビルドされたアプリに対してガイドラインやApp Storeに提出できるアプリの要件を遵守できているか機械的にチェックするツールを作成しました。このツールはFastlaneプラグインとして提供され、Fastlaneによるビルドパイプラインに簡単に組み込むことが可能です。ツールによるチェック結果はコンソールログ以外にHTMLレポートとして出力が可能で、検証を担当されているQAチームと連携してリリース前の段階でアプリに問題が無いことを確認しています。

本発表では以下の内容をお話しします

• このツールを開発した経緯
• 実際にどのような項目をチェックしているのか
• チェック機能の実装方法
• QAチームとの連携
• ガイドラインを追い続けるための情報源

iOS開発においてApp Store ReviewガイドラインとApp Storeに提出できるアプリの要件を満たすために気をつけるべき注意点と、今回紹介するチェックツールと同様のものを自作するために必要な知識を持ち帰ってもらいたいと思います。

モバイル開発をしている上でデザインとの関係性は切手は切れない関係だとお思います。
また、プロダクト自体も成長に伴い複雑性がましてきました。そのときに私はデザインシステム
に注目して様々なアプローチしてきました。

本発表ではあまり馴染みではない「デザインシステム」はどういうものなのかという基本的な話から
ではどのようにしてプロダクトにデザインシステムを導入し、どこまで何をしていったのか
エンジニアリングを持って何を解決していったのかを解説します。

概要

• デザインシステムの基礎
• 導入にあたって
• エンジニア側からできること
  • カラー管理・自動化
  • 画像管理
  • インタラクション

動画を現実の風景に重ね、その一部を透過させて再生する実装について説明します。

AR(Augmented Reality)空間でシンプルに動画再生するのはそれほど難しくありません。
しかし一部透過させようとするとリアルタイム画像加工をする必要があり難易度が高まります。

表示のガタつきを抑え、一部を透過させた動画を再生するには。
60fpsかつ音声付きで再生するにはどうしたら良いのでしょうか。

クロマキーシェーダーと再生処理の工夫により実現した実装とその他Tipsを共有します。

この発表では以下の内容について話す予定です:

• クロマキー合成シェーダーの実装
• 60fps音声付きでの透過動画のスムーズな表示
• リアルタイム配信映像の受信について

「プログラミング」と「論理」の世界には直接的な対応関係があり、
私たちが普段書いているSwiftにおいても例外ではありません。

例えば、論理の世界における命題「AかつB」はタプル型 (A, B) 、
「AならばB」は関数型 A -> B を使って書くことができます。
これらの型（命題）を組み合わせ、適用していくことで、
あたかも論理式（や数式）を証明するかのように、アプリのプログラムが完成します。

この、「型 ⇔ 命題」、「プログラム ⇔ 証明」に対応することを「Curry-Howard同型対応」と言います。
この背景を知るには、「直感主義論理」と「型付きラムダ計算」の両方を学ぶことが重要です。

そこで、この発表では、理論的基盤となる「古典命題論理・述語論理」「ラムダ計算」の基本をおさらいした後、
「直感主義命題論理」「Curry-Howard同型対応」について、実際にSwift言語を使ってお話しします。
また、Swiftがサポートする「多相型」、「Protocol (Witness)」、「Opaque Result Type」等にも触れ、
圏論の図式を使った、より手軽で簡単な解説も予定しています。

なお、今回の発表は、昨年のiOSDCの発表の続編になります。
事前の予習として、下記のスライドをご参考ください。

代数的データ型 https://speakerdeck.com/inamiy/algebraic-data-type-in-swift
圏論とSwiftへの応用 https://speakerdeck.com/inamiy/iosdc-japan-1

本トークでは、Auto-Renewable Subscriptionsと呼ばれる、定期的に新しいコンテンツが配信される種類のApp内課金について、実際に実装する上でハマったことや実装前に知りたかったようなノウハウを織り交ぜて説明します。
また、今年のWWDCのセッション『In-App Purchases and Using Server-to-Server Notifications』では、サーバー間通知の仕様のアップデートがアナウンスされ、レシートの取り回しの方針が今秋から大きく変わることが判明しました。本トークではそちらについてもご紹介いたします。

【アジェンダ】

1. In-App Purchasesについて
2. Auto-Renewable Subscriptions導入の経緯
3. Auto-Renewable Subscriptionsの大まかな処理の流れ
4. StoreKit frameworkの各メソッド定義と実装方法
5. Sandboxテスターによる動作確認方法
6. サーバーサイドの設計
   ・状態更新通知
   ・Sandboxレシートのハンドリング
   ・Grace Periodの実装
   ・WWDC19で発表されたサーバー間通知の新しい仕様について
7. リジェクトについて気をつけたいポイント

みなさんは以下の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時間もの時間が消し飛び、この世には「サマータイムが発生した」という「結果」だけが残るッ！！」

iOSアプリを審査に提出するときに回答が必要となる「輸出コンプライアンス情報」についての質問。あなたは毎回、正しく理解して最適な答えを選ぶことが出来ている、と胸を張って言えますか？

HTTPSも暗号化に含まれるの？暗号化を使用しているけれど、EAR（米国輸出管理規則）の免除資格を満たしているか曖昧だ、など不安を抱えながら回答している、という方もいらっしゃるのではないでしょうか。

本トークでは5分間でフローチャートを交えながらこの「輸出コンプライアンス情報」にあなたのアプリがどう回答するべきなのかを説明します。このトークさえしっかり聞けば、明日以降のiOSアプリの申請では自信を持って「輸出コンプライアンス情報」に回答することができるようになるでしょう。

Swift 5のiOS13から使用できる機能の一つにProperty Delegates(SE-0258)というものがあります。
SwiftUIでも@StateなどすでにPropety Delegatesで実装されたものもあり、目にした方もいらっしゃると思います。

Property Delegatesはとてもユニークな機能で、これまで書いていたボイラープレートを解消できたり、アーキテクチャやコンポーネント設計を考える上でも、重要な機能の一つとなってくるのではないでしょうか？

この発表ではProperty Delegatesとはどのようなものなのかを紹介するとともに、
どのような課題を解決するのか例を踏まえて紹介します。

概要
Property Delegatesとは
実装例の紹介(State、User Defaults、Validation)
Swiftプログラミングにおける継承、抽象化、関心の分離などのこれまでの考え方などを踏まえたProperty Delegatesの役割の考察

WWDC 19で発表されたXcode 11の新機能の中でも喜ばしいものの1つは、XCFrameworksという、フレームワークの新しいバイナリ配布フォーマットです。これまでフレームワークの配布には".framework"という拡張子のフォーマット（バンドル）が使われていました。しかし".framework"のバイナリの配布では、1つのバンドルでシミューレーターとデバイス両方で使用できるようにするためのビルド手順の複雑さ、iOS用とmacOS用、tvOS用など対応プラットフォーム毎にバンドルを分離する必要（この場合は3つ）などの問題がありました。

Xcode 11から使える".xcframework"という新しいフォーマットは、まさにこれらの問題を解決しているのですが、どのように解決しているのか、またどうしてXcode 11のタイミングで導入されたのでしょうか？本LTではXCFrameworksの構造や作成方法、そしてこの形式が導入された理由（の推測）に迫っていきます。

アプリ開発の経験が無く、プログラミングそのものの経験も浅い、そんな初心者の困り事の一つは、不具合の原因を特定するのに多くの時間を費やしてしまうこと。
原因特定スピードを上げるにはLLDBデバッガが有効です。
Xcode10.2から登場したvコマンドについて

• vコマンドでわかること
• vコマンドの操作手順
• poコマンドとの違い
  をお話します。
  LLDBデバッガを活用した経験があまりない方や、poコマンドを普段使っていてvコマンドを使ったことがない方向けです。

日本ではほぼすべての人が義務教育期間を経て立派な大人になっていくと思います。そして、そんな意識が曖昧な期間の人々は大きな過ちを犯しがちです。そう。例えば「先生」に対して「お母さん」と呼んでしまう問題は鉄板の過ちと言えるでしょう。人間は過ちを犯すものです。脳内では「先生」と「お母さん」は区別はついているはずなのに呼び間違えてしまう事象が発生してしまいます。脳内に常にバグがあります。そんな我々が書くプログラムにおいてもそのようなバグが混在しないと言えるでしょうか？いいえ。発生しないなんて言い切れないです。特にSwiftのような実行前に厳格にチェックが入るシステムなら事故は減らすことができると思います。しかし、私達が普段扱っているのはSwiftで記述できますが、未だに@objcなどの存在がちらほら見えるUIKitやFoundationを支えているであろう Objective-C の存在を感じざるを得ません。Objective-Cでは非常に動的にメソッドを呼び出すことが可能です。これはつまり「先生」を「お母さん」と呼び間違える可能性が出てくるということです。Objective-Cの世界では「先生」に対して「お母さん」と呼び間違えたら自分が羞恥心でクラッシュします。

このトークではObjective-Cにおいて、「先生」を「お母さん」と呼び間違えてしまった場合の復帰策についてお話していきます。

iOS12から搭載されたAR Measureアプリは、ARKitの精度を証明するとともに、現実のものを何でもスマホで測ることができるという世界を実現しました。しかし、AR Measureの操作には慣れが必要だったり、自分でスマホを持った状態で動き回らなくてはいけないという課題が存在します。そんな課題をCore ML、すなわち「機械学習」を使って解決することができます。例えばフリマアプリなどで服を売りたい時、服の着丈、身幅、肩幅、袖丈などを載せたいと思う人がいると思います。このようにあらかじめ測定したい場所・指標が決まっている場合、機械学習でそれらを測るために必要な点群の位置を推定することができます。点群の位置さえ推定できれば、ユーザーがわざわざARで測らなくても、平面認識と深度推定によって自動的に現実物のサイズを得ることができます。つまり、機械学習で「どこを測るか」を決めて、ARで「それが現実世界でどのくらいの長さなのか」を決めます。今回はTシャツを例に、その着丈、身幅、肩幅、袖丈をARKitとCore MLを使って一瞬でサイズ測定するプロトタイプをお見せします。今回のプロトタイプを応用すれば、インテリアや人の身長など、様々なものを一瞬で測ることができるようになります。この発表では、機械学習によっていかにARのサイズ計測が簡単かつ速くなるか、というお話と、それによって実現できた精度とその改善方法、その過程で使用したモデルなど技術的な知見を共有します！

iOS の設定は Configuration Profile という形式のファイルをインストールすると変更できることは、意外と知られていません。
もし、これをアプリを通してインストールできれば、iOS 11 未満でも Wi-Fi を QR コードで繋げるなど様々な可能性が広がります。

この LT では、Configuration Profile によってできること、そしてアプリから Configuration Profile をインストールする方法を解説し、皆さんの iPhone 環境構築体験を豊かにするための知識を披露いたします。

マーケチームから来る「あくつ〜。プッシュ通知許諾率あげてくれないとリテンション施策打てないよ〜」という声。

平均30％と言われる承諾率だが、何故か僕たちのアプリは17%・・。

プッシュ通知承諾パネルを表示するタイミングは、熟考された上に以下の２つのタイミング。

• お気に入りにアイテムを追加した時（新しくお気に入り商品が投稿された事を通知するため）
• 商品の購入が完了し、取引が始まった時（取引のリマインドのための通知を送りたいため）

何が悪いのかさっぱりでしたが、意外なことで解決しました。
ある１つのことをしただけで、プッシュ通知許諾率が全体平均17％から40％にあがったワケとは！？
拘りの強いiOSエンジニア（デザイナー）が陥りやすい罠についてサクッと話します。

プッシュ通知の配信といえば Firebase を思い浮かべる方が多いと思いますが、
AWS でも Pinpoint というサービスを使うことで、プッシュ通知のセグメント送信をすることができます。
さらに、 AWS Pinpoint では AWS Lambda を使ってセグメントをカスタマイズすることができるため、
ほかの AWS リソースのユーザー情報をもとに通知内容をユーザーごとに変更することまでできます。
また、ユーザーに複数のチャネルを割り当てることができるため、プッシュメールとプッシュ通知を使い分ける、といったことも可能です。

本 LT では、 Pinpoint を用いたプッシュ通知の配信から、こうしたユーザーごとのカスタマイズまでを扱います。
特に普段のアプリのバックエンドで AWS を活用しており、通知配信も AWS 内で行いたい方の参考になれば幸いです。

開発環境の構築って面倒ですよね。
Xcodeのインストールは時間がかかるし、その他いろんなツールに関して手順書を用意しておいても、ちょっと違うバージョンがうっかり入っちゃうとかよくあります。

このLTでは、毎月数十台のMacをセットアップし続けてきた経験から、Appleの提供する標準機能だけで全く同じ構成のmacOS環境を準備するために行ってきたいくつかの方法と、それぞれの特徴についてお話しします。
また、Sierra -> High Sierra -> Mojaveと毎年バージョンアップされるに伴って利用できる技術が変わっており、現在進行形で困っていることについても話します。

SOLID原則は、オブジェクト指向プログラミングにおける基本的な5つの原則です。

S - 単一責任の原則 (Single Responsibility Principle)
O - 開放/閉鎖原則 (Open/Closed Principle)
L - リスコフの置換原則 (Liskov Substitution Principle)
I - インタフェース分離の原則 (Interface Segregation Principle)
D - 依存関係逆転の原則 (Dependency Inversion Principle)

コーディングにおいて、言語化できない不吉なにおい（Code Smell）を感じたときには、これらの原則に照らし合わせることで設計の間違いを言語化し、修正の手がかりを掴むことができます。

SOLID原則はもちろん、ソフトウェア設計のための原則です。
しかしオブジェクト指向は「複雑な問題領域を分割統治する」コンセプトであり一般性を見いだせます。原則が転用できるのは、コードの中のみではないはず。
このLTでは、コーディングにまつわらない日常生活のものごとをいくつか例に挙げ、SOLID原則の視点で解釈してみます。
ドキュメンテーションから部屋掃除に至るまで、SOLID原則を適用すると、どのような「におい」をあぶり出し、改善することができるのでしょうか？
そうやってSOLID原則に慣れ親しんでみれば、コーディングでのSOLID原則の熟達にも役立つことでしょう。

30分枠でも同タイトルのプロポーザルを提出していますが、LT枠としては「こんなふうに共通の課題を見いだせる！」というアハ体験の楽しさを重視したいと思います。