トーク

過去のiOSDC Japanでも何度か話していますが、私はWebにおけるXR技術であるWebXRを強く推しています。

WebXRとSafariの相性は良くなく、フラグが追加されたかと思いきや、実際には使えないことが多く、なぜSafariでWebXRを楽しめないのかというモヤモヤを抱えてきました。しかし、ついにApple Vision Proが登場しました。
この新しいデバイスのSafariは、iPhoneのSafariとは異なり、WebXR Device APIに対応しています。

AppleはSpatial computingという表現を用いていますが、関連するものとしてSpatial Webもあります。
私はSafari on Apple Vision ProでSpatial WebとWebXRがついに花開く、そう思っていました。

しかし、現時点でのSafari on Apple Vision Proにはまだいくつかの制約があります。
これらの制約が解消されると、理想的なWebXR体験が可能になるでしょう。

本セッションでは、Safari on Apple Vision ProにおけるSpatial WebとWebXRの現状について詳しくお伝えします。
Webが好きで、WebでXRを楽しみたいと考えている“Web屋”の皆さんに向けた内容を予定しています。

Transform from a coder who simply follows instructions to a true engineer who innovates and satisfies customer needs on your own. Learn from my journey transitioning from iOS development to mastering some other areas. Also, discover how to broaden your skills and evolve into roles like tech lead, manager, consultant, freelancer, or founder of a new company creating your own products and services. This session provides real-life experiences and strategies to improve your career and truly become an engineer, who can survive next 10 years.

Xcode Previewsを使用することで即座にレイアウトや動作確認ができ、開発効率を向上させることができます。しかし、依存関係が複雑なプロジェクトでは通常のビルドと変わらないくらい時間がかかってしまいます。
SwiftPMによるマルチモジュール化により、Previewビルドの時間を短縮することもできますが、大規模なプロジェクトでは複数の開発が並行して行われているため、即座に対応することは難しいです。

高速化のための簡易的かつ効果的な方法として、Preview用のTargetを作成する方法を紹介します。依存ファイルを減らすことでビルド時間の短縮を狙いますが、単にTargetを設定するだけではうまくいかない場合が多いです。本トークでは、そこで発生する問題に焦点を当て、具体的な解決策を提案します。

以下について話します。

• Previewビルドを早くするためのいくつかの方法
• Preview用のTargetを用いてビルド時間を短縮する方法
• 依存関係が複雑なプロジェクトに適用した時に生じた問題点とその解決策

自分が担当しているアプリではSwiftPMによるマルチモジュール化をせず、この方法を用いることで、約120秒かかっていた初回のPreviewビルドが約23秒になりました。本トークを通じてPreviewのビルド時間を短縮し、よりスピーディな開発環境を構築してみませんか？

「Simulatorアプリでマウススクロールを使えたらいいな」
普段アプリ開発をしている中で、このようなことを思ったことはありますでしょうか？

Simulatorアプリで画面をスクロールするには、マウスのドラッグ＆ドロップで操作する必要があります。
慣れてしまえばなんてことないですが、マウスをいちいち動かすのは地味に不便です。

本LTでは、この問題をmacOSのCore Graphicsの機能で解決していきます。
Core Graphicsを使えばユーザイベントを変換することができ、擬似的にSimulatorアプリ上でマウススクロールを使うことができます。

「Core Graphicsなんてグラフィック系のライブラリでしょ？」と思ったら大間違い。実はユーザイベントにも深い関わりがあるんです。
あなたの知らないmacOSのハック術、お教えします。

Swift Concurrencyは、非同期処理やマルチスレッド処理を便利にするSwiftの新機能です。iOSアプリ開発において、ゼロからこの機能を利用する場合は比較的スムーズに導入できますが、既存のアプリに導入する際にはさまざまな課題が発生します。

我々のチームでは、すでにリリースされているアプリにSwift Concurrencyを全面的に導入しました。まず、API通信のような非同期で結果が返る処理をasync/awaitに変換することから始めました。その過程で、ActorやMainActorの利用も行いました。また、非同期処理にまつわる問題を厳密にチェックするため、SWIFT_STRICT_CONCURRENCYオプションを有効にし、その結果に対する対応策も講じました。

その過程で遭遇した具体的な問題とそれに対する対策の実例を紹介します。

Swift コードの品質を向上させるためには、コードベースが大きくなるほど自動化が不可欠です。CodeQL は GitHub が開発した静的解析ツールで、コードベース全体を検査して脆弱性やエラーを検出することができます。たとえば、データを安全でない方法で利用する、関数に危険な引数を渡す、機密情報を漏洩するなどの、コードにおける潜在的なセキュリティ問題を検出することが可能です。現在は、GoやPython、C++といった様々な言語がサポートされています。

