トーク

患者さんに「かかりつけ薬局」として「選ばれる」薬局には、何が必要か。
「kakari」は、薬局の「差別化」に着眼した新しいコンセプトの薬局アプリです。

去年には姉妹アプリであるかかりつけクリニック支援サービス「kakari for Clinic」をリリースし、その後両アプリ間の連携を開始しました。
「kakari for Clinic」アプリでオンライン診療を受けた患者さんは、「アプリ連携」機能を活用することで、「kakari」を初めて利用する際に必要となる情報の登録が簡略化され、「kakari」アプリを簡単に利用できるようになります。

本セッションでは、「kakari」で実現したい未来と、
FirebaseのDynamicLinkを使ったアプリ関連携の実装について紹介します。

2014年からサービス開始したnote。

iOSアプリはこれまでWebと機能面での差がありましたが、2020年は開発の土台作りのためのMagic PodやXcodeGenなどの活用、公式ライブラリであるDiffable Data SourceやCombineなどの導入、iOS 14で追加されたウィジェット機能の取り入れ、エディタ機能のリプレイスなど、さまざまな取り組みをしてきました。

2021年も、iPadアプリ対応やアクセシビリティ向上などに取り組み、アプリの評価も急上昇しています。

でも、インターネット上でひとびとが暮らすときの本拠地を目指すnoteにとっては、必要な開発がまだまだ山積みです。

本セッションでは、CTOの今からnote iOSアプリ開発のこれまでとこれからをご説明したうえで、日々一緒に働くPdM、デザイナー、ディレクターのコメントをご紹介します。

iOS で使えるライブラリを作ったからみんなに使って欲しい、仕事の成果をオープンソースで公開したいということはよくあると思います。
Swift Package Manager の登場や Xcode への GitHub の統合などでオープンソースのライブラリの利用はとても簡単になりました。
しかし、そういったオープンソースのライブラリを提供するのはまだ簡単ではありません。

実際に使いやすいライブラリを提供するには、ライブラリそのものの API のデザインだけでなく、
ライブラリを運用するためのバージョンの管理、CI の設定、ドキュメントの作成や、内部のレポジトリと外部のオープンソースのレポジトリの差異、
Issue の管理のなど多岐にわたる問題への対応が必要になります。

このセッションでは、実際に業務の成果をオープンソースとして公開した「Twitter Text Editor」の経験を踏まえて、API のデザインから運用のためのツールの作成などをまとめていきたいと思います。

対象とする方:

• オープンソースのライブラリを使った iOS アプリの開発の経験がある方
• ライブラリの開発に興味がある方

前提とする知識:

• Git
• GitHub
• Swift Package Manager
• Xcode

At Apple, we believe that privacy is a fundamental human right.
（WWDC 2021 Apple’s privacy pillars in focus より）

プライバシーは基本的人権であると、Appleは明言します。

WWDC 2021の中でもプライバシーに関わるアップデートやセッションがありました。
昨年は App Storeにおける「プライバシー表示」が開始され、iOS14.5から開始されたATT（App Tracking Transparency）は、現在進行形で巷を騒がせています。

このように年々重要性が高まっているプライバシー保護ですが、私たちアプリ開発者は一体何を行えばよいのでしょうか。
また、数ある制約の中でどのようなユーザー情報を活用していけるのでしょうか。

幸いにも、私たちはAppleというプラットフォーム上で生きています。
そこには多くの制約がありますが、裏を返せば、私たちはその制約によってユーザーのプライバシーを侵害してしまうリスクから守られています。

ユーザーの利益を損なわないために、また、私たち自身を守るためにも、まずはAppleが示すプライバシー保護について学びましょう。

本トークでは、アプリ開発に関わるプライバシー保護についてお話します。
WWDC 2021 にて発表された最新情報に触れつつ、Appleが重要視するプライバシー保護の4本柱について説明します。
そして、私たちアプリ開発者が対応しておくべき事項を紹介した上で、変化していく環境にどのように適応していくか、について考えます。

iOSDC Japan 2020で発表した『iOSではじめるWebAR』のアップデート版です！
ChromeもMicrosoft EdgeもFirefoxも“標準”でWebXR Device APIに対応する中、長らく未対応の続く我らがWebkit、そんなWebXR領域では何かと足が遅く見えるWebKitでも 1 年も経てばいくつか変更が入っています。

