When SweetPad builds but the iOS Simulator or your app never launches, the cause is usually a missing destination, an uninstalled runtime, or a misconfigured xcodebuild path. Here is how to fix it.
The classic symptom is that a SweetPad build finishes successfully, yet nothing happens: the Simulator never opens, or it opens but your app does not install or launch, and no obvious error is shown. Sometimes SweetPad reports that no destination is available, or the destination list is empty. Other times the Simulator boots but the app fails to install with a launch or installation error in the output. The key realization is to separate the two phases: building and running are different steps. A green build only means xcodebuild compiled the app; it does not mean the app was installed and launched on a device. The launch phase depends on a valid destination, an installed and bootable Simulator runtime, and a correctly configured xcodebuild path so SweetPad can drive the Simulator tooling. The following checks walk through the causes in order of likelihood, starting with the one that trips up the most people — forgetting to select a destination or running build instead of build-and-run.
The single most common cause is that no destination was selected, or you triggered a plain build rather than build-and-run. A build with no run step compiles the app and stops, which looks like a silent failure if you were expecting the Simulator to appear. Open the Command Palette or the SweetPad sidebar, run the select-destination command, and choose a specific iOS Simulator. Then run the build-and-run command rather than build alone, so SweetPad proceeds to boot the Simulator, install the app, and launch it. SweetPad passes your chosen destination to xcodebuild as the -destination argument, so without a selection there is nowhere to run. If you previously selected a destination that no longer exists — for example after deleting a Simulator or updating Xcode — reselect a current one. This check resolves the majority of not-launching reports, so confirm it before digging into runtimes or toolchain paths, which are less frequent culprits.
If the destination list is empty or missing the device you want, the underlying cause is usually that no iOS Simulator runtime is installed. SweetPad's destination list is populated directly from the runtimes that come with, or are added through, Xcode. Open Xcode and check its settings for installed platforms and Simulator runtimes; download the iOS runtime you need if it is absent. After installing a runtime, return to SweetPad and reselect the destination — the new Simulators should now appear. You can also verify available Simulators from the command line with xcrun simctl list devices, which shows every device and its availability; if a device shows as unavailable, it usually points at a missing or mismatched runtime. This situation is common right after a fresh Xcode install or a major Xcode update, where the runtimes are not downloaded automatically. Once at least one bootable Simulator exists and appears in the destination list, SweetPad has a valid target to launch your app on.
SweetPad drives xcodebuild and the Simulator tooling from the active developer directory, so a wrong or missing path breaks launching even when everything else looks fine. Run xcode-select -p and confirm it returns a path inside your Xcode application, such as one ending in Xcode.app/Contents/Developer. If it instead points at the standalone Command Line Tools, the full Simulator machinery is not available; fix it with sudo xcode-select -s and the path to your Xcode app. Make sure you have launched Xcode at least once so it finished installing components, and accept the license if prompted, which you can also do with sudo xcodebuild -license. A mismatched path is especially likely after installing multiple Xcode versions or after an update that reset the selection. Because SweetPad ultimately shells out to these tools, pointing the developer directory at a complete, licensed Xcode install is essential for the Simulator to boot and for your app to install and launch through the extension.
To isolate whether the problem is SweetPad or the Simulator itself, boot a Simulator outside of VS Code. Open the Simulator app from Xcode, or use xcrun simctl to boot a device by its identifier, and see whether it starts normally. If the Simulator will not boot even manually, the issue is in your Xcode or Simulator installation, not in SweetPad, and you should focus there — reinstalling the runtime, freeing disk space, or restarting the Mac to clear a stuck simulator service. A Simulator that is in a bad state can be reset; erasing its content and settings or shutting down all simulators with xcrun simctl shutdown all often clears a hung device. Once you confirm a Simulator boots and runs a simple app manually, you know the platform is healthy, and any remaining failure is in the SweetPad configuration layer — the destination selection or the build-and-run step — which narrows your troubleshooting considerably and prevents you from blaming the wrong component.
Sometimes the Simulator boots but your app specifically fails to install or launch. Read the SweetPad output panel carefully, because the install and launch phase reports its own errors distinct from compilation. A frequent cause is selecting a non-app scheme — a framework or test scheme produces no launchable app bundle, so nothing installs. Reselect the scheme that builds your actual app target. Another cause is a bundle identifier or minimum-deployment mismatch: if your app's minimum iOS version is higher than the Simulator runtime you chose, installation fails, so pick a Simulator on a compatible runtime. Corrupted state from a previous install can also block launching; erasing the Simulator's content and settings or uninstalling the app from the Simulator and rebuilding usually clears it. For Simulator runs, signing is generally not the blocker, but for physical devices it very much is, so if you switched to a device destination, verify provisioning and signing in Xcode. Matching scheme, deployment target, and runtime resolves most install-phase failures.
When the Simulator subsystem gets into a bad state, no amount of reconfiguration helps until you clear it, so this is the reset-oriented last resort. Shut down all simulators with xcrun simctl shutdown all, then try again. If a device is corrupted, erase it with xcrun simctl erase or from the Simulator app's menu. Restarting VS Code ensures it picks up a corrected PATH or developer directory, and restarting the Mac clears a wedged CoreSimulator service that can silently prevent booting. If you recently updated macOS or Xcode, confirm the update fully completed, because a half-finished update commonly leaves the Simulator unable to boot until components finish installing. Freeing disk space matters too, since Simulators need room to boot and install apps. After clearing state, walk back through the earlier checks — destination selected, runtime installed, correct xcodebuild path — to confirm the healthy baseline. These resets are rarely needed, but when the Simulator refuses to cooperate despite correct configuration, clearing stuck state is what finally gets it launching again.
If the Simulator works but a physical device does not, the cause is almost always signing and trust rather than anything SweetPad controls, so treat device runs as a separate category with their own checklist. Confirm the device is connected, unlocked, and that you tapped Trust This Computer when prompted; an untrusted device will not appear as a usable destination. The target needs a valid signing configuration — a development team selected and a provisioning profile that includes the device's UDID — which you set up in Xcode's Signing and Capabilities tab, since SweetPad does not provide a signing UI. On modern iOS you may also need to enable Developer Mode on the device itself and approve the developer certificate under the device's VPN and Device Management settings the first time you run. If the device shows as unavailable or the install fails with a code-signing error, open the project in Xcode and run once to that device to let Xcode provision it, then return to SweetPad, which reuses the same signing setup. Because these are Apple signing requirements, they apply identically whether you launch from Xcode or from VS Code.
Because building and running are separate steps. A plain build only compiles the app; it does not install or launch it. Select an iOS Simulator destination and use the build-and-run command so SweetPad boots the Simulator, installs the app, and launches it.
That means no Simulator runtime is installed. Open Xcode, download an iOS Simulator runtime from its platform settings, then reselect the destination in SweetPad. You can verify available devices with xcrun simctl list devices.
Run xcode-select -p and confirm it returns a path inside Xcode.app. If it points at the Command Line Tools instead, fix it with sudo xcode-select -s and the path to your Xcode app, then relaunch and try again.
Common causes are selecting a framework or test scheme instead of the app scheme, or a minimum-deployment version higher than the chosen runtime. Reselect the app scheme, pick a compatible Simulator, and erase the Simulator if a previous install left it in a bad state.
Run xcrun simctl shutdown all to stop all simulators, and xcrun simctl erase to reset a corrupted device, or use the Simulator app's erase menu. Restarting VS Code or the Mac clears a wedged CoreSimulator service when the Simulator refuses to boot.
Test by booting a Simulator manually from Xcode or with xcrun simctl. If it fails to boot outside VS Code, the problem is in your Xcode or Simulator installation, not SweetPad. If it boots fine manually, focus on SweetPad's destination and build-and-run configuration.