Slicingとは：動作原理とApp Thinningとの関係

Slicingとは

SlicingはApp Thinningのコンポーネントであり、App Store側でアプリケーションバイナリのバリアント（スライス）を作成する役割を担います。開発者がすべてのサポート対象構成のコードとリソースを含むユニバーサルファットバイナリをアップロードすると、App Storeがそれを分析し、複数のスライスを生成します：A17プロセッサを搭載したiPhone用、M4を搭載したiPad用、Apple Watch用など。各スライスには、そのアーキテクチャと解像度の特定の組み合わせに必要なコードフラグメントとリソースのみが含まれます。

iOS 9以前は、開発者は異なるデバイス向けに手動で別々のバイナリファイルを作成するか、すべてを一度に含むユニバーサルファットバイナリを配布していました。Slicingはこのプロセスを完全に自動化しました：開発者はXcodeで1つのプロジェクトを準備し、App Store Connectに1つのアーカイブをアップロードするだけで、サーバー側のSlicingが最適な数のバリアントを作成します。ユーザーはスライシングプロセスを見ることはありません — 自分のデバイスに最適化された準備済みの.appを受け取ります。

Slicingはコードと画像だけでなく、Metalシェーダーにも適用されます。Apple GPUは独自の命令セット（Metal Shading Language）を使用しており、PowerVRやARM Maliの命令とは異なります。SlicingはターゲットデバイスのGPUファミリーのシェーダーのみをスライスに含めます。これはカスタムシェーダーを使用するゲームで特に重要です — 例えば、高精細な後処理効果は、強力なGPU（iPad Pro M4、iPhone 16 Pro Max）を搭載したデバイスでのみコンパイルされます。

Slicingと単純なアーキテクチャコンパイルの違い

Xcodeコンパイラは複数のアーキテクチャ（armv7、arm64、arm64e）を持つファットバイナリを作成しますが、リソースは削除しません — すべての解像度のすべての画像が.app内に残ります。Slicingはさらに進んでいます：Asset Catalogs、Metalシェーダー、Swiftライブラリを分析し、各スライスから特定のターゲットに不要なものを削除します。例えば、@3xグラフィックスはiPhone SEのスライスには含まれず、iPhone固有のコントローラ（別のリソースに抽出されている場合）はiPad Airのスライスには含まれません。

Slicingの仕組み

SlicingプロセスはApp Store Connectにビルドをアップロードした後に開始され、分析、スライシング、パッケージングの3つの段階で構成されます。分析段階では、App Storeサーバーがバイナリファイルを解析し、サポートされているアーキテクチャ、デバイス、画面解像度、iOSバージョンに関する情報を抽出します。App Storeはすべての市販Appleモデルをその技術仕様にマッピングしたデータベースを使用します — デバイスデータベースはiOSのリリースごとに更新されます。

スライシング段階では、サーバーが各ユニークな組み合わせに対してバイナリファイルの個別のコピーを作成します。これを行うために、App StoreはAsset Catalogsから特定のタグ（idiom、subtype、scale）を持つ画像を抽出し、ターゲットデバイスに一致するものだけを選択し、新しいリソースバンドルをアセンブルします。Swift標準ライブラリもスライシングの対象となり、未使用のシンボルとメソッドが削除されます（デッドコードストリッピング）。

パッケージング段階では、各スライスが個別の配布パッケージに配置され、メタデータ（このスライスが対象とするデバイスモデルのリスト）とリンクされます。ユーザーがアプリケーションをダウンロードすると、App Storeはデバイスモデル、iOSバージョン、接続タイプに基づいて適切なスライスを選択します。正確な一致がない場合、サーバーは最も近い特性のスライスを使用します。AppleはすべてのバリアントをCloudKit CDNネットワークに保存し、世界中に高速配信します。

App ThinningにおけるSlicingの位置づけ

SlicingはApp Thinningの3つのメカニズムの1つですが、ダウンロードサイズの削減に最も貢献します。Bitcodeはマシンコードの最適化を担当し、On-Demand Resourcesはデバイス上のリソース管理を担当し、Slicingは配布段階での冗長なリソースの削除を担当します。Slicingがない場合、最初の2つのメカニズムは機能しますが、ユーザーはすべてのデバイス向けのリソースを受け取り、Asset Catalogsの数に応じてサイズが20–40%増加します。

