iOS 27でレスポンシブなカメラアプリを構築する

Appleのカメラパフォーマンスチームは、プレビュー出力以外のすべてを遅延させることで、カメラの起動時間を半分に短縮しました。1秒近くかかっていた起動が、ラボのライトボードで計測しておよそ半分、つまり2倍の改善になったのです¹。その梃子となるのが、iOS 26以降で利用できるDeferred Start APIであり、その背後にある原理は明快です。カメラの起動を速く感じさせる上で最も重要な要素は、プレビューフレームがどれだけ素早くディスプレイに表示されるかなのです¹。

この記事の軸は「AVFoundationアプリが瞬時に使えると感じさせるために何をすべきか」です。技術的には動いているカメラと、使う準備が整ったと感じられるカメラとの差は、まさに倒れていくドミノがすり抜ける隙間そのものだからです。WWDC26の3つのセッションがこのテーマを扱っています。レスポンシブな起動と持続的なキャプチャを扱うセッション303、レスポンシブ性を損なわずに高解像度キャプチャを行うセッション304、そして新しいスクエア型Center Stageフロントカメラを扱うセッション341です。いずれも同じキャプチャセッションのアーキテクチャを通じてつながっているため、1つを採用すれば他の採用コストも下がります。

TL;DR

• 起動シーケンスは4段階（アプリ起動、セッションの構成と開始、出力の初期化、プレビューのストリーミング）から成り、その大半の時間を出力の初期化に費やします。Deferred Startはプレビューをレンダリングするもの以外のすべての出力を後回しにし、Appleのラボ計測で起動時間を半分にします¹。
• AVCaptureVideoPreviewLayerベースのアプリは、iOS 26以降でリコンパイルするだけで自動的なDeferred Startを無償で得られます。video-data-outputのアプリは、同じ恩恵を得るために手動モードを採用する必要があります¹。
• 写真出力を遅延させてもプレビューは速くなりますが最初のキャプチャは速くなりません。そのためAVCapturePhotoOutputのisResponsiveCaptureEnabledと組み合わせ、処理の準備が整うまでショットをバッファリングしましょう¹。
• iOS 27で新登場したPro Video Storageは、システム全体のストレージプールを事前に確保することで、高データレートのProRes書き込みがファイルシステムの競合でつまずくことなく、決定論的に保たれるようにします¹。
• Center Stageフロントカメラ（iPhone 17、iPhone Air、iPhone 17 Pro）は、フロントの.builtInUltraWideCameraとして公開されるスクエア型センサーです。dynamicAspectRatioを使えばセッションを再構築せずにスクエアから任意のアスペクト比を切り出せ、AVCaptureSmartFramingMonitorがAuto ZoomとAuto Rotateを駆動します²。

起動シーケンスは4段階に分かれる

AppleのカメラパフォーマンスチームのエンジニアであるJakeが、セッション303で4つの起動段階を解説しています。

カメラの起動は4つの段階を経て進みます。AppleのエンジニアJakeがそれらを順に分解しています¹。まずアプリが起動します。リンカがバイナリをロードし、静的イニシャライザが実行され、UIシーンが生成されます。次にセッションが構成され、開始されます。AVCaptureSessionの初期化、構成のコミット、セッションの開始のいずれもが時間とシステムリソースを消費します。3番目に、すべてのAVCaptureOutputが初期化されますが、その時間は出力の数とその品質設定に応じて増えていきます。4番目に、プレビューがストリーミングを開始し、フレームがアプリへと流れ込みます¹。

これを速くするための作業はUIから始まります。起動を2つのフェーズに分けましょう。プレビューの表示に不可欠なリソースと、プレビューが動き始めた後まで待てるリソースです¹。AVFoundationの定番サンプルカメラアプリであるAVCamでは、起動した瞬間に必要なのはカメラプレビューとシャッターボタンだけであり、イメージウェルやモードピッカーは後からフェードインさせれば十分です。この原理はUIにとどまりません。プレビューがレンダリングされる前に生成されるリソースはすべて、起動時間に上乗せされるのです¹。

