所 友太 / Spinners Inc.
2020年におけるHomeKitの総括。

みなさんにあまり知られていないだろうHomeKitの入門からオープンソース化されたHomeKit ADKまで20分に凝縮してお届けします。

• HomeKitざっくり入門
• HomeKitにおけるBridgeの概念
• HomebridgeでHomeKit未対応の製品をHomeKit対応
• HomeKit Accessory Development Kitで作る自作アクセサリ

トビラシステムズ株式会社では、アプリ内に迷惑電話フィルタ機能を実装しています。
弊社では3年以上に渡り多くの電話番号情報を提供するためにCall Directory Extensionと向き合ってきました。
何かと制限が多いCall Directory Extensionに多くのデータを安全に入れるために実践してきたTipsをご紹介します。

【サマリー】

• 各OSごとのパフォーマンス
• 差分データの更新のTips
• メモリ管理
• 更新途中でキルされるとCall Directoryがクラッシュする問題

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 開発者

「iOSから連絡先をサーバーに同期させたい」
用件を受け、iOSにはContact APIがあるから楽勝でしょ、と思ったあなた。
しかしながら連絡先の構造はそんなに簡単なものではありません。
ミドルネーム？Suffix？振り仮名？旧姓？
そんなハマりやすい連絡先処理の説明やVCard変換など、
サーバーのテーブル設計にも役立つiOSのContact APIについてお話しします。
(Androidの連絡先にも若干触れる可能性あり)

定期的に配信されるコンテンツがあるサービスでは、自動ダウンロードの機能がより良いユーザー体験を提供します。
ユーザーは常に安定した通信環境にいるとは限らず、大きいコンテンツの取得には通信的な負荷もかかります。
例えば、新聞紙面の画像はサイズが大きい複数枚の画像で構成されており、ダウンロードには多くの通信量や実行時間が必要となります。
あらかじめ大きいコンテンツを自動でダウンロードしておく仕組みは、ユーザーがアプリを継続的に利用するにあたり非常に重要な役割を担います。

iOSではバックグラウンドでコンテンツをダウンロードするためのAPIが複数用意されています。
しかし、バックグラウンドでタスクを動かすタイミングや時間はOSによって制御されており、ユーザーが調整できる箇所は限られています。
それぞれのAPIが抱える制約を理解し、コンテンツの性質に応じて適切な選択をしなければなりません。

本セッションでは、大きい画像コンテンツを対象にした自動ダウンロード機能について説明します。
実装の過程で直面した問題への対策やアプリやサーバーサイドを含めた全体のアーキテクチャを解説するとともに、日本経済新聞 紙面ビューアーにおける新聞紙面画像での運用事例を紹介します。
大規模サービスにおける運用を通じて得られた安定して自動ダウンロードを成功させるための課題の解決方法を説明します。

アプリの運用を続けていくと、成長に合わせて機能も増えていきます。
機能のリリースを優先した運用を続けた結果、月日が経過してふと気づいたときにアプリのパフォーマンスが低下していたという経験はないでしょうか？

このトークでは、4年間運用されて表示パフォーマンスが低下していった詳細画面を題材に、原因の特定から最大で表示速度が200%改善するまでを以下のような観点を踏まえて紹介します。

第1フェーズ（調査）

・表示速度をどのように計測するか
・何が原因で表示速度が落ちていたか
・そもそもどのようなViewの構成だったか

第2フェーズ（最短リリースを目標とした改善）

・どのようにViewを生成していくか
・データの受け渡しをどのように繋げていくか

第3フェーズ（画面回転も考慮した改善）

・改善するためにどのようなViewの構成に変えていったか
・Viewに紐づくデータはどのように定義したか

まだしばらくはUIKitも現役なはずなので、これから改善をやってみようという方も新規の実装をしていこうという方にも、参考になる知見を紹介できればと考えています。

Apple pencil、活用できてますか？

Apple pencilは、2015年末にiPad Proとともに発売され、2018年末には第二世代が発売されました。長らくApple純正アプリ以外は対応に苦慮してきたと思われますが、WWDC2019でPencilKitが発表されたことにより、簡単にApple pencil対応が可能になりました。