この CodeQL、なんと Swift もベータサポートされています！本LTでは、CodeQL を用いて Swift コードの脆弱性とエラーを検出する方法を紹介します。

現在最新の Swift 5.10 にも対応しています。しかし、いくつかドキュメントにない対応が必要となります。それらを紹介するにあたって、自身のOSSアプリを公開する際「秘匿情報書いたりしてないかな.....」とドキドキしながら公開ボタンを押してどうなったか！！という小話と共に紹介します。

コストがかかって大変ですが、おざなりにはできないセキュリティチェック。まずは数行の設定を書くだけで利用できる便利なCodeQLをみなさんも始めてみませんか？みんなでフィードバックしていくことで安全な Swift コードを増やしていきましょう。

本セッションでは、App Store Server APIやApp Store Server Notificationsというアプリ内課金のバックエンドで用いられるApple提供の仕組みの仕様や実装を紹介します。
特にNotificationsはStoreKit2と同じタイミングでバージョン2といえる抜本的な改善がされており、2024年の今も安定して機能追加やApple公式のOSSライブラリも提供されるようになりました。

課金機能がアプリで完結しないケースでは、StoreKit2に加え様々な基盤と相互に連携する必要があります。たとえば有料機能のための認証・認可API、ユーザー分析、iOSアプリ内課金以外の決済手段との連携です。
これらを実現する上で、クライアントの環境・操作内容に依存せずリアルタイムに更新を受信できるバックエンドの機構は依然重要です。しかし、アプリ内課金のバックエンドの仕組みはあまり世間に公開されていません。日本経済新聞社の電子版アプリで提供するサブスクリプションをStoreKit2に合わせてフルリプレースして得られた知見を紹介します。

このトークを通して、参加者は通常目を通すことが少ないアプリ内課金のバックエンド側の最新動向を学ぶことができます。システム全体を把握して、バックエンドチームと連携する際にも効果的に役立つ Tips が学べるセッションとなります。

iOS 15から導入されたStoreKit2はアプリ内課金の実装を大幅に簡略化できます。オファー機能や複数のプラン提供を行いやすくするために導入・移行を検討している方は多いのではないでしょうか。
ただし課金機能がアプリで完結しない場合、StoreKit2と様々な基盤を連携する必要があります。たとえば有料機能の認証・認可API、課金ユーザー分析、iOSアプリ内課金以外の決済手段が挙げられます。

そのためのバックエンド構築にはApp Store Server APIやApp Store Server NotificationsというApple提供の仕組みが使えます。近年バージョン2といえる抜本的な改善がなされ、アプリ内課金の状態を自社サービスから詳細に分析できるようになりました。

本セッションでは、日本経済新聞社の電子版アプリで提供するサブスクリプションをStoreKit2ベースでフルリプレースして得た知見を紹介します。各種ツールの仕様・アプリ内課金全体の仕組みを理解、クライアントからバックエンドまでどのような手順で安全にアップデートしていくか注意点を確認しつつ解説します。クライアントだけでは把握しづらかった課金状態をAPIで把握したTipsも紹介していきます。

このトークを通して、参加者は自社のシステムにアプリ内課金を連携するための実践的な仕様を理解することができるでしょう。

みなさん、UIWindowというクラスについてご存知でしょうか。

グローバルに画面最前面に要素を表示するHUD(Head up display)の実装を行う際などにUIWindowを用いることがよくあります。しかし、通常の開発で直接触ることは少ないためUIWindowについてあまりよく理解せずに使われていることも多いのではないでしょうか。

例えばUIWindowにおける表示順はUIViewのsubViewsにおける表示順などとは少し異なっているため注意が必要です。 isKeyWindow がtrueなUIWindowが最前面であると思われたり、 UIApplication.shared.windows の順番がUIWindowの表示順であると思われたりしがちですがどちらも間違っています。

また、複数のUIWindowを表示している際のステータスバーの挙動にも一癖あります。特定の画面でステータスバーを非表示にしたいようなケースでUIWindowの特性をちゃんと把握していないと意図した挙動を実現できないことがあります。

このトークではUIWindowがどういうものなのか、UISceneやUIViewとの関係性を踏まえて話しつつ、UIWindowの表示に関する挙動や利用する際の注意点について紹介します。

みなさん、UIWindowを最前面に表示したい時どのように表示を行なっていますか？

多くの方が makeKeyAndVisible() を使っているのではないでしょうか。Developer Guideにも 「自身の windowLevel 以下のUIWindowの中で最前面に表示できる便利メソッド」であることが明記されています。

しかし、同時にDeveloper Guideには「表示だけであれば isHidden プロパティを false にすればよい」とも書いてあります。