次の負荷ポイントはセッションそのものです。AVCaptureSessionはすべてのキャプチャオブジェクトを統括するため、JakeはメインスレッドでのUIセットアップが終わり次第、まずこれを生成します。ただしセッションの生成はメインスレッドをブロックするので、その生成はメインスレッド外にディスパッチし、UIシーンのセットアップと並行して実行してハングを避けます¹。同じ注意はstartRunning()とstopRunning()にも当てはまります。どちらもブロッキング呼び出しであり、メインスレッドで呼び出すとアプリがハングします¹。複数回にわたってコミットするのではなく、最初に1つの構成をコミットしましょう。再構成のたびに起動時間が延びるからです¹。

Deferred Start: 2倍の勝利

出力の初期化は起動の中で最もコストの高い部分ですが、その瞬間においてほとんどの出力は無駄な重荷にすぎません。プレビューをレンダリングするには、アプリにはプレビューレイヤーか単一の出力だけがあれば十分であり、ムービーファイル出力や写真出力は最初のフレームに何ら寄与しません¹。Deferred Startはこの点を突きます。出力の初期化を起動が完了するまで先送りするので、最初のフレームが表示される前に初期化されるのはプレビュー出力だけになります¹。

すべてのAVCaptureOutputとAVCaptureVideoPreviewLayerはisDeferredStartEnabledプロパティを持っています。その出力を遅延させるにはtrueに設定し、プレビューをレンダリングするもの以外のすべてを遅延させましょう¹。遅延した処理をいつ実行するかを決める方法には2つのモードがあります。自動モードでは、システムが最適なタイミング、つまりプレビューが表示された直後を選び、アプリが追跡できるように2つのデリゲートコールバックを発火します。初期化の開始前のsessionWillRunDeferredStartと、完了後のsessionDidRunDeferredStartです¹。iOS 26以降のSDKでリコンパイルしたアプリは、デフォルトで自動モードになり、automaticallyRunsDeferredStartはすでにtrueに設定されています¹。

// Automatic mode — defer everything but the preview layer
session.beginConfiguration()
session.automaticallyRunsDeferredStart = true      // true by default on iOS 26+ SDK

photoOutput.isDeferredStartEnabled = true           // defer the photo output
// videoPreviewLayer renders preview, so it is NOT deferred

session.commitConfiguration()
session.startRunning()                              // call off the main thread

手動モードは制御をアプリに戻します。automaticallyRunsDeferredStartをfalseに設定し、先に済ませる必要のある起動作業（設定の読み込み、重要でないUIの構築）を行ってから、runDeferredStartWhenNeeded()を呼び出してシステムに進めてよいと伝えます¹。手動モードが特に効いてくるアーキテクチャが1つあります。AVCaptureVideoDataOutputでプレビューをレンダリングするアプリです。Deferred Startはデータ出力には自動的には適用されないため、こうしたアプリは手動のDeferred Startを採用して同じ起動の恩恵を得ます。一般には最初のフレームが提示された時点でトリガーします（JakeはCAMetalLayerを通じて提示を追跡しています）¹。

Appleはこの結果をラボのライトボードで検証し、拡大していくLEDパターンをキャプチャする2台の電話機を比較しました。Deferred Startを有効にした電話機は、赤と緑のLEDが両方点灯している間にパターンを捉えました。有効にしなかった電話機は、緑のLEDがほぼ消えかかってからようやく起動を終えました¹。計測すると、Deferred Startなしの起動は1秒近くかかり、ありの場合は起動が半分に、つまり2倍の改善になりました。複雑なキャプチャセッションではそれ以上の改善も見られます¹。

破壊的な変更はまとめてグラフを一度だけ再構築する

