トーク

VideoToolBoxは、AVPlayerなどが属するAVFoundationのさらに低位のレイヤーで、動画の圧縮（エンコード）や伸張（デコード）を行います。AVPlayerは非常に優秀なため、ほとんどの場合、VideoToolBoxを直接利用する必要はありません。しかし、MPEGの構造を理解し、VideoToolBoxを使って特殊再生を行うことで、AVPlayerがどれほど複雑な処理を行っているかを垣間見ることができます。

このトークでは、カメラで撮影した映像ファイルをVideoToolBoxで再生し、スキップ、シーク、倍速再生などの特殊再生を行う方法を解説します。また、なぜそのような処理が必要になるのか、MPEGフォーマットの重要なポイントについても説明します。

Webフロントエンド開発からiOSアプリ開発への移行は、技術的な視点のシフトが必要となります。例えば、Webフロントは主にDOMベースの操作が中心ですが、iOS開発ではユーザーのタッチ操作など直接的なインタラクションが求められるため、iOSのネイティブAPIなどに対して知見が必要です。
このようににSwiftUIとWebフロントエンド技術（Next.js）の比較を通じて、SwiftUIの特性とWeb開発者にとっての利点・欠点を掘り下げます。

本トークでは以下の三点について重点的に取り上げます。

1.SwiftUIのファーストインプレッション： Webフロントエンド技術者が初めてSwiftUIを使った際の直感的な感想と具体的な違いをまとめます。
2.機能比較： React.js, Next.jsとSwiftUIで開発した場合の違いを比較します。特にタッチ操作やジェスチャーの応答性、アニメーションの実装のしやすさなど、直接的なユーザーインタラクションが重要な要素としてどのように扱われるかを見てみます。
3.コミュニティサポート：それぞれの開発者コミュニティの規模感や活発さについて取り上げます。

本トークにより、Webフロント技術者以外にも今までiOS開発にあまり触ってこなかった方々がSwiftUIを利用した開発に興味を持つきっかけを提供できれば幸いです！

モバイルクロスプラットフォーム技術でシェアを拡大しているFlutterですが、既存アプリを一気に乗り換えるのはコストがかかります。Flutterには「Add-to-app」という画面単位でFlutterを組み込む仕組みが用意されており、これを利用することでリスクを抑えつつFlutterを導入することができます。

「Add-to-App」を利用することで、コストを押さえつつクロスプラットフォームの導入を小さく始める事ができます。

しかし、良いことばかりではありません。例えば以下のデメリットも存在します。

・OS毎に別々のUIデザイン適応が困難
・Flutter(Dart)有識者不足
・サードパーティ製パッケージへの依存

Flutter 1.0がリリースされてから5年が経った今、実際に「Add-to-app」を使用してFlutterを導入する中で判明したメリットとデメリットを詳しく紹介します。特に導入時の課題や注意点についても触れ、Flutter導入を検討している開発者にとって役立つ情報を提供します。

カメラアプリを開発する際、広角カメラ（builtInUltraWideCamera）でQRコードやレシートなどの小さな被写体にピントを合わない問題があります。

従来のiPhoneでは最短撮影距離が10cmでしたが、最新のiPhone 15では15cm、iPhone 15 Proでは20cmと、カメラの進化に伴い最短撮影距離が増加しています。このため被写体に近づきすぎるとピントが合わずボケてしまいます。

Appleの標準カメラアプリは被写体との距離に応じて自動的に最適なカメラを切り替える機能を持っていますが、自作のカメラアプリではこの機能が自動で提供されません。そこで開発者が対策を講じる必要があります。

このセッションでは、小さな被写体を撮影する際の対応方法を紹介します。
具体的には最短撮影距離から被写体に最適なカメラ設定を行う方法を詳しく解説します。これによりカメラアプリ開発者がユーザーに高品質な撮影体験を提供できるよう支援します。

iOSアプリ開発において自動テストは一般的になってきています。
しかし、どういった自動テストを用意すればいいのか、このテストは本当に価値を発揮できているのかと、不安に思うことはありませんか？

その不安を解消する手段として「ミューテーションテスト」を使ってみてはどうでしょうか。
ミューテーションテストは、プロダクトコードを意図的に変異させ、テストコードが適切に失敗するかを確認することで、自動テストの有効性を評価するテスト手法です。

