Introduction

Sometimes an iOS app needs to know whether it is running in the Simulator or on a physical device. That usually comes up when you work with hardware-dependent features such as the camera, motion sensors, push setup, or device-specific debugging behavior.

Apple provides a built-in way to check this at compile time, and that should be your default solution. Runtime checks can still help for diagnostics, but they are usually secondary.

Use targetEnvironment(simulator) In Swift

In Swift, the standard check is #if targetEnvironment(simulator). Because this is a compile-time condition, it is stable and explicit. You are not guessing from device names or environment quirks.

1import UIKit
2
3func runtimeDescription() -> String {
4    #if targetEnvironment(simulator)
5    return "Running in the iOS Simulator"
6    #else
7    return "Running on a physical device"
8    #endif
9}
10
11print(runtimeDescription())

This pattern is ideal when a code path should compile differently based on the runtime target. For example, you may want to disable camera capture inside the Simulator:

1func canUseRealCamera() -> Bool {
2    #if targetEnvironment(simulator)
3    return false
4    #else
5    return true
6    #endif
7}

That is more robust than checking model identifiers or architecture values manually.

Wrap The Check In A Helper

If many parts of the app need the same information, centralize it. That keeps the rest of the code clean and avoids scattering compiler directives everywhere.

1enum AppEnvironment {
2    static var isSimulator: Bool {
3        #if targetEnvironment(simulator)
4        return true
5        #else
6        return false
7        #endif
8    }
9}
10
11if AppEnvironment.isSimulator {
12    print("Using mock services")
13}

Now feature code can ask AppEnvironment.isSimulator instead of repeating the directive. This also makes testing and refactoring easier because environment-specific behavior lives in one place.

Runtime Checks For Diagnostics

If you need additional simulator details for logging or debugging, ProcessInfo can read environment variables injected by the Simulator.

1import Foundation
2
3let env = ProcessInfo.processInfo.environment
4let deviceName = env["SIMULATOR_DEVICE_NAME"] ?? "unknown"
5let model = env["SIMULATOR_MODEL_IDENTIFIER"] ?? "unknown"
6
7print("Simulator device: \\(deviceName)")
8print("Simulator model: \\(model)")

This is useful for debug logs, test harnesses, or telemetry during development. It should not usually be the main control path for app behavior because environment variable details are less central than Apple's official compiler check.

Prefer Capability Checks When Possible

Many apps reach for simulator detection when they actually need feature detection. If the real question is whether the device has a camera, biometric authentication, or location services, test that capability directly.

For example, camera availability is often a better condition than environment detection:

1import AVFoundation
2
3let hasCamera = AVCaptureDevice.default(for: .video) != nil
4print("Camera available: \\(hasCamera)")

This is more future-proof because it asks the exact business question. A simulator branch is still useful when platform behavior itself changes, but capability checks reduce assumptions.

Objective-C Equivalent

Older Objective-C projects use the platform macro form. The idea is exactly the same as the Swift version.

1#if TARGET_OS_SIMULATOR
2NSLog(@"Running in the iOS Simulator");
3#else
4NSLog(@"Running on a device");
5#endif

That makes it straightforward to keep simulator behavior consistent in mixed Swift and Objective-C codebases.

Common Pitfalls

One common mistake is checking the device model string and assuming that values such as x86_64 or arm64 are enough to detect the Simulator. That is brittle and tied to implementation details. targetEnvironment(simulator) is the supported approach.

Another mistake is using simulator detection in place of hardware or API checks. If your real need is feature availability, permissions, or sensor support, detect those directly instead of inferring them from the environment.

Finally, do not rely on simulator-only testing for release-critical features. Camera, notifications, performance, storage behavior, and background execution often differ on real devices. Simulator branches can help development, but physical device testing remains necessary.

Summary

• In Swift, use #if targetEnvironment(simulator) to detect the iOS Simulator.
• Wrap that logic in a helper if many parts of the app need it.
• Use runtime environment inspection mainly for diagnostics and logging.
• Prefer capability checks when your real concern is hardware or API support.
• Test on physical devices before shipping because Simulator behavior is not identical.