トーク

iOS 15から、即時通知と呼ばれる新しい通知が導入されました。これは、一定時間内に必ず確認してほしい情報を知らせる際に利用するもので、同じくiOS 15から導入された通知要約や集中モードを突破してユーザーの目に届く強力なものです。便利な反面、乱用するとユーザーに機能そのものをオフにされてしまう可能性があるため、使い所は精査する必要があります。
また、一度プロダクトに導入すると、その便利さ故つい使用箇所を増やしたくなってしまう可能性が高いですが、無論そういうわけにはいきません。安易に強力な通知配信を増やさないためには、開発メンバーの中で同じインプットが必要です。
本セッションでは、一iOSユーザーとして即時通知を受け取ってきて再考する即時通知の使いどころ、実際にプロダクトに即時通知を導入してみて見えてきた、即時通知利用に関して開発メンバーでもつべき共通認識について導入事例と共にお話します。

【概要】
SwiftUIが登場してから３年が経とうとしています。

古いOS対応もあり、すぐに導入できなかったアプリも多かったでしょう。
そんな中、新規のアプリを全てSwiftUIで構成した例も増えてきました。

しかし、現実問題として既存の多くのアプリはUIKitで構成されています。
この資産を活かしつつ、どのようにSwiftUIと歩んでいくのかを考えていく必要があります。

今回はそんな悩みを抱えつつ、私達のプロダクトで行なってきた共存の仕方をご紹介していきます。

【目次】
1.SwiftUIとUIKit
-SwiftUIの強みと弱み
-実装判断の基準
-責務の分け方

2.アーキテクチャー
-既存のアーキテクチャー
-SwiftUIとUIKitのアーキテクチャー共存

3.課題
-共存の向き・不向き
-車輪の再発明
-実装において注意すべき点

※内容が前後する可能性があります

iOS 14まではピクチャ・イン・ピクチャ（以下PiP）を表示させるには動画コンテンツが必要でした。
しかし、新しくiOS 15でPiPのAPIが追加されたことにより動画コンテンツが無いただのUIViewもPiPとして表示させることが可能になりました！

これまでPiPを利用したアプリを3つリリースしてきた経験から、PiPを利用したアプリの開発からリリースするまでについて話したいと思います。

・PiPに好きなUIを表示させる仕組みと実装
・より良いPiP体験の提供
・PiPでできないこと
・Appleの審査を通過する

PiPを使うことでユーザーにより良い体験を与えることができるアプリはたくさんあると自分は感じています。
ぜひこのセッションで得た情報をもとにPiPを使った良いアプリが増えれば良いと願っています！

皆さんはresultBuilderを使った事があるでしょうか。
Swift5.4で導入されたこの技術はConcurrencyの発表で少し影が薄くなりましたが、実は複雑な処理をシンプルかつ宣言的なものに置き換えられるとても便利な技術です。
実際、私たちのチームではこれを用いることで、メンテコストの高い実装部分を大幅に改良する事が出来ました。
本トークではresultBuilderとは何なのか、またどういう効果的な利用法があるのかを実際の導入事例を交えてご紹介致します。
21分後にはあなたも1人前のresultBuilder！

コンテンツ
・resultBuilderとは
・仕組みと実装方法
・プロダクション導入の実例やライブラリの紹介
・高度な活用方法

聞き手の想定
・resultBuilderの存在を知らない方
・存在は知っているけど使い方がわからない方
・活用イメージが湧かない方

0.01秒が結果を左右する陸上競技の世界ではタイムはとても大切なものであり、日々の練習でもストップウォッチは欠かせません。
iPhoneにもストップウォッチがありますが、陸上競技の現場では画面上にあるボタンを押すことの難しさが致命的な欠点となり、実用に耐えないのが現状です。
そんな問題を解決するために音量ボタンで制御可能なストップウォッチアプリを作成したところ、App Store Reviewガイドライン違反で公開が停止…
どうすれば物理ボタンを使わずに全力疾走中でも使えるストップウォッチが作れるのか？
ストップウォッチのUXを最大限に高めるために検証した様々な対策を陸上競技歴15年の私が紹介します。

目次（予定）
・なぜ物理ボタンを使ってはいけないのか？
・実際に作ってみた
a.近接センサーを使う
b.加速度センサーを使う
c.音を使う
d.etc
・結果：一番良いインタラクションは？

アプリで画面を更新するためのトリガーとしてポピュラーなものは

• Pull-to-refreshなどのユーザーの明示的なアクション
• サーバー上などのデータが更新されたタイミング

の2種類に大きく分類できます。

ユーザーの明示的なアクションで画面更新する場合は比較的シンプルに実装することが可能ですが、サーバー上のデータが更新されたタイミングに同期して画面更新を行う場合、更新通知を受け取る方法やUI更新方法など、考慮することが増えて実装が複雑になりがちです。

そこでこのトークでは、リアルタイムでの更新が必要となる具体例を紹介した後に、サーバー上のデータをリアルタイムで同期するための設計/実装について、Firebaseを用いる手法、Push通知を用いる手法、WebSocketを用いる手法など、複数の手法の比較を行い、いかにしてリアルタイムで更新する画面を実装するかの解説を行います。