起動シーケンスにおける単一構成の規律の背後には、WWDC26のラボパネルに登壇したカメラエンジニアが説明したメカニズムがあります。AVCaptureSessionはキャプチャオブジェクトのグラフを統括しており、破壊的な変更を強制するプロパティを設定するたびに、セッションはそのグラフを再解決します⁵。再構成は通常、写真モードから動画モードへの切り替えや、アクティブなフォーマットを低い解像度へ落とすなど、複数のことを一度に変えることを意味するため、各プロパティを個別に設定するとステップごとにグラフが再構築されてしまいます⁵。バッチ全体をbeginConfiguration()とcommitConfiguration()で包めば、バッチに含まれる変更が1つでも20でも、グラフはコミット時にちょうど1回だけ再解決されます⁵。パネリストはこのペアを銀行取引になぞらえました。beginConfiguration()が取引を開き、引き出しと預け入れは保留のまま留まり、commitConfiguration()がそれらをまとめて確定するというわけです⁵。

Deferred Startは、もう1つの起動前の梃子とすっきり組み合わさります。パネルは、Deferred Startとprepared-photo-settings配列（AVCapturePhotoOutputのsetPreparedPhotoSettingsArray(_:completionHandler:)）が直交的かつ補完的であることを確認しました。一方は出力の準備を遅延させてプレビューを先に表示させ、もう一方は最悪ケースの静止画パイプラインのリソースを事前に確保するもので、競合なく組み合わせられます⁵。

速いプレビューは速いキャプチャではない

写真出力を遅延させることには、はっきり述べておくべき落とし穴があります。プレビューは大幅に早く始まりますが、最初のキャプチャまでの時間は変わりません。キャプチャを開始する前に、システムは依然として遅延した写真出力の初期化を終える必要があるからです¹。プレビューは表示され、ユーザーがシャッターをタップしても、その瞬間はもう過ぎ去ってしまっているのです。

その解決策がAVCapturePhotoOutputのisResponsiveCaptureEnabledです。このプロパティは、キャプチャの開始と処理の開始との間にバッファリングを追加するので、写真出力が完全に準備できていなくてもその瞬間を捉えられます¹。Appleのドミノのデモでは、Deferred Startと並んでレスポンシブキャプチャを動かした電話機は倒れるドミノをきれいに撮影できた一方で、対照側の電話機は完全に撮り逃しました¹。この組み合わせが推奨されるパターンです。品質重視の写真出力でDeferred Startを採用して起動を速く保ち、写真出力が初期化を終えるまでの間をレスポンシブキャプチャでカバーさせるのです¹。

連射の高解像度キャプチャ

AppleのCamera SoftwareチームのエンジニアであるMohitが、セッション304でバスケットボールコートを舞台にfast capture prioritizationを実演しています。

セッション304は、レスポンシブ性の話を高解像度の連写へと広げます。そのメカニズムがAVCapturePhotoOutputのisFastCapturePrioritizationEnabledです。これは新しいプロパティではなく既存のものですが、有効にするとシステムは短時間に連続する複数のキャプチャを検出し、写真品質を最高品質設定からバランス重視へと適応させます。バランス重視はキャプチャと処理の双方に必要な時間が少なくて済みます⁴。新しい部分はOSとともに登場します。iPhone 16とiPhone 17でiOS 27からは、システムはそれらのバランス重視のfast captureを、後からdeferred photo processingを使って処理するようにもなります。これはWWDC23由来のバックグラウンドパイプラインで、次のキャプチャをブロックせずに写真を仕上げます（上で述べたDeferred Startの起動APIとは別物です）⁴。Appleのバスケットボールのデモでは、deferred processing、レスポンシブキャプチャ、fast capture prioritizationのすべてを有効にすると、同じプレーについてキャプチャが1枚ブロックされる対5枚のレスポンシブなショット、という差になりました⁴。

同じセッションは高解像度の対応表も更新します。24MPと48MPのキャプチャ対応は、iPhone 16 Proの望遠カメラとiPhone 17の超広角カメラに拡大し、18MPのオプションはiPhone 17のCenter Stageフロントカメラにのみ存在します⁴。prioritizationの設定が、何をリクエストできるかを左右します。12MPは3つのprioritizationレベルすべてで使え、単一フレームの48MPはバランス重視か品質重視が必要であり、マルチフレーム合成の18MPと24MPのフォーマットは処理時間が長いため品質重視のprioritizationを要します⁴。deferred processingこそが、レスポンシブなアプリでこれらのマルチフレーム合成を実用的にするものです。重い作業がバックグラウンドで、キャプチャセッションとメモリを共有せずに行われるからです⁴。

