iOS overview

Peach runs Swift apps in the browser. Point peach swift at a SwiftPM package, an .xcodeproj or an .xcworkspace, and Peach compiles your app target from source, opens it on a simulated iPhone, and keeps it live while you edit. Your project stays as it is: Peach adds no JavaScript entry, Vite setup or node_modules, and it never runs Xcode or your build phases.

Swift support is in beta. Many real apps compile and run today, and the gaps are reported by name instead of hidden. Expect some apps to stop at an API Peach does not have yet.

#What compiles

Peach compiles your Swift to WebAssembly with the pinned swift.org toolchain (Swift 6.4) and links it against Peach’s own SwiftUI, UIKit and system framework modules. That covers:

• +
  SwiftUI apps: an App with a WindowGroup, views, modifiers, @State, @Binding, @Observable models, @AppStorage, navigation stacks, tabs, sheets, alerts, lists and forms.
• +
  UIKit apps: an app delegate with @main or @UIApplicationMain, or a main.swift that calls UIApplicationMain. Scene delegates and the legacy lifecycle both run their callbacks in the order iOS runs them, and the key window’s root view controller mounts, including a UIHostingController.
• +
  Xcode project structure: the app target’s sources and resources, its in-project framework targets, local Swift packages, and remote packages at the revisions Package.resolved pins. Build settings, .xcconfig files, schemes and #if DEBUG follow Xcode’s rules.
• +
  System frameworks: Foundation (including URLSession over the browser’s network), Combine, Dispatch, UserDefaults, SQLite, Core Location and Core Motion driven by the simulated device, among others. Coverage varies by framework.

When your app imports a module Peach does not provide, peach swift lists every such module and the files that import it. When compilation fails, it ends with the APIs Peach lacks, each with its error count and files. That list is the honest picture of how far your app is from running.

#How it renders

Your Swift code runs in a WebAssembly instance inside Peach’s app worker, the same place a React Native app’s JavaScript runs. Your SwiftUI and UIKit views render through Peach’s iOS components, the same ones that render React Native apps on iOS. Layout, scrolling, gestures, text input, the keyboard, accessibility, the status bar and home indicator all come from that one iOS surface, so a Swift app behaves like every other app in Peach. Peach never paints Swift views with a separate renderer.

See How Peach works for the worker model that keeps scrolling and animations moving while app code is busy.

#iOS behavior Peach follows

Peach portrays iOS 27 on iPhone and iPad device profiles. Behavior is matched against Apple’s own simulator. Peach does not invent behavior:

• +
  App and scene lifecycle callbacks fire in iOS order with the same application and scene states.
• +
  UIDevice.current reports the model, system name and version of the device you select, and follows device changes.
• +
  Core Location reads the simulated device’s location and permission state, which you drive with the commands in Device state. It never reads your browser’s real location.
• +
  @AppStorage and UserDefaults values persist for the installed app, across code changes and relaunches.

#Edit while it runs

Save a Swift file and Peach recompiles only what changed, then swaps the new code in while keeping your view state. A counter keeps its count, a pushed screen stays pushed, and a selected tab stays selected, as long as the view’s position in the tree did not change. A save that only changes a literal in a view body (a string, number or bool) applies without compiling at all. See Running Swift apps.

#Not supported yet

• +
  Multiple windows and Settings scenes. App and WindowGroup map to one app surface.
• +
  Storyboard roots, multiple connected scenes, and launch URLs or shortcuts.
• +
  Objective-C and assembly targets. Peach names them as unsupported and still compiles the targets beside them.
• +
  Xcode build phases and run scripts. Peach reads the project as data and never runs them, so generated sources must already exist on disk.
• +
  Closed-source binary frameworks. Peach builds a stand-in from the framework’s interface so your app compiles, and every call into it fails with an error that names the framework. A C framework that ships a WebAssembly build, or whose Rust crate is in your project, links and runs for real.
• +
  Files written to Documents, Caches or tmp live in memory. They last while the app runs and start empty after a relaunch or a recompiled edit.

#Next steps

• +
  Running Swift apps: SwiftPM, Xcode projects, targets, schemes and every peach swift flag.
• +
  Run a SwiftUI app: a complete walk from project to live edits and sharing.
• +
  peach swift reference and peach ios.
• +
  Swift modules inside an Expo or One app live in the React Native section.