makeKeyAndVisible() によってUIWindowが keyWindow となるため keyWindow なUIWindowが最前面のUIWindowであると思われがちですが実際にはそうではありません。

この理解が曖昧だと「キー入力は受け付けたいが最前面に表示したくない」といったケースで困ったり、「 makeKeyAndVisible() を呼んでいるのに別のUIWindowが最前面になってしまった」というケースで困ることがあります。

このLTではUIWindowの表示順決定方法について紹介しつつ、 makeKeyAndVisible() で何が起こっているのか紹介します。

目的:

Swift標準ライブラリやサードパーティツールを使用した、iOSアプリ開発における様々なノイズ除去技術を紹介し、　最高品質の音声録音を実現するための方法を紹介します。

内容:

1. Swift標準ライブラリ
   AVFoundation, CoreAudioなどのSwift標準ライブラリを使ってできるノイズ除去手法の紹介と簡単な実装例を紹介します。
2. サードパーティツール
   世の中に存在するノイズ除去が可能なツール、 高度なAIを活用したノイズ除去用サードパーティライブラリをいくつか紹介したり、それぞれの利点、実際にどれぐらいノイズを除去できるのかのライブデモ、利点の比較などを行います。
3. ライブデモ
   実際にノイズ除去技術を利用して録音した音声を、ノイズ除去していないもの、Swift標準ライブラリでノイズ除去したもの、サードパーティーライブラリでノイズ除去したもの、複数のツールを組み合わせたものなどを実際に聴いて比較し、最強のノイズ除去ベストプラクティスを決定します。

みなさんはCore Audioを利用してiOSで音声を扱ったことはありますか？
iOSではCoreAudioをはじめ、AVAudioPlayer/AVAudioRecorderやAVAudioEngineなどさまざまな音声を扱うAPIが存在しますが、どのAPIを使ってどのような音声処理ができるのか？を語られることは少ないと思います。

このセッションでは、オーディオデータの取得と処理技術、リアルタイム録音技術、再生技術を学び、iOSアプリケーションのオーディオ機能を強化するための実践的な例とベストプラクティスを紹介します。

本セッションを聴き終わった際にはあなたもiOSで音声処理を試してみたくなることでしょう

1. Core Audioの理解:
   • Core Audioのアーキテクチャの概要
   • iOSオーディオスタックにおけるCore Audioの役割
2. オーディオデータの取得と処理:
   • オーディオデータの取得方法とその処理
   • サンプルレート、ビット深度、チャンネル数の基本概念
3. 高度なオーディオ技術:
   • リアルタイムオーディオ録音の実装:
   • 効率的なバッファ管理とデータ転送
   • 音声エフェクトの実装と管理
   • オーディオエフェクトの追加と調整
4. 実践的な例とデモ:
   • 実際のコードを用いたデモ
   • 実践的なサンプルプロジェクトの紹介

アクセシビリティは、すべてのユーザーにアプリを利用してもらうための重要な要素です。

このセッションでは、SwiftUIを使用してアクセシブルなiOSアプリを構築するための具体的な技術と知見を紹介します。具体的には、以下のポイントについてお話します。

VoiceOverの設定 - 視覚障害者向けのナビゲーション補助。
Dynamic Type対応 - ユーザーがテキストサイズを調整できる機能。
カラーコントラストの最適化 - 色覚多様性に対応したデザイン。
インタラクション要素の設計 - タッチやジェスチャーの使いやすさの向上。

このセッションを通じて、アクセシブルなアプリ開発のための具体的な知識とスキルを習得しましょう。

皆さん、バイナリ形式で配布されるSDKがx86_64のシミュレータしか同梱されていない状況に困ったことはありませんか？
本トークでは、実機向けバイナリをARM64シミュレータ向けに変換する作業を通じて、アプリのバイナリを解析する手法を紹介します。
具体例としてLive2D Cubism SDKを取り上げ、必要なツール（lipoとotool）、バイナリ解析の基礎、バイナリ変換手法、動作確認までを丁寧に解説します。

• バイナリ変換の基本概念と必要なツール（lipoとotool）の紹介
• ARM64バイナリをシミュレータ対応のバイナリに変換する手順
  • Mach-Oバイナリの基本構造の理解
  • 必要なコマンドの置き換え
  • オフセットの再計算方法
• 変換したシミュレータ対応バイナリをLive2D Cubism SDKに組み込み
• iOSシミュレータでの動作確認

基本的なiOS開発の経験があれば十分です。ARM64アーキテクチャに関する知識やバイナリ解析の経験がなくても問題ありません。

このトークを通じて、バイナリ解析の楽しさを少しでも伝えられればと思います。お楽しみに！