プレビューのレンダリング: レイヤーとデータ出力

プレビューを駆動できる出力は2つあり、その選択によって他にどれだけの作業が必要になるかが決まります。AVCaptureVideoPreviewLayerは、アプリ側でフレームごとの作業をすることなく、カメラが見ているものをそのまま表示します。HDRのトーンマッピングを自動で処理し、CPUとGPUのオーバーヘッドを低く抑え、低遅延表示向けにチューニングします¹。トレードオフは、フレームごとのアクセスを提供しないことです¹。（その自動トーンマッピングのHDRの側面については、AVFoundation HDRとApple Logの記事がキャプチャと表示のパイプラインを詳しく扱っています。）

AVCaptureVideoDataOutputは、フレームごとの処理が優先される場合の代替手段です。プレビューレイヤーに代わって主要な表示出力となり、フレームの流れをアプリが制御できるようにします。フレームごとのカスタムUIオーバーレイ、Metal連携、フレーム解析などです¹。その代償は、上で触れた手動Deferred Startの採用に加え、もう1つの規律です。フレームドロップを避け、体験を滑らかに保つために、フレームごとの作業は短く済ませることです¹。フィードを表示するだけならプレビューレイヤーを使い、実際にフレームを処理するならデータ出力に手を伸ばしましょう。

負荷の下でパフォーマンスを持続させる

カメラ開発のほとんどは、制御された環境のデスクで行われます。しかし人々は暑く晴れた日にアプリを使い、デバイスが熱を持つにつれてシステムはスロットリングします¹。2つのコストAPIによって、アプリはそれが来るのを察知できます。ハードウェアコストは、使用中のセッションのハードウェアの割合を表す0から1の値を返します。1を超えるとシステムはその構成をサポートできません¹。コストはカメラの数、アクティブなフォーマット（1080p対4K）、フレームレート、そしてフォーマットがビニングされているかどうかとともに上昇します。ハードウェアコストはフォーマットの最大フレームレートを前提とするため、60 fpsのフォーマットで30 fpsで動作するアプリは、報告されるコストを下げるためにフレームレートのオーバーライドを設定すべきです¹。

システムプレッシャーコストも0から1を返し、現在の状態のコストを表します。1を超えると構成は持続不可能になります¹。採用のパターンはこうです。構成のコミット後、ハードウェアコストが1以下に保たれていることを確認し、それからAVCaptureDeviceのsystemPressureStateを監視して変化のハンドラを登録します¹。プレッシャーが高まるにつれ、ハンドラはキャプチャデバイスのフレームレートを下げ、GPUやApple Neural Engineの作業をスロットリングし、UIの作業を最小化します¹。

Pro Video Storage: 決定論的なProRes書き込み

セッション303では、高データレートの動画キャプチャ向けに、iOS 27で新登場したPro Video Storageが紹介されています。

従来のファイルシステムI/Oは非決定論的です。システムは競合する操作、メモリの断片化、ストレージの摩耗をやりくりするため、書き込みのタイミングは変動します¹。ProResのような高データレートのキャプチャは、フレームを落とさずに記録するために持続的な高帯域幅のI/Oを必要とし、タイミングの変動はまさに望ましくない性質です。iOS 27で新登場したPro Video Storageは、高データレートのキャプチャ向けに事前確保したストレージを追跡・管理することでこの問題に対処します。これはすべてのアプリが共有するシステム全体のリソースであり、既存のムービー記録APIに組み込まれます¹。

