iOS Simulator Recognition Failure in Flutter Environment

You have initialized a Flutter project, verified the environment variables, and successfully launched the application on an Android Emulator. However, the development workflow halts when attempting to target iOS. Despite having Xcode installed and functional, the Visual Studio Code device selector displays "No Devices" or restricts options solely to macOS Desktop and Chrome. Executing flutter devices in the terminal confirms the isolation:

$ flutter devices
2 connected devices:
macOS (desktop) • macos  • darwin-arm64   • macOS 14.0
Chrome (web)    • chrome • web-javascript • Google Chrome

# Expected:
# iPhone 15 Pro (mobile) • [UUID] • ios • com.apple.CoreSimulator.SimRuntime.iOS-17-0

This discrepancy is rarely a bug within the Flutter SDK or the VSCode Dart extension. It is almost exclusively a system-level configuration issue regarding how the macOS command-line tools interface with the Xcode application bundle. Specifically, the active developer directory is likely pointing to a standalone command-line tools package rather than the full Xcode installation required for simulation.

The Mechanics of Toolchain Resolution

Flutter does not communicate directly with the iOS Simulator binary. Instead, it relies on Apple's xcrun utility to locate and execute developer tools like simctl (Simulator Control). The xcrun tool resolves paths based on the value set by xcode-select.

When you install the "Command Line Tools for Xcode" separately (often triggered by Homebrew or Git installations), the system path defaults to /Library/Developer/CommandLineTools. This directory contains compilers (clang, swift) and basic make tools, but it does not contain the CoreSimulator framework or the iOS SDKs required to spawn a simulator instance.

Key Architecture Concept: The iOS Simulator requires the full Xcode bundle context because it depends on the runtime libraries located inside Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform. The standalone CommandLineTools lack these platform definitions.

To verify your current configuration, execute the print-path command:

# Check the current active developer directory
xcode-select -p

# INCORRECT OUTPUT:
# /Library/Developer/CommandLineTools

# CORRECT OUTPUT:
# /Applications/Xcode.app/Contents/Developer

Realigning the Developer Directory

To resolve the visibility issue, you must force the system to point to the full Xcode application bundle. This requires root privileges.

# 1. Switch the xcode-select path
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer

# 2. Verify the path change
xcode-select -p
# Output should be: /Applications/Xcode.app/Contents/Developer

# 3. Accept the Xcode license agreement (mandatory for CLI usage)
sudo xcodebuild -license accept

Once the path is corrected, restart VSCode completely (Cmd+Q). The Flutter daemon will re-poll the available devices upon initialization. You can verify the availability of runtimes via the simctl interface directly:

# List available devices and runtimes
xcrun simctl list devices available

Comparison: Standalone Tools vs. Xcode Bundle

Understanding the difference between the two environments is critical for troubleshooting future build errors, especially when dealing with native iOS dependencies or CocoaPods.

Feature	CommandLineTools (Lightweight)	Xcode.app (Full Suite)
Path	`/Library/Developer/CommandLineTools`	`/Applications/Xcode.app/...`
Git/Make/Clang	Included	Included
iOS SDKs	Missing	Included
CoreSimulator	Missing	Included
Flutter Support	Partial (Analysis only)	Full (Build & Run)

Advanced Troubleshooting: CocoaPods and Ruby

Even after fixing the simulator path, you may encounter build failures related to CocoaPods on Apple Silicon (M1/M2/M3). The system Ruby installation often clashes with architecture requirements (ARM64 vs. x86_64) when invoking FFI (Foreign Function Interface).

Avoid using the system Ruby. macOS ships with a dated version of Ruby that requires sudo for gem installation, which breaks permission boundaries. Use a version manager like rbenv or rvm.

If you see errors related to `ffi` during `pod install`, ensure your terminal and the CocoaPods process are running in the correct architecture mode. A robust fix involves reinstalling the FFI gem with explicit architecture flags:

# Uninstall the existing ffi gem
sudo gem uninstall ffi

# Reinstall specifically for arm64
sudo arch -x86_64 gem install ffi

# Update pods inside the ios directory
cd ios
arch -x86_64 pod install

Automating Simulator Launch

Waiting for the simulator to cold boot via VSCode can be slow. A more efficient workflow involves pre-warming the simulator via the CLI. You can create a shell alias to launch the Simulator application directly, which VSCode will then immediately detect as an active device.

# Open the Simulator app directly
open -a Simulator

By ensuring xcode-select points to the comprehensive Xcode bundle, you bridge the gap between the Flutter tools and the underlying Apple SDKs. This configuration is a one-time setup that persists across reboots, ensuring a stable environment for iOS development on macOS.