まずはWebKit Feature Statusで“WebXR Device API”がIn Developmentステータスになっていること！いつSupportedステータスに変わるかわかりませんが、少なくともSafariでWebXR Device APIが使える未来が予定されていることだけはわかります！

そしてiOS 14.5で突然SafariのExperimental Featuresに追加されたWebARのためのものと信じているmodel要素！これはiOS 14.5時点では要素そのものは認識されるものの肝心の3Dモデルは表示されませんが、今後デファクトスタンダードになるかもしれない要素が登場したと言えます。

そうした事例を挙げながら、多くの人が毎日触るであろうSafariにおけるWebARが今どのような状況にあり、何ができるようになっているのか、次のようなトピックスを解説します。

• iOSとWebARのこれまでとこれから
• WebXR Device APIの概要とその動向
• WebXR Device APIに頼らないWebAR
• iOSでも動くWebARを用いた最新事例10選
• WebARコンテンツの開発手法

SwiftのCodableはすごく便利な機能です。しかしながら時にCodableが得意ではないフォーマットを扱うことはみなさんもあるはずです。もしAPIのJSONならCodable向きにスキーマを調整できるケースも多いはずなのですが、このトークではそのような調整がそもそも不可能な例として、Appleの独自ファイルフォーマット (Apple Watchの文字盤ファイル) を見ていきます。どのようにSwiftコード側でCodableを整えていくかのテクニックをお伝えします。

Apple Watchの文字盤ファイルでなにをするの？

文字盤ファイルを取り出して解析した人はおそらく世界に1人しかいないので簡単に説明します。アレには、文字盤の種類(写真とかSiriとか)や、左上には天気があり下にはカレンダーがある、といったデータが詰め込まれています。

そして、文字盤ファイルは取り出してシェアできます。それを解析して再合成してみました。1個の文字盤を1個のCodableなstructで表現し、Swiftらしさのある整った読み書きしやすいコードにします。そこで出てくるテクニックは他のファイルをCodableで定義するのにも役立つでしょう。

文字盤ファイルのここが難しい！

文字盤ファイルにはJSONの部分もありますが、その全体は複数のJSONやplistが画像リソースとともに詰まったフォルダ構造をしています。個別のJSONやplistには、変数名として使えないキー名が出てくるだけではなく、Unix Epochの日付とCore Data由来の2001年でオフセットされた日付の混在や、Objective-C時代のシリアライズなど、普段のCodableだったら扱いたくないような要素が次々に出てきます。これらをスマートに乗り越えていきましょう。

StoreKit はアプリ内課金を実現するためのフレームワークです。StoreKit の API は取り扱いが難しく、難しいが故に 3rd party のライブラリを介して利用したり、いざアプリに組み込んだ際には考慮漏れや原因の特定が困難な不具合に苛まれる事があったかと思います。

そんな中、 WWDC21 にて Apple より StoreKit 2 の発表がありました。 API は刷新され、非常に取り扱いやすくなりました。本セッションでは、これまでの StoreKit の API の取り扱いの難しさを振り返りながら、 StoreKit 2 でどのように変わるのかを解説します。

noteのiOSアプリはここ1年間で大きな変化を遂げました。
元々30%程度だったSwift率が90%を超え、デバイスもiPhoneの縦画面のみの対応でしたがiPadの複数ウィンドウにも対応しました。
このように目に見えるカイゼンを進めてきた私たちですが、あるきっかけで目に見えない課題があることを知りました。
アクセシビリティ機能を駆使して私たちのアプリを利用してくれている方からお問い合わせをいただいたのです。
この方の日頃の利用方法についてインタビューさせていただくことになり、今まで見えていなかった課題に気づくことができました。
そこでアクセシビリティの有識者に力を借りながら、Voice OverやDynamic Typeといったアクセシビリティの助けとなる機能にも対応をはじめました。
・Voice Overを利用するとさわれると思っているUI要素にさわれない
・わかりやすいと思っていたボタンなのにVoice Overを通すと何のボタンなのか理解ができない
このトークではこういった課題を認知して、実際に対応したことをまとめてお話します。