とはいえ、多くのテストを実行するため、実行時間が大きな課題となります。
しかし、近年のマシンスペックの向上やXCTestを取り巻く環境の進化により、ミューテーションテストの実施が現実的になってきました。

本トークでは、ミューテーションテストの基本的な概念とその利点を説明し、さらに実行時間を短縮するための具体的なアプローチについて紹介します。

具体的には、「muter」というライブラリがおこなっているアプローチを元に、実行時間を短縮するための工夫を紹介します。
加えて、ミューテーションテストを実行した際の実行時間や出力結果を基に活用法を紹介します。

これにより、iOS開発における自動テストの価値を最大限に引き出す方法を学んでいただけることを目指します。

【ご案内】

• SwiftUIを使ってUIの異変を見逃さないこと
• 異変を見つけたら、すぐにUIKitを利用すること
• 異変が見つからなかったら、SwiftUIを使い続けること
• SwiftUIとUIKitのメリットとデメリットを理解し、最適なアプローチを選ぶこと

iOSアプリ開発において、SwiftUIを利用することで直感的で効率的なUI構築が可能になります。
しかし、時にはSwiftUIに固執することで、開発が行き詰まることもあります。そんな時はUIKitの力を借りることが有効かもしれません。
本LTでは、上記の案内をもとに、SwiftUIとUIKitを使い分ける8つのパターンを解説します。

「WebView内でもログイン状態を維持してください」

アプリ開発をしていると、WebViewを使うことはよくあると思います。
WebView内でログイン状態を維持する方法には、大きく「RequestHeaderにAuthorizationトークンを使用する方法」と「Cookieを使用する方法」の2つがありますが、どちらがより良い方法なのでしょうか？

このトークでは、WKWebViewを用いてユーザーのログイン状態を維持する方法として、上記2つのアプローチについて徹底解説します。
両者を比較し、それぞれのメリット・デメリットを説明したのち、セキュリティ重視や実装の簡便さなど、具体的なケーススタディを通じて最適な選択を議論します。

これらの知識を通じて、参加者はWKWebViewでのログイン状態維持におけるベストプラクティスを学び、自分のプロジェクトに即座に適用できる実践的な知識を得ることができます。
初心者から中級者まで、幅広いレベルの開発者にとって役立つ内容を提供しますので、ぜひご参加ください。

内容:

• WKWebViewとは
• RequestHeader　/ Cookies の説明
• RequestHeaderを用いたログイン情報の維持、そのメリット・デメリット
• Cookiesを用いたログイン情報の維持、そのメリット・デメリット
• まとめ

私は事業用クレジットカードを提供するサービスに携わっており、カードや利用明細を閲覧・管理するiOSアプリを開発しています。
自社でも導入しているため、自分もそのアプリのユーザーです。

アプリではカード番号等をコピーでき、決済ページへの情報入力の際に便利です。
しかし各情報をタップしてコピーする度に「コピーしました」というアラートが表示されます。
アラートはOKボタンをタップして消えるため、カード番号コピー→OKタップ→名義人コピー→OKタップ、とユーザーの連続した動きを中断させてしまいます。

開発時は気にしていませんでしたが、ユーザーの自分は「このアラート邪魔…作ったの誰…」と私自身の実装に対し文句を言うのでした。
そうしてこのアラートが不要だと気づいた私は、ユーザーの操作を妨げずにコピーしたことを伝えようと決めました。

このトークではそのようなユーザーへのフィードバックに、不要なアラートを使わないためのアイデアをお話しします。

はじめに、Apple社製のものをはじめとした様々なアプリにおいて、類似した状況で用いられるフィードバックを調査した結果をまとめます。SwiftUIに無い一時的に表示するバナーの実装や、その為のライブラリの使用は大仰に感じ、まずは事例調査をしました。
その後、プロトタイプの実装やデザイナーとの相談を経て冗長なアラートを取り除くまでの流れを紹介します。

SF Symbolsが発表されてからしばらく経ちますが、私の所属組織ではいまだPDFでのアイコン作成／iOSアプリへの取り込みが主流でした。また開発観点から見ても、5,000以上の多様なアイコンをあらかじめ揃えたSF Symbolsの活用は、スピードの求められるグロース開発とも相性がいいことがわかっているのに、適用の下準備が整っていませんでした。

