Skip to main content

How Linux builds work

SweetPad turns an Xcode project into input for Swift Build, Apple's open-source build system. Swift Build schedules Linux compilers and portable resource tools against SDK data from your own Xcode.

The build pipeline​

Read the project​

SweetPad reads the workspace, projects, scheme, configurations, and target dependencies. It describes them in the Project Interchange Format that Swift Build consumes. Swift Package Manager supplies the package graph, including resolved remote packages and binary XCFrameworks.

Schemes from remote packages become available after dependency resolution. Listing schemes reads existing checkouts; it does not fetch packages.

Compile for iOS​

The compiler runs on Linux and emits code for the selected Apple destination. For an iPhone, that destination uses the iOS device SDK and ARM64 code. LLD links the objects into Mach-O executables and libraries.

The compiler toolchain and Apple SDK have different jobs. The toolchain supplies executable Linux programs. The SDK supplies headers, modules, frameworks, runtime libraries, and platform metadata.

Compile resources​

SweetPad implements the resource tools that Swift Build expects. These tools compile supported asset catalogs, storyboards, XIBs, String Catalogs, Core Data models, and App Intents data.

Many tool names resolve to the same SweetPad executable. The executable selects the requested operation from its invocation name.

Supported Apple macros use a Linux plugin. SweetPad also builds reachable package macros for the host when their source supports Linux.

Build products and incremental work​

Products use the DerivedData layout that the other CLI commands expect. An explicit build directory keeps CI outputs and local experiments easy to find:

sweetpad build --project MyApp.xcodeproj --scheme MyApp \
  --destination 'generic/platform=iOS' --json --non-interactive \
  -- -derivedDataPath "$HOME/builds/MyApp"

Swift Build tracks inputs and reuses unchanged work. Generated project inputs keep their timestamps when their contents do not change. A fresh DerivedData directory provides a control when you compare a changed resource processor or toolchain.

Run-script phases execute on Linux. The build supplies compatible tools for common Xcode script operations, but a script that depends on macOS still needs adaptation.

Signing and the phone​

Linux signing uses an Apple Development identity from a P12 file and your provisioning profiles. The signer seals the app and its embedded bundles before installation.

The device adapter uses pymobiledevice3==11.50.0 for USB and Wi-Fi. It authenticates the selected device before installation or launch. The modern adapter establishes its developer-service tunnel in userspace.

These are separate operations: a successful build creates products, and a successful installation transfers a signed product to the phone. The Ubuntu guide walks through both.

Tests and other Apple platforms​

Linux can compile iOS test products and generate an XCTest run manifest. Xcode on a Mac supplies the test runtime, including the iPhone test runner. Prebuilt test execution keeps the Linux compilation result intact.

The same engine also builds macOS apps and supported tvOS, watchOS, and visionOS simulator targets. Their runtime coverage differs from iPhone coverage. See support and configuration and the separate macOS CI guide.