iOS端末の業務利用現場では、MDMを使ってアプリ配布やOSレベルの設定を遠隔で行います。しかし実際にはそれだけは不十分で、配布したアプリの設定がそれぞれ必要になります。例えば、接続先サーバなど各アプリ固有情報の入力です。大量のiOS端末を配布する場合、その設定作業だけで途方も無い労力を要します。

これらを自動化する方法はないのでしょうか。

その期待に応えてくれるのが「Managed App Configuraiton」です。Managed App Configuration を使えば、MDM上で登録する key-value を Dictionary としてアプリと一緒に配布できます。その情報を使ってアプリは起動直後の初期設定を自動で行えるというわけです。

Managed App Configuration は少しのコードを追加するだけでどんなアプリでも使えます。ADEPによるInHouseアプリはもちろん、AppStore申請する公開アプリやカスタムAppでも利用可能です。

現在、多くのMDMが Managed App Configuration に対応していますが、残念ながら業務用アプリの多くは対応していません。本トークでは業務用アプリで Managed App Configuration をどのように使えるのか、具体的な実装や設定の仕方、活用方法をご紹介します。

ARKitは進化を続けていて表現できる内容も年々増えています。
LiDARセンサーやiOSの機能と連動して、少し工夫することで面白い機能が実現できます。

私は100日間AR表現実装チャレンジを通して多様なAR表現を実装してきました。
その中で「これは面白い！」と人に伝えたくなる実装がいくつか出てました。

• LiDARで認識した世界にカラーボールをぶつけて色付け
• リアルタイム顔ペイント
• BlotterMedia風身体エフェクト
• AR謎解き
• 視線トラッキング
  他

眠らせておくにはもったいない実装の数々を熱く紹介していきます！
聞いた人がワクワクするような内容になるはず。

Swift、ARKit、SceneKit、Metal Shader Languageなどを中心にした実装。
デモとコード解説を軸に、AR表現に興味を持った人がさらに興味を持つようなセッションです。

新しい生活様式になってから約二年が経とうとしています．その中で，アプリやサービスを通して人とお話する機会が非常に増えてきました．これに伴い，通話アプリの種類は会議からタレントとの交流まで多岐に渡るものとなりました．そしてこれらのアプリには，「背景を隠せるようにしたい」「専用の背景を提供したい」「コラボコンテンツを提供したい」といった機能のニーズがあるかと思います．

本トークでは，バーチャル背景の実現方法を2つご紹介いたします．また，これらの方法は，既に本番プロダクトに導入済みであり，実現方法に加えて，本番導入に伴うtipsもご紹介したいと思います．

具体的には，

ARKitを使った方法

• バーチャル背景の実現方法
• パフォーマンス周り
• 他の手段とのメリデメ
• 副次的に得られそうなメリット

CoreMLを使った方法

• バーチャル背景の実現方法
• パフォーマンス周り
• 他の手段とのメリデメ

本番プロダクトに導入する際のtips

• 開発
• 申請

皆様の体験向上に貢献できれば，幸いです．

自動更新サブスクリプションを提供するAppでは、初めてサブスクリプションを行うユーザーに対して、
無料トライアルなどの割引お試し価格をオファーをすることができます。
また、以前サブスクリプションを利用したことのあるユーザーに対してはプロモーションオファーを通して同じように無料トライアルなどのオファーを利用することができます。

アプリ側でこれらのオファーを実装することは比較的難しくありません。
しかし、お試しオファーの利用中にプロモーションオファーを適応した場合、ユーザーの課金状態（レシートの中身）はどうなっているのでしょう？
お試しオファーの無料期間中にプロモーションオファーを受けた場合、お試しオファーの無料期間は破棄されプロモーションオファーの無料期間が即時適応されます。

ではプロモーションオファーの無料期間中に新しいプロモーションオファーを受けた場合はどうなるでしょう？
さらに、
1ヶ月自動契約更新のサブスクリプションで課金中のユーザーがプロモーションオファーを受けた場合と、
12ヶ月自動契約更新のサブスクリプションで課金中のユーザーがプロモーションオファーを受けた場合はどうなるでしょう？
ちょっと変数が増えてきてややこしくなってきましたね。( ^ θ ^ )

このトークでは、オファーを受け取ったときの課金状態に応じてどのように課金ステータスが変わるのかについてお話したいと思います。

WWDC は async/await で盛り上がっていて Combine ロスなので、Combine について発表したいと思います。