ライブラリ自体は使いやすいものですが、具体的なノウハウについては情報が少なくて、実際につくってみると試行錯誤することになりました。そこで本トークで、開発ノウハウを共有したいと思います。

このトークでは、PencilKitを利用したノートアプリ（「Like a Paper」）を個人開発した経験から、Apple pencil対応の勘所を話します。具体的には、PencilKitでできること/できないこと、 PKDrawing から UIImage への変換、ダークモード対応の罠、 PKToolPicker のカスタマイズなどを扱います。

これまでは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への対応方法をご紹介します。

20xx年。

アプリ戦乱の時代。
各地では多くの戦い(申請)が行われていた。

戦果を上げる(申請が通る)ものもいれば、
負けて帰ってくる(リジェクトされる)ものもいた。

特にサブスクリプション地域(課金実装)では、
相手(Apple)との戦闘(やり取り)が激化しており、
兵士(エンジニア)はみな疲弊していたのだった。。。

これはそんな戦いを描いた１つの物語(アプリ審査過程の話)である。

課金ページの実装を専属で担当し、課金ページのレイアウト改変やA/Bテストを頻繁に行った結果、毎月のようにAppleからのリジェクトを経験しました。
メッセージで多くのやりとりを行ない、一般的には公開されていないような課金ページの細かなアンチパターンが蓄積してきたので、紹介していきたいと思います。

みなさんデバッグメニュー作っていますか？接続先のサーバーを切り替えられるようにしたり、特別な処理や表示をするための仕組みをアプリ内に実装したことがあると思います。こういった仕組みやデバッグメニューは開発中の動作検証にとても便利ですが、アプリごとに独自実装されることが多いため、使い方も実装方法もすべて異なってしまいます。これでは新しいメンバーが参加した際やQA時に毎回使い方を説明する必要があって大変ですし、各アプリでのメンテナンスコストもかさんでしまいます。

また、ユーザーが利用しない機能なので開発や改善の優先度も低くなり、気づいたら大きな負債になってしまうこともあります。負債が大きくなった結果、うっかりユーザーにもデバッグメニューが見える状態でリリースする事故がおきてしまうかもしれません。

これらの問題を解決するために、デバッグメニューを専用アプリとして切り出して管理する方法を実現しました。このトークでは、

• デバッグメニュー専用アプリを作り、対象アプリの状態を再ビルドなしで切り替える方法
• AdHoc, InHouse, SimulatorだけでなくApp Store版でも対象アプリの状態を切り替える方法
• デバッグメニュー専用アプリを作ることによるメリットとデメリット

についてお話します。

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

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

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

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

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

iPadOS 13.4でついにマウスやトラックパッドを接続可能になったことでキーボードとマウスが揃い、iPadは以前よりもさらに作業・創作用マシンとしての真価を発揮できるようになりました。
このトークではマウス・キーボード対応アプリで抑えるべきポイントについてまとめます。

多くのアプリはマウスやキーボード対応をしていなくても大きな問題になることはありませんが、ドキュメント編集アプリなど、閲覧にとどまらない機能を提供するアプリではマウスへの対応を行うことがその使い勝手に大きく影響します。
また実際にテキストエディタでマウス対応を行った経験を踏まえて、マウス対応そのもの以外にもマウスやキーボードをフル活用するアプリで対応しておくと良いAPIについても合わせてお話しいたします。

• iPadOSにおけるマウス・キーボード
• マウス対応のための準備
• まず抑えるべき簡単な変更
• マウスカーソルの変更について
• マウス操作とタッチ操作を振り分ける
• あると嬉しいコンテキストメニュー
• iOS/iPadOSとキーボード
• シフトキーを使った範囲選択
• ショートカットコマンドなど

今や技術面で何か画期的なことが達成される場合、十中八九、機械学習／ディープラーニングが利用されています。大学で専門的に機械学習を学ぶ人も多く、技術書でもオンライン講座でも機械学習系は非常に人気です。今や猫も杓子も機械学習を学び一見レッドオーシャンとなっている機械学習分野ですが、我々iOSエンジニアには実は「機械学習のブルーオーシャン」が残されています。それがCore MLです。

『Core ML？触ってみたことあるけど、簡単だし、今更トークで聞くことなくない？』