アプリは、AVCaptureMovieFileOutputのusesProVideoStorageを、あるいはvideo data outputから記録する場合はAVAssetWriterのusesProVideoStorageを設定してオプトインします¹。するとストレージが割り当てとファイルI/Oを処理し、高データレートのコーデックでも書き込みパフォーマンスを一貫して保ちます。採用の手順はこうです。Pro Video Storageはシングルトンなので、その共有アクセサを通じて取得し、対応していることを確認します。ムービーファイル出力、セッション、接続、選択したフォーマットを構築します。ムービーファイル出力のisProVideoStorageSupportedを確認します。ストレージがリサイズやファイルの作成・削除の処理でビジー状態でないことを確認します。そのうえで有効にして記録を開始します¹。キャプチャ中、記録は事前確保したプールに書き込まれ、キャプチャが終わると最終的な場所へ移されます¹。カメラ設定では、どれだけのストレージを割り当てるかをユーザーが制御できるようになり、remainingCapacityメソッドが残量を報告し、open-settingsメソッドがアプリからそのUIへユーザーを案内します¹。

Center Stageフロントカメラはスクエア型

AppleのCamera SoftwareチームのエンジニアであるTracyが、セッション341でスクエア型のCenter Stageフロントカメラを紹介しています。

従来のフロントカメラのセンサーは4対3のアスペクト比を持ち、フレーミングを電話機の向きに縛り付けていました。iPhone 17、iPhone Air、iPhone 17 ProのCenter Stageフロントカメラは、スクエア型のイメージセンサーを95度のレンズと組み合わせており、iPhoneのフロントカメラとしては最も広い視野を備えています²。AppleのエンジニアTracyはその利点をこう説明します。スクエアの形状によってユーザーは任意のアスペクト比を選べるようになり、電話機を回転させずに縦向きや横向きのセルフィーを撮影できます。これにより片手でのしっかりしたグリップと、中央に収まり自然なアイコンタクトの取れた映像が保たれるのです²。

セッションのセットアップは標準的なAVFoundationです³。AVCaptureSessionを生成し、カメラをフロントの.builtInUltraWideCameraデバイスタイプを持つAVCaptureDeviceとして見つけ、それをAVCaptureDeviceInputで包み、プレビュー用のAVCaptureVideoPreviewLayerと写真用のAVCapturePhotoOutputを追加します。セッションは互換性のあるメディアタイプ同士の間にAVCaptureConnectionを暗黙的に形成します²。

その構成要素となるのが、iOS 26から利用できるAVCaptureDeviceのdynamicAspectRatioです。このプロパティを設定すると、セッションを再構築したりプレビューを中断したりすることなく、スクエアセンサーから選んだアスペクト比を切り出せるので、切り替えはシームレスです²。このプロパティは、1280から4032までのスクエアフォーマットで5つのアスペクト比（3x4、4x3、9x16、16x9、1x1）に対応します。ただし1つの制約があり、4032の写真フォーマットは3x4と4x3のみに対応します。これらが最高解像度を維持するからです²。

// Tap to Rotate using dynamicAspectRatio
let discovery = AVCaptureDevice.DiscoverySession(
    deviceTypes: [.builtInUltraWideCamera],
    mediaType: .video,
    position: .front
)
guard let device = discovery.devices.first else { return }

// Find a format that supports the desired ratio
guard let format = device.formats.first(where: {
    $0.supportedDynamicAspectRatios.contains(.ratio4x3)
}) else { return }

try device.lockForConfiguration()
device.activeFormat = format
let timestamp = device.setDynamicAspectRatio(.ratio4x3)  // returns first-buffer timestamp
device.unlockForConfiguration()

各フォーマットは自身のsupportedDynamicAspectRatiosを公開しており、比率を設定すると、その変更が有効になる最初のバッファのタイムスタンプが返ります²。返されるタイムスタンプは飾りではありません。動画記録においては、それが1つのクリップを終え、次のクリップを新しいアスペクト比で開始するための継ぎ目になるのです。

Auto Zoom、Auto Rotate、そしてセンサー補正

