The iOS Simulator does not have a built-in airplane mode toggle or network disable switch. It shares the host Mac's network stack directly. To simulate offline conditions, you either disable networking on the Mac itself, use Network Link Conditioner to throttle bandwidth to zero, or architect your app with a network abstraction layer that can be toggled in test builds.

Why the Simulator Has No Airplane Mode

Physical iOS devices manage their own cellular radio, Wi-Fi chip, and Bluetooth hardware. Airplane mode is a hardware-level toggle. The Simulator is a user-space process running on macOS. It does not emulate network hardware. Instead, it uses the host Mac's TCP/IP stack directly. Any network request from a simulated app goes through the Mac's network interfaces. This means there is no way to disable networking for the Simulator alone without affecting the entire Mac.

Method 1: Disable the Mac's Network Interface

The most direct approach is to turn off networking on the Mac. This affects everything on the machine, not just the Simulator.

Using the Menu Bar

Click the Wi-Fi icon in the menu bar and select "Turn Wi-Fi Off." If you are connected via Ethernet, unplug the cable.

Using the Command Line

1# Turn off Wi-Fi (en0 is the default Wi-Fi interface)
2networksetup -setairportpower en0 off
3
4# Turn it back on
5networksetup -setairportpower en0 on
6
7# List all network interfaces to find the right one
8networksetup -listallhardwareports

Using a Script with Automatic Restore

For testing sessions, wrap the disable/enable cycle in a script:

1#!/bin/bash
2# offline-test.sh - Run a test session with networking disabled
3
4INTERFACE="en0"
5
6echo "Disabling Wi-Fi..."
7networksetup -setairportpower "$INTERFACE" off
8
9echo "Network is off. Run your Simulator tests now."
10echo "Press Enter to restore networking."
11read -r
12
13networksetup -setairportpower "$INTERFACE" on
14echo "Wi-Fi restored."

The downside is obvious: you lose internet access on the Mac for the duration of the test. IDE features, package managers, documentation lookup, and any other network-dependent tools will stop working.

Method 2: Network Link Conditioner

Network Link Conditioner (NLC) is an Apple developer tool that intercepts network traffic and applies configurable constraints like latency, bandwidth limits, and packet loss. While it cannot completely disable the network in a binary sense, it can simulate conditions so degraded that they are functionally equivalent to offline.

Installing Network Link Conditioner

NLC is distributed as part of the "Additional Tools for Xcode" package:

1. Open Xcode > Settings > Components.
2. Or download from developer.apple.com/download/more and search "Additional Tools."
3. Install the Network Link Conditioner preference pane from the downloaded DMG.

Once installed, it appears in System Settings > Network Link Conditioner.

Creating a Custom "Offline" Profile

1. Open Network Link Conditioner in System Settings.
2. Click "Manage Profiles" then click the "+" button.
3. Configure the profile:

1. Name it "100% Packet Loss" and save.
2. Select the profile and toggle NLC on.

With this profile active, all network requests from the Simulator (and the Mac) will time out. The TCP connections will technically be attempted but every packet is dropped, so your app sees connection timeouts and network errors identical to a real offline scenario.

Using NLC from the Command Line

1# Enable NLC with a specific profile (macOS 13+)
2# Note: NLC GUI must be installed first
3sudo dnctl pipe 1 config bw 0
4sudo pfctl -E

Method 3: Application-Level Network Mocking

The most precise approach does not touch the system network at all. Instead, you inject a mock network layer into your app during testing.

URLProtocol Stubbing

Register a custom URLProtocol subclass that intercepts all requests and returns errors:

1class OfflineURLProtocol: URLProtocol {
2    override class func canInit(with request: URLRequest) -> Bool {
3        return true  // Intercept all requests
4    }
5
6    override class func canonicalRequest(for request: URLRequest) -> URLRequest {
7        return request
8    }
9
10    override func startLoading() {
11        let error = NSError(
12            domain: NSURLErrorDomain,
13            code: NSURLErrorNotConnectedToInternet,
14            userInfo: [NSLocalizedDescriptionKey: "Simulated offline"]
15        )
16        client?.urlProtocol(self, didFailWithError: error)
17    }
18
19    override func stopLoading() {}
20}
21
22// Register in your test setup
23URLProtocol.registerClass(OfflineURLProtocol.self)

Using a Launch Argument Toggle

Configure your app to check a launch argument that enables offline mode:

1// In AppDelegate or your networking layer
2if ProcessInfo.processInfo.arguments.contains("--offline") {
3    URLProtocol.registerClass(OfflineURLProtocol.self)
4}

Then pass the argument in your Xcode scheme under "Arguments Passed On Launch" or in UI tests:

let app = XCUIApplication()
app.launchArguments.append("--offline")
app.launch()

This approach is the only one that affects the Simulator exclusively without disrupting the Mac's connectivity.

Method 4: Proxy-Based Network Control

Tools like Charles Proxy or mitmproxy can intercept Simulator traffic and selectively block requests.

1# Using mitmproxy to block all traffic
2mitmproxy --mode regular --set block_global=true
3
4# Or use Charles Proxy's Throttle Settings
5# Enable Throttling > select "No network" preset

Configure the Simulator to use the proxy by setting the HTTP proxy in System Settings > Wi-Fi > Advanced > Proxies on the Mac (since the Simulator inherits the Mac's proxy settings).

Comparison of Approaches

Testing Network Transitions

Beyond testing pure offline behavior, you should also test transitions between online and offline states. Real users move in and out of connectivity.

1import Network
2
3class NetworkMonitorWrapper: ObservableObject {
4    private let monitor = NWPathMonitor()
5    @Published var isConnected = true
6
7    init() {
8        monitor.pathUpdateHandler = { [weak self] path in
9            DispatchQueue.main.async {
10                self?.isConnected = (path.status == .satisfied)
11            }
12        }
13        monitor.start(queue: DispatchQueue.global())
14    }
15}

To test this in the Simulator, use Network Link Conditioner and toggle it on/off during a running session. Your NWPathMonitor callbacks will fire just as they would on a real device.

Common Pitfalls

Assuming NWPathMonitor reflects Simulator-specific state. Since the Simulator uses the Mac's network, NWPathMonitor reports the Mac's connectivity status. If you disable Wi-Fi on the Mac, the monitor correctly reports .unsatisfied. But there is no way to make the monitor report offline while the Mac is online, short of using the URLProtocol approach.

Testing only the offline state, not the recovery. Users do not stay offline permanently. Test that your app recovers gracefully when connectivity returns: pending requests retry, cached data refreshes, and UI updates from an error state back to normal.

Using Reachability libraries that only check interface availability. Many legacy Reachability wrappers check whether a network interface is available, not whether a specific host is reachable. In the Simulator, the interface is always "available" even if Network Link Conditioner is dropping all packets. Test with actual HTTP requests, not just reachability checks.

Forgetting to re-enable Network Link Conditioner. NLC persists across reboots. Leaving a "100% Packet Loss" profile active will break all networking on your Mac until you disable it. Consider adding a reminder or using the command-line approach that resets on reboot.

Summary

The iOS Simulator cannot disable networking independently because it shares the Mac's network stack. For quick manual testing, disable Mac Wi-Fi or use Network Link Conditioner with a 100% packet loss profile. For precise, repeatable, Simulator-only offline testing, implement a URLProtocol subclass that intercepts requests and returns offline errors, toggled via a launch argument. This application-level approach is the only method that does not disrupt the Mac's own connectivity and can be integrated into automated UI test suites.