自分達のアイデアを形にして新しいサービスをラウンチするのは興奮するものですし、さらにそれを軌道にのせてマネタイズするまでのノウハウは開発者の成功の証として世に溢れています。一方、アプリケーションの開発を「続ける」ことは、そのような華々しさとは縁遠く、かつフリーウェアとなれば生計を立てる外でそれを実行する必要があります。
発表者は2014年にOSSのmacOSアプリケーションCotEditorの開発を引き継ぎ、以来おおよそ月に1回のリリースを8年以上続けています。OSS開発を続けるということはどういうことなのか、どうモチベーション維持をするのか、このトークではそんなCotEditorプロジェクトを続けている哲学を紹介します。以下のような話を含みます：
・開発の基本方針
・開発を続けるモチベーション
・ユーザからのフィードバックとの付き合い方

iPhoneが登場して以降、QRコードを読むという行為はありふれた行為となりました。

iOSにおいては

• 古くからカメラからのインプットを扱えるAVFoundationを用いて
• 新しくは画像解析フレームワークであるVisionを用いて
  QRコードを読むという機能は比較的簡単に実現できます。

しかし、QRコードを読み込むシーンというのはアプリによって様々です。

例えば

• １つのQRコードをしっかり読み込みたい
• リッチな表現でQRコードを読み込みたい
• 夜や倉庫の中といった暗い場所でもQRコードを読み込みたい
• 連続で複数のQRコードを読み込みたい
  などなど。

本セッションではシーンに応じてQRコードを気持ちよく読み取るためにした工夫をお話します。
頻繁に使う機能だからこそ体験の良いQRコード読み込みを実現していきましょう！

近年、SRE（Site Reliability Engineering）の手法をアプリケーションにまで拡大しようといった動きが盛んです。

しかし、実際にモバイルアプリの可観測性≒オブザーバビリティを向上させるためには、ネイティブエンジニアの専門性が求められる場面が多く、あまり実際に効果のあった事例が共有されていないように感じます。

このトークでは

• アプリ内で計測される指標を用いてSLI / SLOを構成する
• アプリ内でのレスポンスのパースエラー検知
• 問い合わせ調査のオブザーバビリティ向上
• 外部SNSの認証サービスの障害検知
• App Store Connect API 、MeticKitの活用

といった実際にチームで効果のあったプラクティスを紹介したいと思います。

LINE iOSは、200万行を超えるソースコードと200以上のモジュールで構成されている大規模なプロジェクトであるため、そのビルド時間も長くなりがちです。

私達はビルド時間の改善の一環として、Bazelを取り入れました。その結果、ビルド速度が2倍になるというメリットを享受しましたが、メンテナンスコストが増大するというデメリットにも直面しました。

このセッションでは2年間Bazelを使い続けて分かったBazelの長所やリスク、運用時の注意点、そしてLINE iOSのビルド環境の現状と今後についてご紹介します。

Wantedly では、「デザインの生産性を向上させ、デザイナ - エンジニア 間コミュニケーションを改善することで、ユーザに価値を届ける速度を向上させる」ことを目的として UI デザインシステムを作っています。

今回は現場で運用されているデザインシステムと iOS 実装の成功と失敗について以下の内容を話します。

• Wantedly の UI デザインシステムとはなにか
• コンポーネントリストではなく「共通の考え方とツール&アセット」
• Figma 実装から考える iOS 実装のインターフェース設計
• チームへの普及の成功と失敗

iOSのビルド環境はXcodeやSwift Package Managerのアップデート、新しいMacの登場などによって毎年変化を遂げています。
サービス提供を開始した2015年から現在に至るまで、これらの変化に合わせて継続的にビルド環境の改善が行われてきました。
本セッションでは2021年以降に実施したビルド環境の改善についてご紹介し、今後の目指す姿についてお話いたします。

• Swift Package Managerの活用とライブラリ整理
• Apple Silicon対応
• マルチモジュール化
• ビルド時間改善

昨年、Swift Concurrencyが導入されました。当初はiOS 15のみでサポートされていましたが、Concurrencyのback deploymentが実現されたため、iOS 13以降であれば今すぐにでもConcurrencyを取り入れることができます。

しかし、実際にConcurencyを取り入れようとすると、参考となる情報はまだまだ少ないのではないでしょうか。Conccurency自体の情報は豊富でも、iOSアプリ開発での活用、特にactorや単体テストなどについてはほとんど語られていないように思います。

本トークでは、iOSアプリ開発におけるConcurrency活用の一つのベースラインとなることを目指して、async/awaitやTask、actor、MainActorなどを、アプリやテストのコードにどのように取り入れるか、具体例を用いて紹介します。

WWDC 2019 で発表された PencilKit を利用することで、数行のコードで 標準メモアプリと同様の手描き体験をアプリに導入できます。

発表に先立ち、日本経済新聞社の紙面ビューアーアプリでは、Apple Pencil を用いた紙面画像にメモやハイライトを書き込める機能をリリースしました。