AVCaptureSmartFramingMonitor（iOS 26以降、カメラから取得）はdynamicAspectRatioの上に乗り、Auto ZoomとAuto Rotateを駆動します²。このモニターは、自動的な顔と視線の検出から定期的なフレーミングの推奨を与えます。各推奨にはアスペクト比とズーム倍率が含まれ、アプリは適用することも無視することもできます。写真キャプチャを対象とするため、推奨を行うのは4032の写真フォーマットがアクティブなときに限られます²。デフォルトでは何も推奨しないので、enabledFramingsを設定し（すべてのsupportedFramings、または選んだサブセットに）、それからrecommendedFramingをkey-value observeして各推奨を適用します。滑らかな遷移のためには順序が重要です。先にアスペクト比を設定し、それからズーム倍率を設定します²。モニターはセッションの実行中に開始できます。自動フレーミングをオフにするには、KVOの登録を解除してstopMonitoringを呼び出します²。

新しいセンサーには、正しさにまつわる落とし穴が1つあります。それ以前のiPhoneフロントカメラはセンサーをLandscape Leftで取り付けていたため、縦向きのセルフィーはネイティブのセンサー向きで届き、再生時に270度の回転を求めるEXIFタグを持っていました。Center StageセンサーはPortraitで取り付けられているため、古い回転値に依存するアプリは写真を横向きや上下逆さまにレンダリングしてしまいます²。AVCapturePhotoOutputはデフォルトでセンサー方向補正によってこれを処理します。HEIC、JPEG、非圧縮の処理済み写真を物理的に回転させ、EXIFメタデータを更新することで、出力が以前と同じLandscape Leftに収まるようにし、既存の回転ロジックがそのまま機能し続けるようにします²。注意点が2つあります。補正はBayer RAWやApple ProRAWには決して適用されないこと、そしてAppleは最良のパフォーマンスのために補正をオフにして（cameraSensorOrientationCompensationEnabledを介して）テストし、向きが正しいままであることを確認するよう推奨していることです²。

動画と通話でのCenter Stage

動画記録ではdynamicAspectRatioは同じように機能しますが、QuickTimeのムービートラックはすべてのサンプルが同じ寸法を共有することを要求するため、キャプチャの途中で比率を変えると記録が停止します²。AVCaptureMovieFileOutputでは、変更時に記録が自動的に停止します。AVCaptureVideoDataOutputとAVAssetWriterの組み合わせでは、setDynamicAspectRatioの完了タイムスタンプが、1つの記録を終えて新しい比率で別の記録を始めるためのカット地点になります²。記録はまた、このカメラで2つの顔認識シネマティック手ぶれ補正モード、cinematicExtendedとcinematicExtendedEnhancedを得ます。これらは背景よりも被写体を安定させることを優先します²。

ビデオ通話が最もシンプルな経路です。Center Stageは、Voice over IPのバックグラウンドモードを使う会議アプリではすでにアクティブで、コントロールセンターのVideo Effectsメニューからユーザーが切り替えます²。そのバックグラウンドモードを持たないアプリは、Center Stage APIを直接採用します。これはプロセスごとに有効化され（Portrait、Studio Light、Gesturesと同様）、コントロールモードを設定し（アプリ内ボタンを許可するcooperative、またはapp）、それからisCenterStageEnabledをtrueに設定すると、フレーミングが全員を中央に保ちます²。ビデオ通話のもう1つのアップグレードはデフォルトでオフで出荷されます。リアルタイムの低遅延手ぶれ補正モードで、接続のpreferredVideoStabilizationModeをlowLatencyに設定して有効化します²。

採用のガイダンス

3つのセッションは、段階的な採用に報いてくれます。

すべてのAVFoundationカメラアプリへ: まずDeferred Startを採用しましょう。AVCaptureVideoPreviewLayerでプレビューをレンダリングし、iOS 26以降のSDKでリコンパイルするなら、自動モードが無償でオンになります。automaticallyRunsDeferredStartがtrueであること、そしてすべての非プレビュー出力がisDeferredStartEnabled = trueであることを確認して検証しましょう¹。写真出力のisResponsiveCaptureEnabledと組み合わせて、速いプレビューが使えるシャッターでもあるようにします¹。

