Sandbox — what it is, the isolation principle, and the file system

What is Sandbox

Sandbox is a Mandatory Access Control system implemented at the iOS kernel level (XNU — Sandbox.kext kernel extension). Each app receives a unique UUID Sandbox profile at launch, which determines which resources the app is allowed to access.

The Sandbox architecture includes three key components: File System Isolation (each app sees only its own container), Network Access Control (requests to the local network can be restricted), and Inter-Process Communication (a ban on direct IPC with other apps). Apple introduced Sandbox in iOS 2.0 and has since significantly strengthened the restrictions in every major version.

Sandbox is not optional — all apps from the App Store run in the sandbox. A developer cannot disable Sandbox or bypass its restrictions. An attempt to access a prohibited resource fails with error code EPERM (Operation not permitted) and an entry in the system log.

import Foundation

// Attempt access to another app file — returns nil
let otherAppPath = "/var/mobile/Containers/Data/Application/OTHER-UUID/Documents/file.txt"
let data = try? Data(contentsOf: URL(fileURLWithPath: otherAppPath))
// data == nil — Sandbox blocks access

// Correct access — within own Sandbox
let fileManager = FileManager.default
guard let documentsURL = fileManager.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first else { return }

let myFileURL = documentsURL.appendingPathComponent("notes.txt")
try "Hello, Sandbox!".write(to: myFileURL, atomically: true, encoding: .utf8)

App sandbox structure

The Sandbox of each app on iOS contains several predefined directories accessible through the Foundation API. The location on the physical medium is /var/mobile/Containers/Data/Application/{UUID}/, but developers should not use this path directly: it changes on every device restart in different iOS versions.

The main Sandbox directories: Bundle (.app — read-only, contains the executable code and resources), Documents (user data, backed up to iCloud), Library (Caches, Preferences, Application Support — with different backup rules), tmp (temporary files, deleted by the system when space is low). Each directory has its own lifecycle and storage policy.

The physical Sandbox path can be obtained via NSHomeDirectory() or FileManager.url(for: .documentDirectory). Apple recommends using the URL-based API because it abstracts the internal structure of the file system and remains stable when the macOS Sandbox changes on the desktop.

Access to files outside the sandbox

Direct access to the file system of other apps in iOS is completely blocked. Even if a developer knows the container UUID of another app, Sandbox at the kernel level returns an error when attempting to read or write. This is a fundamental difference between iOS and macOS, where Sandbox is more flexible.

Apple provides three legitimate mechanisms for inter-app data exchange: UIDocumentPickerViewController (the user selects a file through the system interface, and the app receives a Security-Scoped URL), Share Extension (an extension for passing data to another app), and App Groups (a shared directory for apps of the same developer).

UIDocumentPicker is the only way to access files from other apps without prior setup. The user explicitly selects a file through the standard system picker, and iOS provides the app with a temporary Security-Scoped URL. Access lasts until the picker is closed or until stopAccessingSecurityScopedResource is called.

Security-Scoped Bookmarks

A Security-Scoped Bookmark is an iOS mechanism that allows preserving access to a file outside the Sandbox between app launches. When the user selects a file through UIDocumentPicker, the app can create a bookmark from the Security-Scoped URL and save it in UserDefaults or another store.

On the next launch, the app restores access via URLByResolvingBookmarkData, which returns a Security-Scoped URL. Then you need to call startAccessingSecurityScopedResource before reading the file and stopAccessingSecurityScopedResource after finishing. Balanced calls are mandatory — each start must have a corresponding stop, otherwise the system will exhaust the Security-Scoped resource limit.

// Create Security-Scoped Bookmark
func createBookmark(for url: URL) -> Data? {
    return try? url.bookmarkData(
        options: .minimalBookmark,
        includingResourceValuesForKeys: nil,
        relativeTo: nil
    )
}

// Resolve bookmark data to URL
func resolveBookmark(data: Data) -> URL? {
    var isStale = false
    let url = try? URL.byResolvingBookmarkData(
        data,
        options: .withoutUI,
        relativeTo: nil,
        bookmarkDataIsStale: &isStale
    )
    
    if isStale {
        // Bookmark is stale, need to create new
    }
    
    return url
}

Important limitation: Security-Scoped Bookmarks do not work for files inside your own Sandbox — only for files obtained through UIDocumentPicker or iCloud Drive. A bookmark contains Security-Scoped data that allows the system to identify which app is requesting access to which file. If the app's certificate expires or changes, the bookmark becomes invalid.

Sandbox and App Groups

App Groups is an iOS mechanism that allows several apps (and their extensions) from one developer to share a common Sandbox directory. To enable it, you need to add the App Groups Capability in Xcode and specify the same group identifier for all target apps.

The shared App Groups directory is outside the Sandbox of each individual app, but all apps in the group have full read and write access to it. This allows exchanging files, databases (Core Data with the Store URL in the App Group), and UserDefaults (via initWithSuiteName) between the main app, Today Widget, Watch Extension, and Share Extension.

Apple recommends using App Groups for state synchronization between an app and its extensions. For example, the Today Widget can read data from the shared App Group directory where the main app writes up-to-date data. At the same time, each app is still isolated from other App Groups — only apps with the same group identifier have access.

Sandbox limitations in iOS

Sandbox in iOS imposes a number of strict restrictions that must be taken into account during development. The main ones: a ban on dynamic code (loading and executing code outside the Sandbox), a ban on direct access to the address book, calendar, and photos without user permission (Privacy framework), and restrictions on creating child processes (fork and exec are prohibited).

Network: apps can connect to any remote servers via TCP/UDP, but access to localhost is restricted — other apps cannot connect to a server inside your app (except for debug builds). Multicast and broadcast UDP are also blocked for App Store apps.

Hardware resources: access to the camera, microphone, geolocation, Bluetooth, and HealthKit requires explicit user permission through the system dialog. For each type of resource, iOS uses a separate entitlement and an Info.plist key with a usage description (NSPhotoLibraryUsageDescription, NSCameraUsageDescription). Requesting permission without a usage description in Info.plist causes the app to terminate.

• Dynamic code — prohibited: JavaScriptCore for JS in WebView, but not arbitrary machine code
• Child processes — fork, exec, and system are unavailable from the Sandbox
• Device access — camera, microphone, and GPS require a system dialog
• Local network — multicast and broadcast UDP are blocked for the App Store
• Encryption keys — Keychain is available, but only for your own app (kSecAttrAccessGroup for App Group)