Combine は複数のイベントを扱うのが楽だったり、debounce operator などを利用した時間を制御するような処理も容易に記述できるので、有用なシーンはまだまだあると個人的には思っています。
しかし、Combine を使って時間の制御などを行い始めるとテストが難しくなっていきます...

このトークでは、そんな Combine を使ったコードのテスト方法と仕組みについて以下のような内容で発表したいと思っています。

・ViewModel 内で Combine を利用するコードの基本的なテスト方法
・combine-schedulers というライブラリによって Combine の時間を操りテストを劇的に改善する方法（より正確なテスト・テストの実行時間の削減が可能）
・combine-schedulers の仕組み

発表で紹介させて頂く combine-schedulers は、最近話題になっている The Composable Architecture（TCA） や isowords の作者である Point-Free さんが作っているライブラリで、TCA との相性も良かったりします。

しかし、このライブラリは TCA には依存しておらず、TCA を利用していないコードでも十分に効果を発揮できるものになっています（本トークも TCA に依存しない形式にします）。

さらに、このライブラリには他にも様々な機能があります。
特に UIKit や SwiftUI のアニメーションを操る機能もあるのですが、時間に余裕があれば紹介させて頂きたいと思っています！

SwiftUIではViewが状態を持たなくなることによりシンプルにコードでUIを表現できるようになりました。
しかし状態がなくなったわけではありません。この状態をどう管理していくかが問題になります。

宣言的UIコミュニティでは、状態管理手法について数年さまざまな議論を経て変化を遂げてきました。
その中で一定の答えが出ようとしています。その歴史と現在の回答を説明したいと思います。

本発表でみなさんがシンプルでスケーラブルなコードにより高速にiOSアプリを開発できる体制を構築するお手伝いができたらと考えています。

この発表では、以下について解説します。

• なぜ状態管理のアーキテクチャを考える必要があるのか？
• 宣言的UIの状態管理アーキテクチャの歴史(Flux、Redux、GraphQL)
  • Fluxが提案された根本的な理由と現代における異なる解決手段
  • Redux(The Composable Architecture)のボイラーテンプレートと正規化の課題
• コンポーネントとカプセル化
  • 状態とは何か？
  • 2つのSingle Source of Truth
  • Lifting State Up(State Hoisting)
  • Reducerの必要性
  • 状態の種別と管理方法、状態における新たな認識と捉え方
• 宣言的UI(SwiftUI)と宣言的データフェッチング(GraphQL)によるシンプルなアーキテクチャの実現
  • なぜAPI仕様であるはずのGraphQLが状態管理に関係するのか、クライアントキャッシュ
  • GraphQLとViewModel
  • Fragment Colocationによるスケーラブルな開発
  • RESTのためのクライアントキャッシュ

近年、高性能なサーバーではなくスマートフォンなどのモバイル機器上で機械学習モデルの推論を走らせる、EdgeAIと呼ばれる技術の開発が進んでおり、 TensorFlowLite/MLKit/CoreML/MediaPipe をはじめ様々なモバイル端末向けの推論ライブラリが開発されています。

メルカリでは、動画などストリーミングメディアの推論に特化した MediaPipe というGoogle製のOSSの活用して、カメラをかざすだけで家の中にあるアイテムがいくらで売れるのか知ることができる、「かざして売れるかチェック」という機能を提供しています。

このトークでは、この機能が開発されるまでに遭遇した困難とその解決方法を、大きく3つのトピックに分けてお話していきます。

• BazelでBuildされるMediapipeをiOS Frameworkとして提供する方法
• 推論の計算負荷を減らし、電池消費を抑える工夫
• モデルサイズを小さくしてダウンロードサイズを抑える工夫

従来の iOS アプリ開発では、主に Grand Central Dispatch を用いた非同期計算（イベントループ、マルチスレッド、マルチコア）と、
それらの処理をパイプライン合成可能な単位にラップしたリアクティブプログラミングが主流でしたが、
Swift 5.5 の登場により、いよいよ言語仕様としての async/await と Structured Concurrency が導入されます。

普段、私たちが Swift プログラミングで書く同期的なコードが、 async/await キーワードを付けるだけで、いとも簡単に非同期のコードに変換できてしまう。
さらに、協調的マルチタスクによって、スレッドを大量消費したりブロッキングすることなく、実行途中の関数を一時停止したり再開できる。
まるで魔法のようにも見えるこれらの仕組みですが、その裏側は一体どのように動き、解釈できるのでしょうか？