データ出力とMetalパイプラインへ: 無償の恩恵からは外れます。手動のDeferred Startを採用し、最初のフレームが提示された後にrunDeferredStartWhenNeeded()をトリガーし、フレームごとの作業を短く保ちましょう¹。systemPressureStateの監視を組み込み、熱を持ったデバイスでパイプラインが段階的に劣化するようにします¹。

ProResと高データレートの動画へ: iOS 27でPro Video Storageを採用し、持続的な書き込みを決定論的にしましょう。記録の前にisProVideoStorageSupportedとビジーチェックでゲートします¹。

iPhone 17 / Air / 17 Proのフロントカメラとセルフィーアプリへ: フロントの.builtInUltraWideCameraを見つけ、dynamicAspectRatioを通じてTap to Rotateを公開し、Auto ZoomとAuto RotateのためにAVCaptureSmartFramingMonitorを重ねましょう。オフにする理由を計測で確かめたのでない限り、センサー方向補正はオンのままにし、それがRAWには決して触れないことを忘れないでください²。

FAQ

Deferred Startは実際にどれだけ起動を速くしますか?

Appleはラボのライトボードでおよそ2倍速いと計測しました。1秒近くかかっていた起動が、Deferred Startを有効にすると約半分に下がり、複雑なキャプチャセッションではそれ以上改善することもあります¹。この恩恵は、最初のフレームの前にプレビュー出力だけを初期化し、他のすべての出力をプレビューが表示された後まで遅延させることから生まれます¹。

Deferred Startは自動的に得られますか?

アプリがAVCaptureVideoPreviewLayerでプレビューをレンダリングし、iOS 26以降のSDKでリコンパイルするなら、はい。自動モードがオンになり、automaticallyRunsDeferredStartはデフォルトでtrueです¹。AVCaptureVideoDataOutputでプレビューをレンダリングするアプリは自動的には得られず、同じ起動の恩恵を得るには手動のDeferred Startを採用する必要があります¹。

Deferred Startを使っても最初の写真がまだ遅いのはなぜですか?

写真出力を遅延させてもプレビューは速くなりますが最初のキャプチャは速くなりません。キャプチャを開始する前に、システムが依然として遅延した写真出力の初期化を終えるからです¹。AVCapturePhotoOutputのisResponsiveCaptureEnabledを設定してキャプチャをバッファリングすれば、写真出力が完全に準備できる前でもその瞬間が記録されます¹。

コードでCenter Stageフロントカメラを見つけるにはどうすればよいですか?

.frontの位置で.builtInUltraWideCameraデバイスタイプをリクエストするAVCaptureDevice.DiscoverySessionを使います。Center Stageフロントカメラは、iPhone 17、iPhone Air、iPhone 17 Proでそのフロントの超広角デバイスとして公開されます²。そこからdynamicAspectRatioを設定すれば、セッションを再構築せずにスクエアセンサーから対応する任意のアスペクト比を切り出せます²。

古いフロントカメラの回転ロジックは新しいセンサーで壊れますか?

壊れる可能性があります。Center Stageセンサーは歴史的なLandscape Leftではなく、Portraitで取り付けられているため、補正されていないバッファは横向きや上下逆さまに見えてしまうからです²。AVCapturePhotoOutputはHEIC、JPEG、非圧縮の処理済み写真（RAWは決して含みません）に対してデフォルトでセンサー方向補正を適用するので、cameraSensorOrientationCompensationEnabledを無効にしない限り、既存の回転値はそのまま機能し続けます²。

Apple Ecosystemクラスター

この記事はカメラとキャプチャのレーンに位置づけられます。プロ向け動画のキャプチャと表示のためのAVFoundation HDRとApple Logのワークフロー、キャプチャがアプリのアーキテクチャのどこに収まるかを示すiOSアプリの3つのサーフェス、プレビューをホストするUIレイヤーを扱うSwiftUIは何でできているか、そしてどの機能がどこに来るかを示すAppleプラットフォームマトリクスです。ハブはApple Ecosystemシリーズです。AIエージェントを伴うiOSの文脈については、iOS Agent Developmentガイドをご覧ください。

参考文献