SlicingとBitcodeの違いは適用ポイントにあります：Slicingはリソースレベル（画像、シェーダー、NIBファイル）で動作し、Bitcodeはマシンコードレベルで動作します。Slicingはコードをアーキテクチャ（arm64 vs arm64e）で分割し、BitcodeはAppleが新しいアーキテクチャ向けにコードを再コンパイルすることを可能にします。Bitcode + Slicingを組み合わせることで最大の最適化が得られます：Bitcodeが特定のアーキテクチャ向けのコードを生成し、Slicingがそのアーキテクチャに不要なリソースを削除します。

On-Demand Resourcesとの関係 — SlicingとODRは重複しません。Slicingはどのリソースがデバイスへの配布に含まれるかを決定し、ODRはこれらのリソースがいつロードおよびアンロードされるかを管理します。開発者はリソースにODRタグを付けることができ、Slicingはそれがデバイスに一致する場合にスライスに含めます。Appleは最小インストールサイズのために3つすべてのメカニズムを同時に使用することを推奨しています。

異なるデバイス向けのSlicingバリアント

Slicingは複数の次元に従って個別のスライスを作成します：プロセッサアーキテクチャ、画面サイズ（解像度）、iOSバージョン、GPUファミリー（Metal用）。アーキテクチャはCPU命令セットを決定します：arm64 — 基本の64ビットセット（iPhone 5s — iPhone X）、arm64e — Pointer AuthenticationとPACをサポートする拡張セット（iPhone XS以降、A12X+搭載のiPad Pro）。arm64e用のスライスには、arm64デバイスでは利用できないメモリ保護命令を含むコードが含まれます。

画面解像度 — Slicingの2番目の主要な次元です。Appleは@1x（iPhone 3GS）、@2x（iPhone 4 — iPhone SE 3）、@3x（iPhone 6 Plus以降）のスケールと、iPad固有（追加メトリクス付きの2xおよび3x）を使用します。Slicingはターゲットデバイスに一致するスケールの画像のみをスライスに含めます。XcodeでAsset Catalogsを適切に整理することで、リソースセットを手動で管理する必要がなくなります — カタログに画像を追加し、サポートするデバイスタイプを指定するだけです。

GPUファミリー — 3番目の次元で、Metalアプリケーションにとって極めて重要です。AppleはGPUを世代別に分類しています：Apple GPU family 1（A7）、family 2（A8）、... family 8（M4）。Metalシェーダーは各ファミリーごとに個別にコンパイルされます。Metal Shading Languageの命令セットはGPUの世代ごとに拡張されるためです。SlicingはターゲットデバイスのGPUファミリーのシェーダーのみをスライスに含め、レンダリングにMetalを使用するゲームやアプリケーションのサイズを大幅に削減します。

スライスサイズに対するアーキテクチャの影響

CPUアーキテクチャはスライスのサイズに直接影響します：arm64eコードには追加のPointer Authentication（PAC）およびSigned Return Address命令が含まれ、arm64と比較してバイナリファイルが5–10%増加します。ただし、この増加はSlicingがarm64eコードをA12+プロセッサ搭載デバイスのスライスにのみ含めるという事実によって相殺されます。A15 Bionicを搭載したiPhone SE（第3世代）の場合、Slicingはこのチップの能力に最適化された個別のスライスを作成します。

XcodeでのSlicing設定

XcodeでのSlicing設定は最小限です — 主要な設定はAsset CatalogsとBuild Settingsを通じて行われます。Asset Catalogには、デバイスタイプ（Any、iPhone、iPad、Apple Watch、Apple TV）ごとに整理されたリソースが含まれ、スケールと表示モードが正しく指定されている必要があります。Xcodeは自動的に、Deployment Target設定で指定されたターゲットデバイスに一致するリソースのみをビルドに含めます。

Xcodeにおける主要なSlicing設定はBuild SettingのApp Thinningです。利用可能な値：