そこで今年、開発側のSF Symbols利用の土台作りとともに、デザイン側のカスタムシンボル作成のワークフロー整備をおこないました。

このポスターセッションでは、カスタムシンボルを使ったオリジナルアイコンの作成方法や、SF Symbols.appへのSVGデータの取り込み／加工のデザインワークフローの作成、更にデザイナーとエンジニア間のデータのやり取り方法を整備した事例を紹介予定です。

実際にデザイナーがSF Symbols.appを利用してみると思わぬ落とし穴にハマったり、想定外の動きをしたりしました。また、アイコン作成者（デザイナーごと）に依存する形状のブレが生じないよう、Adobe Illustratorのガイド機能を利用したプロセス調整なども行っています。これらの整備をする上で、SF Symbolsに込められたVariablesの思想なども見えてきたため、Tipsもまとめます。

ここにトマトがあります。
このトマトを、幅を指定して切るメソッドについて考えてみましょう。

extension Tomato {
  public func slice(width: Double)
}

トマトを3cm幅でカットする際は、以下のように書けば良さそうです。

tomato.slice(width: 3)

さてここで、メソッドのシグネチャからwidthを省略したら、メソッドを使う側にどう伝わるでしょうか？

tomato.slice(3)

「トマトを3cm幅でカットする」ではなく、「トマトを3つにカットする」と伝わってしまうかもしれません。

Swift の API Design Guidelinesは、明確で一貫性のあるコードを書くための指針を教えてくれます。しかし、その抽象的な概念を理解し、日々のコーディングに適用するのは難しい場合があります。

本LTでは、身近な「野菜」を使って、これらのガイドラインの理解を深めていきます。野菜を使うことで抽象的な概念を具体的なイメージとして捉え、より実践的な知識として吸収し、より良いコードが書けるようになることを目指します！

現在担当しているアプリはメインの導線に関してはSwiftUIに移行を完了しました。
SwiftUIへの移行とあわせてSwiftUI Previewを活用して開発とフィードバックのループを高速化し業務に活用しています。

iPadでのUIの活用やダークモードとライトモードの確認に非常に効果的なSwiftUI Previewですが、なかなかクセが強いところもあり
Previewがうまく実行されなかったり、実行に時間がかかってしまったりと、快適に使っていくためには工夫して使っていく必要があります。

それらを踏まえ、このトークでは我々が行っているSwiftUI Previewドリブンな開発、
SwiftUI Previewを快適に活用しながら実装していく為にしていることを紹介させていただきます

具体的なアジェンダは以下のとおりです

• SwiftUI Previewドリブンな開発とメリット
• マルチモジュールな設計とSwiftUI Preview
• 徹底的に依存を排除する
• 限りなく小さい単位でビルドする

Gradleのプラグインとして開発されたAmperというプロジェクトを構成するためのツールが登場しました。
AmperはKotlin Multiplatform（KMP）のプロジェクトを構成することを前提としています。
従来のGradleファイルを用いて構成する場合と比べ、構成ファイルがシンプルになるため、特にiOSアプリ開発者への恩恵は大きいです。

本LTでは、Amperに関する知見を共有いたします。
以下の内容を中心にお話しします。

• Amperの基本的な機能とその利点について
• Amperを使ったKMPプロジェクトの具体的な構成方法
• module.yamlの書き方とその役割
• Fleetでのmodule.yamlに関するコードアシスタンスの利用方法
• Kotlin MultiplatformおよびCompose Multiplatformプロジェクトの具体的な構成方法

このLTを通じて、参加者の皆様がAmperを使ったKMPプロジェクトの構成方法を理解し、実際のプロジェクトに活用できるようになることを目指します。

過去の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のビルド時間を短縮し、よりスピーディな開発環境を構築してみませんか？

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 が学べるセッションとなります。

みなさん、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標準ライブラリでノイズ除去したもの、サードパーティーライブラリでノイズ除去したもの、複数のツールを組み合わせたものなどを実際に聴いて比較し、最強のノイズ除去ベストプラクティスを決定します。