理論的背景からコンパイラ・ランタイムの実装に至るまで、テーマが非常に多岐に渡るとても奥深い領域ですが、
今回の発表では主に前者について、関数型プログラミングの観点から解説を試みようと思います。

重要なキーワードは、ずばり「モナド」「継続（コールバック）」「コルーチン」。

関数型プログラミング界の三銃士を連れながら、皆様の心の中の継続を呼び起して協調的な発表になるよう目指します。

デスクトップ上やファイル上で右クリックをするとコンテキストメニューが開きますよね。
そのコンテキストメニューに並ぶコマンドを選択すると、ファイルの制御や共有をしたり、特別な操作を行うことができます。

今回はそのコンテキストメニューのコマンドを自作できる Finder Sync Extension について紹介したいと思います。
具体的な実装例の説明を踏まえながら、便利ツールの作り方を学びましょう！
・Finder Sync Extension でできること
・常駐型アプリの作り方
・Finder Sync Extension の実装
・Finder Sync Extension のデバッグ方法

皆さん、こんな経験はありませんか？

• App Storeのアプリページに流入するユーザがインストールしてくれない
• インストール後に何故かアプリを起動してもらえない

ネイティブアプリの広告業界にはApp Store Optimization（ASO）という言葉がありますが、App Size Optimization=アプリサイズの最適化は１つの重要なファクターになっています。

大容量プランが出てきたとはいえ、マスユーザーは常に低速回線、ギガ数の残りと戦ってるのです。

このセッションでは実際にリリースから7年経ってFat IPAとなってしまったアプリを25%以上のサイズ圧縮を行なっていった中で実際に挑戦して効果があったこと、なかったことをお伝えします。

また、App Size Optimizationは圧縮してから始まるといっても過言ではありません。実際に大きな機能をリリースする中で徐々に太っていくことを防ぐことはできるのでしょうか？

アプリサイズが大きくなっていくことを防ぐために私たちが考えたこと、運用上で効果的なアイデアもお伝えします

2020年末、僕たちは「Appのプライバシーに関する質問への回答」の準備に追われていた。この情報が出た当時「アプリ担当者が、収集データと使用目的を調べれば良いよね」と呑気に構えていた僕は、同僚の発言で目が覚めた。

「集めたデータを別チームが分析に使っていたら、どうすれば良いんでしょう？」

弊社の提供する6つのiOSアプリから収集された様々なデータは、BigQueryとLookerが完璧に整えられた社内を縦横無尽に飛び交っていた。このデータ全ての流れを、利用目的を、利用部署を知っている人はいるのか。このトークでは1つ目のトピックとして、この調査プロジェクトについて話そう。

年は明けて2021年、なんとか「Appのプライバシーに関する質問への回答」を終えた僕たちは、広告SDKの更新やATTモーダルの実装を終え、iOS14.5にあわせて無事にリリースしていた。そして数週間後、一通のリジェクト通知が届く。

「XXXをトラッキング目的で使っているなら、ATTで許可をとりなさい。」

そのときようやく気がついた。世間ではATTについて「IDFAを取得できなくなる」点のみ語られていたが、実際はすべてのトラッキング用データに関係していた。普通に考えればApp Tracking Transparencyという名前から分かることだ。同時に思い出した。弊社のBigQueryやLookerには、iOSだけでなく、Android、Webのデータが混在して収集されていることを。そして、一体どれがATTで許可を得たデータなのか、誰にもわからないことを。

このトークでは2つ目のトピックとして、ATTにちゃんと対応するために始まった横断プロジェクトについて話そう。

※このトークでは『この場合はこの対応をすれば正解』といった具体的な例は話しません。

今年の4月、Apple製の紛失防止タグ「AirTag」が発売されました。
AirTagはUWB（超広帯域無線通信）技術が使われていて、高い精度で位置を検知することができます。
このUWB技術を使った空間認識を開発者でも使えるようにするフレームワーク Nearby Interaction について紹介したいと思います。

• Nearby Interaction フレームワークの使い方
• Nearby Interaction フレームワークの使用例
• Nearby Interactionがサードパーティ製アクセサリをサポート（iOS15~）