Learn how to build and launch an iOS app on the Simulator directly from VS Code using SweetPad — selecting a scheme and destination, running the build, and debugging with LLDB.
Before running anything, it helps to understand what SweetPad does when you press build, because that mental model makes troubleshooting far easier. SweetPad does not compile Swift itself. When you trigger a build, it constructs and runs an xcodebuild command using the scheme and destination you selected, then streams the output into VS Code's integrated terminal or output panel. For running on the Simulator, it uses Xcode's Simulator tooling to boot the chosen device, install the freshly built app bundle, and launch it. Debugging is layered on through the CodeLLDB extension, which attaches LLDB to the running process. Because every step maps to a real command that Xcode also runs, anything that builds and runs in Xcode should build and run in SweetPad, and anything that fails will fail with the same underlying xcodebuild error. Keeping this pipeline in mind — scheme and destination in, xcodebuild and Simulator out — is the key to a smooth workflow and quick diagnosis when something goes wrong.
A successful build-and-run assumes a healthy setup, so confirm the basics first. You should have the full Xcode application installed and selected as the active developer directory, verifiable with xcode-select -p. The SweetPad extension should be installed in VS Code, and you should have opened the folder containing your .xcodeproj or .xcworkspace. At least one iOS Simulator runtime must be installed through Xcode so there is a destination to run on. If you plan to debug, install the CodeLLDB extension. It is also wise to confirm the project builds in Xcode at least once, which validates your signing settings, dependencies, and scheme. If a build fails in Xcode, it will fail identically in SweetPad because the same xcodebuild runs underneath. Taking a minute to confirm these prerequisites prevents you from chasing a SweetPad problem that is actually a project or Simulator problem, and it gives you a known-good baseline to compare against if something behaves unexpectedly.
The scheme tells xcodebuild which app and configuration to build, so selecting the correct one is the first concrete step. Open the Command Palette and run the SweetPad command to select a scheme, or use the SweetPad sidebar where the current scheme is displayed. The list you see mirrors the schemes available in Xcode's scheme selector, including any shared schemes committed to the repository and, potentially, personal schemes. Choose the scheme that corresponds to the app target you want to run rather than a test-only or framework scheme. SweetPad remembers your selection for the workspace, so you usually set this once per project and only change it when switching between apps in a multi-scheme repository. If your expected scheme does not appear, it may not be marked as shared in Xcode; open the scheme management dialog in Xcode, enable sharing, and it will show up. A correct scheme selection is a precondition for both building and for generating an accurate buildServer.json for code completion.
The destination is where your app will run. Using the Command Palette or the SweetPad sidebar, select a destination and pick an iOS Simulator from the list — for example a recent iPhone model on an installed runtime. This corresponds to the -destination argument that xcodebuild receives, and it is the step new users most often forget, which leads to a build that succeeds but nothing appearing on screen. The available Simulators come directly from the runtimes installed with Xcode, so if the list is empty or missing the device you want, open Xcode and install the appropriate Simulator runtime, then reselect. If you intend to run on a physical device instead, connect it, trust the computer, ensure the device is provisioned for development, and choose it from the destination list. Physical devices add signing requirements that the Simulator does not, so for a first run the Simulator is the simpler path. With a scheme and destination both chosen, SweetPad has everything it needs to build and launch.
With a scheme and destination selected, trigger a build from the Command Palette using SweetPad's build command, or use build-and-run to compile and launch in one step. SweetPad assembles the xcodebuild invocation and streams its output into VS Code so you can watch compilation progress and read any errors inline. A first build of a large project can take a while as it compiles dependencies, and subsequent incremental builds are faster. If the build fails, read the xcodebuild output carefully — the errors are the same ones Xcode would report, whether they are Swift compile errors, missing dependencies, or signing issues. If you only ran build rather than build-and-run, you will need to run the run step afterward. Keeping the output panel visible during your first few builds is a good habit, because it teaches you what a healthy build looks like and makes it obvious when a failure is a code problem versus a configuration or environment problem in the SweetPad-to-xcodebuild handoff.
When you run build-and-run against a Simulator destination, SweetPad boots the chosen Simulator if it is not already running, opens the Simulator app, installs your compiled app bundle, and launches it. The first boot of a Simulator can be slow because the runtime has to start up, so give it time before assuming something failed. If the Simulator boots but your app does not appear, confirm you selected the app scheme rather than a framework or test scheme, and check the output panel for an install or launch error. You can interact with the running app in the Simulator exactly as you would when launching from Xcode, including using the Simulator's menus for rotating, simulating location, and adjusting hardware settings. Because SweetPad is only orchestrating the Simulator tooling that ships with Xcode, any Simulator behavior you rely on in Xcode continues to work; SweetPad simply triggered the same launch from your editor instead of from Xcode's run button.
To debug, make sure the CodeLLDB extension is installed, then start a debug run through SweetPad. It launches the app and attaches LLDB so you can set breakpoints in your Swift files, inspect variables, view the call stack, and step through execution using VS Code's debug controls. This gives you the core of a debugging workflow without leaving the editor. Be realistic about the limits: this is standard LLDB debugging, not Xcode's full suite, so you will not get the visual view-hierarchy debugger, the memory graph, or Instruments-level profiling here. For those, open Xcode. For everyday breakpoint-and-inspect debugging of logic, the SweetPad and CodeLLDB combination is perfectly capable. If breakpoints are not hit, confirm you built a debug configuration rather than a release build, that CodeLLDB is installed and enabled, and that the process actually launched under the debugger rather than being started separately. As always, the underlying tools are standard, so problems tend to have standard, well-documented solutions.
Once your first build-and-run works, the day-to-day loop becomes fast. Edit your Swift code with SourceKit-LSP completion, save, and run build-and-run again; incremental builds only recompile what changed, so the loop is quick on modest projects. Bind SweetPad's build and run commands to keyboard shortcuts in VS Code to make the cycle even tighter, mirroring the muscle memory of Xcode's run shortcut. Keep the Simulator open between runs so you avoid repeated cold boots. When you change project structure — adding targets, switching schemes, or regenerating a Tuist or XcodeGen project — remember to regenerate buildServer.json so code completion stays accurate, and reselect your scheme if it changed. For anything SweetPad does not cover, such as editing asset catalogs, configuring signing, or profiling, switch to Xcode for that task and return to VS Code for editing and running. This companion workflow — VS Code for the write-build-run loop, Xcode for the specialized tools — is how most SweetPad users work in practice.
Almost always because no destination was selected, or you ran build instead of build-and-run. Select an iOS Simulator as the destination and use the build-and-run command so SweetPad boots the Simulator, installs the app, and launches it.
Use SweetPad's select-destination command in the Command Palette and pick a Simulator from the list. That list comes from the runtimes installed with Xcode, so install additional runtimes in Xcode if the device you want is missing.
Yes, connect the device, trust the computer, ensure it is provisioned for development, and select it as the destination. Physical devices require valid code signing, which you configure in Xcode; the Simulator avoids those signing requirements for a first run.
It covers standard LLDB debugging — breakpoints, variable inspection, stepping — through the CodeLLDB extension. It does not include Xcode's visual view-hierarchy debugger, memory graph, or Instruments profiling, so keep Xcode for those specialized tasks.
The first build compiles the whole project and its dependencies, and the first Simulator boot starts a fresh runtime, so both take time. Subsequent incremental builds and warm Simulators are much faster.
Not for building and running, but you keep Xcode installed and open it for tasks SweetPad does not cover, such as asset catalogs, storyboards, signing configuration, and profiling. SweetPad is a companion to Xcode, not a replacement.