UndoManagerは、アプリにUndo・Redo機能を提供してくれる強力なクラスです。
特にnote アプリのようなエディタアプリにとって、Undo機能は必須の機能の一つといえます。
しかし、意外とUndoManagerを使いこなしているアプリは少ないのが現状です。

本トークでは、UndoManagerの基礎から、実際のアプリへの導入方法、そしてその際のはまりポイントまで、実体験に基づいて解説します。

[内容]

1. UndoManagerの概要とUndo・Redo方法
2. 導入時に遭遇したはまりポイントと解決策

一緒にUndoManagerをマスターし、アプリのユーザー体験を次のレベルへ引き上げましょう！

noteのiOSアプリにはこれまでUndo/Redo機能がありませんでした。しかし、この春にUndoManagerを導入しUndoに対応しました。

UndoManagerは、アプリにUndo・Redo機能を提供してくれる強力なクラスです。
特にnote アプリのような編集アプリにとって、Undo機能は必須の機能の一つといえます。
しかし、意外とUndoManagerを使いこなしているアプリは少ないのが現状です。

本トークでは、UndoManagerの基礎から、実際のアプリへの導入方法、そしてその際のはまりポイントまで、実体験に基づいて解説します。

[内容]

1. UndoManagerの概要とUndo・Redo方法
2. Undoのグルーピング機能
3. note アプリへのUndoManager導入
4. 導入時に遭遇したはまりポイントと解決策
5. UndoManagerを使ったテストの書き方

一緒にUndoManagerを使いこなし、アプリのユーザーエクスペリエンスを向上させましょう！

スクロール。
それはUI操作の核とも言えるジェスチャーの一つであり、それを実現するためのフレームワークもまたiOSアプリ開発において欠かせない存在です。

しかし、SwiftUIのScrollViewはiOS13で登場した当初、非常に使いづらいものでした。
基本的なスクロールの機能は提供されていたものの、カスタマイズ性に乏しく、UIScrollViewで実現できた多くの動作を再現することは困難でした。

しかし時は2024年。iOS17の登場でScrollViewも進化を遂げました！

このセッションでは、iOS17で追加されたmodifierを中心に、SwiftUIのScrollViewがどのように進化したのかを具体的な例を交えてご紹介します。

技術カンファレンスは様々な方がそれぞれの形で貢献し作り上げるイベントです。
公式サイトや公式アプリはイベントの内容や方針がよく表れるものであり、その開発はITエンジニアならではの貢献のひとつです。
オープンソース化されているものならば使用されている技術も必見です。iOSアプリエンジニア、もしくはAndroidアプリエンジニアとしてソースコードを読んだり実際に開発に参加したりした方も多いでしょう。
毎年ゼロから開発している公式アプリであればその年の最新の設計や流行のライブラリを窺い知る貴重な資料になります。

本ポスターセッションでは、カンファレンスの公式iOSアプリを通してカンファレンスについて考えます。

ポスターに掲載する内容

• 各カンファレンスのイベント内容の紹介
• アプリのコンテンツ内容や設計の紹介
• OSS開発の運営体制や技術領域の考え方の紹介

対象カンファレンス

• iOSDC Japan 2023（「fortee」「名札交換」）
• DroidKaigi 2023
• FlutterKaigi 2023
• try! Swift Tokyo 2024

このポスターセッションが技術領域の垣根を超えた交流やカンファレンスへの貢献の促進につながれば幸いです。

みなさんの会社ではUIKitからSwiftUIへの移行をどのように進めていますか?
また、移行の際に既存のシステムアーキテクチャをどう扱えば良いか悩んでいる方も多いのではないでしょうか。

私たちのiOSアプリ「note」では、VIPERというアーキテクチャを採用しています。
VIPERはiOSアプリ開発にクリーンアーキテクチャの一種で、View、Interactor、Presenter、 Entitiy、 Routingなどに責務を分割するアーキテクチャです。

本セッションでは、noteのiOSアプリにおいて、UIKitからSwiftUIへの移行した際、どのようにVIPERアーキテクチャと向き合っていったかを共有します。

1. SwiftUIにおけるVIPERアーキテクチャ採用の理由
2. Viewレイヤー以外の変更点
3. 移行時の課題とその対処方法

多くの現場でUIKitからSwiftUIへの移行が進んでいるかと思いますが、このセッションでは実務で得た具体的なノウハウをお伝えし、皆様のプロジェクトに役立てていただければと思います。

WWDC21でTextKit 2が発表されました。NSTextLayoutManagerを中心とした新しいテキスト操作へのアプローチは無限の可能性を感じさせた一方で、その実用には多くの困難が伴います。本セッションではそんなTextKit 2を使うことで、テキストとレイアウトの柔軟な関係を実現し、テキスト操作の限界に挑みます。