アプリの機能要件を満たすための独自拡張の実現には、様々な制約が立ちはだかりました。
たとえば、キャンバスに画像を載せる、ズームやスクロールなどビューアーとしての操作は残しつつ書き込みを一時的に無効にするなど、一見すると単純そうですが一筋縄ではいきません。

本セッションでは PencilKit の開発ノウハウを、ドキュメントと内部の動きから洞察した知見の両面から解説します。開発経験を踏まえ、紙の新聞に書き込みを行うユーザー体験をどのようにアプリへ落とし込んでいったか説明できればと思います。

SwiftのWebAssembly対応を進めている、SwiftWasmというプロジェクトがあります。

現在、WebAssemblyはWebブラウザ上の用途だけでなく、「複数言語からコンパイルできて様々な環境で動く高速なプログラム」として、エッジコンピューティングやIoT、ブロックチェインにおけるスマートコントラクトなど、様々な分野で用途が模索されています。

もし将来的にWebAssemblyが覇権を取った場合、そこでSwiftが活躍できるポジションはあるのでしょうか？

このトークでは、Wasm対応によって達成できる未来、プロジェクトの最新状況と課題、実際の活用事例を紹介したいと思います。
Appleプラットフォーム以外でのSwiftの活用に興味のある方には、特に楽しんで頂ける内容になる予定です。

Reactの思想であるLearn Once, Write Anywhereを推し進めるため、React内部にはReactをどこでも動かせるようにするreact-reconcilerというパッケージが存在します。

react-reconcilerはReact DOMやReact Nativeで利用されているUIの差分検出処理のパッケージで、JSXで書かれたコンポーネントのマウントや更新通知を受け取れます。これを使って独自のレンダラーを作ってみましょう。

このトークでは、react-reconcilerのレンダラーをSwift(UIKit)で実装して自分だけのReact Nativeを作る方法について話します。

ここでの「行動ログ」とは、特定の画面の表示、ボタンのタップなど、ユーザー操作を起点に送信するものを指します。集めた行動ログは、サービス開発上の分析や実態把握に役立ちます。

アプリ開発者は、そのログを仕込む役割を担いますが、しばしば課題にぶつかります。

• いざ分析するとき「ログが足りない！」
  • 「QA時にログ送信、網羅した？」
  • そもそもログ要件が十分に練られていない……
• ……

本セッションでは、行動ログにまつわる悩みの種のうち、ログ実装の「仕込み」にフォーカスして、ミスを防ぐ仕組みや工夫の事例をご紹介します。

トピック

• ドキュメントをベースにした型安全なログ実装コード自動生成
• iOS 14以降で使いやすくなった Logger APIの活用
• QA作業を踏まえたログ実装網羅チェッカー

など

ARKitが持つ多くの機能の中でも、みなさんはフロントカメラとバックカメラを同時に使用することによるフェイストラッキングとワールドトラッキングの並走機能をご存知でしょうか？実はこの機能、Human Computer Interaction（HCI）の研究者たちの注目を集めたアツい機能なんです。この機能により、視線を向けるだけで目の前のコーヒーメーカーがコーヒーを淹れてくれるような、これまでにスマートフォン1台ではできなかった体験を実現することが可能となりました。
本トークでは、この並走機能に新たな可能性を感じた私が実際に作ったいくつかのサンプルアプリの紹介やそこで得られた知見の共有をします。

・視線を向けるだけで電気を点けたり、コーヒーを淹れられるアプリ
・目からビームを発してヴィランをやっつけるアプリ
・ユーザが暗い表情をしていると、辺りに花が咲きほこるアプリ

iOS15からユーザー間でのやりとりのための新しい通知、Communication Notificationが導入されました。
そうです、通知にユーザーのアイコンが出るあの通知です。

UIが変わったり、通知の要約を突破できたりと普通の通知よりも便利なこともある一方、Siriに関する知識が必要になってきます。
しかしSiriに関してはドキュメントも知見も少なく、その割に設定する項目も多く、敷居が高いイメージもあるのではないでしょうか？
そもそもなぜ通知の実装にSiriが出てくるのでしょうか？

このトークではCommunication Notificationの実装方法、Communication Notificationを実装する上でのSiriの知識、及びよくやってしまいがちなCommunication Notificationのアンチパターンなどを紹介していきます。

例えばTwitterアプリでは、ツイートに押したいいねは他のどの画面に表示される同一のツイートにも反映されています。
このような体験を実現する上で、グローバルステートとして状態を管理する手法がしばしば用いられ、iOSアプリ開発でもReduxから派生するTCAが例として挙げられます。

しかし、そもそもこのグローバルステートで管理する大抵の状態はサーバーからのレスポンスであることから、WebフロントエンドではReact QueryやSWRを筆頭にサーバーデータのキャッシュによる状態管理が流行しつつあります。

そこで本トークでは、SwiftUIを用いたiOSアプリ開発におけるサーバーデータのキャッシュによる状態管理のアーキテクチャについてお話しします。