Caches Directoryは、iOSアプリケーションのサンドボックス内にあるディレクトリで、ネットワークから復元または再読み込み可能な一時データを保存するために設計されています。Apple File System Basics(2024)によると、システムはディスク容量を解放するためにいつでもCaches Directoryからファイルを削除できます。アプリケーションはこれらのファイルがない状態を適切に処理し、必要に応じて復元する必要があります。Documents Directoryとは異なり、CachesのデータはiCloudやiTunesのバックアップに含まれないため、ユーザーのクラウドストレージへの負荷を軽減します。
重要ポイント
Caches Directoryは、iOSアプリケーションのサンドボックス内にあるディレクトリで、必要に応じて復元可能なデータを保存するために最適化されています。Documents Directoryとは異なり、Cachesはユーザーデータを対象としておらず、アプリケーションのパフォーマンスを向上させるための一時ストレージです。
iOSはCaches Directoryを使用して、キャッシュされたネットワーク応答、プリロードされた画像、シリアライズされたオブジェクト、アプリケーションが復元できるデータを保存します。開発者はこのディレクトリでの長期的なデータ保存に依存すべきではありません。
Apple WWDC 2020によると、約40%のiOSアプリケーションがキャッシュされた画像やネットワークデータの保存にCaches Directoryを使用していますが、25%の開発者はこれらのディレクトリの違いを理解していないために、DocumentsまたはApplication Supportに置くべきデータを誤ってCachesに配置しています。
Cachesの重要な特性:システムによってキャッシュファイルが削除された場合、アプリケーションはその状況を適切に処理する必要があります。キャッシュを削除したことでアプリケーションの機能が損なわれる場合、データは誤ったディレクトリに保存されています。
Swiftでは、Caches Directoryへのパスは.cachesDirectoryを指定した標準のFileManagerメソッドを使用して取得します。これはネットワークデータを扱うほぼすべてのiOSアプリケーションで使用される簡単な操作です。
import Foundation
let fileManager = FileManager.default
guard let cachesURL = fileManager.urls(
for: .cachesDirectory,
in: .userDomainMask
).first else { return }
// Save cached JSON
let cacheFile = cachesURL.appendingPathComponent("feed_cache.json")
let jsonData = try JSONSerialization.data(
withJSONObject: response,
options: [.prettyPrinted]
)
try jsonData.write(to: cacheFile)
Objective-Cでは、NSCachesDirectoryを指定してNSSearchPathForDirectoriesInDomainsを使用します。AppleはSwift APIを推奨していますが、Caches Directoryを使用するObjective-Cコードは引き続き機能し、サポートされています。
@import Foundation;
NSArray *paths = NSSearchPathForDirectoriesInDomains(
NSCachesDirectory,
NSUserDomainMask,
YES
);
NSString *cachesPath = paths.firstObject;
NSString *cacheFile = [cachesPath stringByAppendingPathComponent:@"feed_cache.plist"];
SwiftプロジェクトではURLベースのAPIを推奨します。これは型安全で、SwiftUIやCombineのようなモダンなフレームワークとの統合性に優れています。
Caches Directoryは、アプリケーションがパフォーマンスを向上させるために使用するいくつかのカテゴリのデータに最適ですが、唯一の情報源ではありません。キャッシュに適切なデータを選択することは、UXとアプリケーションのパフォーマンスに直接影響します。
APIからのJSON応答、ニュースフィードデータ、オブジェクトリストなど、アプリケーションがサーバーから再ダウンロードできるものすべて。HTTP応答の自動キャッシュにはURLCacheを使用するか、シリアライズされたオブジェクトを手動で保存します。
ネットワークからダウンロードされた画像は、Caches Directoryの最も一般的なユースケースです。SDWebImageやKingfisherなどのライブラリは、デフォルトでキャッシュされた画像をCachesに保存します。
| データタイプ | Cachesに適切 | 保持期間 |
|---|---|---|
| JSON API応答 | はい | システムクリーンアップまで |
| ネットワークからの画像 | はい | システムクリーンアップまで |
| デバッグログ | 条件付き | tmpの方が良い |
| ゲームセーブ | いいえ | Documentsのみ |
| アプリ設定 | いいえ | Application Support |
データを復元できない場合、それはCachesに属しません。これが最もシンプルな基準です:明日システムがCachesからすべてのファイルを削除したと想像してください。アプリケーションが引き続き正しく動作するなら、データは適切に保存されています。
iOSは自動的にCaches Directoryのクリーンアップを管理しますが、正確なトリガーやアルゴリズムはAppleによって文書化されていません。ディスク容量が不足している場合や、Offload Unused Apps機能がアクティブな場合に、システムがCachesからファイルを削除できることが知られています。
クリーンアッププロセスはアプリケーションにとって透過的であり、システムは通知なしにファイルを削除します。アプリケーションは読み取り前にファイルの存在を確認し、存在しない場合は再作成する必要があります。Cachesを扱う際、長期的な保存に依存しないことが重要な要件です。
Appleの記事「File System Basics」(2024)によると、アプリケーションはCaches Directoryのファイルがセッション間で利用可能であると期待すべきではありません。開発者はフォールバックメカニズムを実装することを推奨します:キャッシュファイルがない場合はネットワークからデータをダウンロードし、再度Cachesに保存します。
>別のシナリオとしてアプリのオフロードがあります。この機能が有効になると、iOSはアプリケーションを削除しますが、Documents Directoryは保持します。Caches Directoryはこのプロセスで削除されます。アプリケーションを復元したユーザーはキャッシュデータを取得できません。アプリケーションは再度ダウンロードする必要があります。
CachesとTemporary(tmp)ディレクトリの違いは、開発者の間でしばしば混乱を引き起こします。両方のディレクトリは一時データを保存しますが、ライフタイムの保証と目的が異なります。
| 特性 | Caches Directory | Temporary Directory |
|---|---|---|
| ライフタイム | セッション間(保証なし) | セッション内のみ |
| システムクリーンアップ | 容量不足時 | セッション終了時または再起動時 |
| 目的 | パフォーマンス向上のためのキャッシュ | 非常に一時的なデータ |
| 例 | キャッシュされた画像 | エクスポート前の一時ファイル |
| バックアップ | なし | なし |
アプリケーションの起動間でデータを保持することが有益だが復元可能な場合はCachesを選択します。データが現在のセッションでのみ必要で、アプリケーション終了後に価値がない場合はtmpを使用します。
Caches Directoryを扱うには、データ損失、予期しないアプリケーション動作、パフォーマンス問題を防ぐためのいくつかのルールに従う必要があります。
FileManager.fileExists(atPath:)はCachesからの読み取りのたびに呼び出す必要があります。ファイルがない場合は、元のソースからデータをロードしてキャッシュに保存します。Cachesにファイルが存在することを決して前提にしないでください。
アプリケーションでCaches Directoryの最大サイズを設定します。例えば、画像は50 MB、JSON応答は10 MBの制限を設けます。制限を超えた場合は、変更日時に基づいて最も古いファイルを削除します。
import Foundation
func trimCache(to maxSizeBytes: Int) {
let cachesURL = FileManager.default
.urls(for: .cachesDirectory, in: .userDomainMask)
.first!
guard let enumerator = FileManager.default
.enumerator(
at: cachesURL,
includingPropertiesForKeys: [.fileSizeKey, .contentModificationDateKey]
)
else { return }
// Enumerate and remove old files
// when exceeding size limit
}
これらのプラクティスに従うことで、システムのキャッシュクリーンアップアクションに関係なくアプリケーションが正しく動作し、ユーザーが予期しないデータ損失に直面することがなくなります。
よくある質問
いいえ、iOSはCachesからファイルを削除する前に通知を送信しません。クリーンアッププロセスはアプリケーションにとって完全に透過的です。削除を知る唯一の方法は、ファイルの読み取りを試みたときです。FileManagerがnilを返すかエラーをスローし、アプリケーションはこの状況を処理する必要があります。
ユーザーはFilesやiTunesを通じてCaches Directoryに直接アクセスできません。ただし、設定 > 一般 > ストレージからすべてのアプリのキャッシュをクリアし、特定のアプリケーションを選択して「Appをオフロード」をタップすることができます。また、iOSはストレージが不足している場合に自動的にキャッシュをクリアすることがあります。
URLCacheは、FoundationによるHTTPリクエストキャッシュの組み込みメカニズムです。内部的にCaches Directoryを使用して、キャッシュされた応答を自動的に保存およびロードします。手動保存の方がより制御が可能で、形式の選択、データの暗号化、各ファイルのライフタイムの個別管理ができます。
App Storeを介してアプリケーションを更新する場合、Caches Directoryは保持されます。ただし、新しいアップデートのインストールにより多くの容量が必要な場合、システムによって内容が削除されることがあります。開発者はアップデート後もCachesが保持されることに依存すべきではありません。これはフォールバックメカニズムを実装する追加の理由です。
特定のNSURLSessionセッションに対してURLCacheをnilに設定するか、.reloadIgnoringLocalCacheDataキャッシュポリシーを使用します。空のキャッシュでURLSessionConfigurationを作成することもできます:sessionConfiguration.urlCache = nil。これは常に最新である必要があるデータに便利です。
まとめ
ターンキー方式のモバイルアプリケーションを開発します
IT Sectrは2017年からスタートアップや企業向けにiOS・Androidアプリケーションを開発しています。私たちがご相談に乗り、最適なソリューションをご提案します。