と思われた方もいるかもしれません。しかし、多くの人が触ったことがあるのは、CoreML.framework止まりです。

CoreML.frameworkは既存のモデルをiOSで扱う際に利用するフレームワークに過ぎず、実はそれはCore MLのポテンシャル全体からみれば氷山の一角にすぎません。たとえば近年のWWDCでは毎年多くのML関連の新機能が発表されますが、CoreML.frameworkのレイヤーだけ知っていてもその機能の多くは活かせず、そもそも具体的に何がどこまでできるということすら理解は難しいと思われます。

Core MLはCore MLのモデルフォーマットと、そのモデル作成を担うCore ML Tools（coremltools）を理解してこそその真価を発揮できます。そして、iOSで最先端の機械学習モデルを効率的に動作させるには、このCore MLの全体を理解しつつ、iOSアプリ開発についても熟知し、その上で機械学習にも理解がある必要があるので、機械学習の専門家でも簡単には参入できないブルーオーシャンとなるわけです。

本トークではiOS×ML分野で仕事をするために必要な技術領域全体について解説します。

AVAudioEngineが登場してから長らく、C言語のAudioUnitのAPIのように入出力のそのままのデータをダイレクトに扱うことができませんでした。それゆえにいまだにC言語のAPIを使っているままの方も多いと思います。

しかし、iOS13ではAVAudioEngineにAVAudioSinkNodeとAVAudioSourceNodeというNodeが追加されました。これらはダイレクトにオーディオデータを扱うことのできるものです。もうレガシーなC言語のAPIを使い続ける理由は無くなりました。

そしてC言語のAPIはDeprecatedになっています。AVAudioEngineに乗り換えなくてはいけないのは時間の問題です。

このトークではこれらの新しく追加された機能の使い方を解説します。後々慌てることのないよう早めに対応していく手助けとなれば幸いです。

ベジェ曲線は、シトロエン社のド・カステリョとルノー社のピエール・ベジェにより考案されました。
ベジェ曲線はアプリのアイコンやアニメーション、ポスターなど様々な箇所で用いられ、私たちの身の回りは実はベジェ曲線で溢れています。

本トークではベジェ曲線を定義から追いかけ、iOS でベジェ曲線を扱うための API である UIBezierPath や Path に絡めながらその魅力をお伝えできたらと思います。

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

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

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

本セッションでは、そんなiOSにおけるWebARの変遷を振り返りながら、時にAndroidにおけるWebARと比較しつつ、具体例を交えてiOSのWebARを紹介します。

みなさんは「エラー」の取り扱いをどうされていますか？

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

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

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

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

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

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

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

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

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

このトークを聞いてプロポーザルの書き方を学び、あなたも次のiOSDCのステージに立って好きなことを広めてみませんか？

皆さんはアプリを使っていて「このアプリを使っているとiPhoneのバッテリー消費早いな」と思ったことはありませんか？
バッテリーの消費は見落としがちな指標ですが、ユーザーにとって非常に重要な影響を及ぼします。

本セッションではバッテリー消費に関するデバッグについて紹介します。
Xcode Energy GaugesやEnergy Logsを活用しアプリの問題点を洗い出していきましょう。

SwiftUIが出て、大きなパラダイムシフトになっています。弊社アプリのObjective-C -> Swift移行の知見を活かし、失敗せずにUIKitからSwiftUIへ移行するための計画と考察した内容を共有します。具体的には、以下のとおりです。

Planning

• まだ移行できない段階でどう計画を立てるか

What not to migrate (yet)

• まだまだSwiftUIに向いていない処理と画面を理解する

Prototyping

• 移行以前に、SwiftUIの使い方と違いを理解するうえでの、prototypingの有効性

Swift

• 値型や関数型プログラミングなど、モダンなSwiftコードにすることで、SwiftUIへ移行しやすくする

Reactive Programming

• RxSwift/ReactiveSwiftを使っている、又はまったくリアクティブプログラミング経験のない状態から、SwiftUIでよく使われるCombineの導入方法・準備方法

Interop

• UIKitとSwiftUIの混在と互換性
• RxSwift/ReactiveSwiftとCombineの混在と互換性

Components

• コンポーネント化の有効性

Architecture

• SwiftUIに適したアーキテクチャを評価し、導入する方法