• None — Slicingが無効、アプリケーションはユニバーサルファットバイナリとして配布
• Automatic — Xcodeがデフォルト設定でSlicingを有効化
• Manual — 開発者がSlicingの特定の組み合わせを選択

General → Deployment InfoのTargeted Device Familiesは、アプリケーションがどのデバイスタイプ向けにビルドされるかを決定します（iPhone / iPad / Universal）。Slicingはスライシング時にこのパラメータに依存します — アプリケーションがiPhoneのみをサポートする場合、iPad用のスライスは作成されません。Deployment Target（最小iOSバージョン）もSlicingに影響します：古いiOSバージョンではarmv7スライスが必要になる場合があり、iOS 13+では不要です。AppleはDeployment Targetを最新の安定版iOSに設定することを推奨しています — これによりスライスの数とバイナリサイズが削減されます。

SlicingのためのAsset Catalogパラメータ

Slicingの最大効率のためには、Asset Catalogsが各リソースに固有のタグを使用する必要があります。XcodeはAttributes Inspectorで画像に対して以下を提供します：Width Class（Any、Compact、Regular）、Height Class（Any、Compact、Regular）、Gamut（sRGB、Display P3）、Memory（Any、Low、High）、Graphics（Any、Low、High）。これらのタグを組み合わせることで、開発者は各画像がどのスライスに含まれるかを制御できます。例えば、Regular Width + Regular Heightのタグが付いたiPad画像は、横向きのiPadスライスにのみ表示されます。

# 特定のデバイス用のスライスをエクスポート
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuildは-thinningパラメータとモデル識別子を指定することで、そのモデルのみのスライスを作成します。識別子のリストはAppleのデバイスデータベースにあります（形式：iPhone17,2 — iPhone 16 Pro Max、iPad14,1 — iPad Pro 11 M4）。この方法はApp Store Connectに送信する前にスライスサイズを確認するのに役立ちます。CI/CDは自動検証のためにこのコマンドを使用できます — スライスサイズが制限（例：モバイルダウンロードで100 MB）を超える場合、パイプラインは警告を発行します。

Slicing結果の確認

App Store Connectにアーカイブをアップロードした後、Appleはスライスサイズの詳細な統計情報を提供します。App Store Connect → Activity → ビルドを選択 → App Thinning — デバイスカテゴリごとにEstimated App Store Sizeを表示します：iPhone、iPad、Apple Watch、tvOS。サイズはiOSバージョンとプロセッサタイプ別に分類されます。スライスが予想サイズを超える場合、App Store Connectは黄色の警告でマークします。

Xcode Organizerによるローカル検証：アーカイブ後、Window → Organizerを開き、アーカイブを選択してApp Thinning Profilesをクリックします。Xcodeは現在のプロジェクト構成に基づいて、各可能なスライスのサイズを表示します。特定のSlicingプロファイルでIPAを作成するためのExportオプションも利用できます。Xcodeは各スライスにどのリソースが含まれているかに関する情報を含む.app-thinning.plistファイルを生成します。

CI/CDでSlicing検証を自動化するには、-thinningを指定してxcodebuildを使用し、作成された.appファイルのサイズを分析します。Appleはコマンドラインユーティリティapp-size（Xcode Command Line Toolsからインストール）を提供しており、詳細なレポート（コードサイズ、カテゴリ別のリソースサイズ（画像、シェーダー、NIB）、Swiftライブラリサイズ）を出力します。Asset Catalog最適化前後のスライスサイズを比較することで、誤った設定によりSlicingに参加していないリソースを特定できます。

# スライスサイズを分析
app-size -m "sliced/App.app" \
  --format json

App-sizeはリソースカテゴリ別に分類されたJSONレポートを出力します。Slicingが正しく設定されている場合、「images」セクションには1つのスケールセット（@2xまたは@3x）のみが含まれ、すべてのバリアントは含まれません。Asset Catalogの設定ミスは、すべてのスケール（@1x、@2x、@3x）がスライスに存在する場合に明らかになります — これはXcodeがこれらの画像のターゲットデバイスを特定できず、Slicingが機能しなかったことを意味します。