A native macOS app for managing and slimming iOS simulators.
Build & run · Download source · Documentation · Releases · Issues
SwiftSimSlim calls Apple’s simctl directly, with an in-process Swift backend, per-device progress, and command logs. Select the services your workflow needs, review a profile, and verify its state after applying it.
| Capability | What you can do |
|---|---|
| Service profiles | Slim or re-enable allowlisted services while keeping required compatibility services enabled. |
| Preview and recovery | Review planned changes, save the original service state, export it as JSON, and restore a saved profile. |
| Full Slim & Clean | Choose the service profile and individual cleanup categories with compact checkboxes in a resizable confirmation. All start selected; apps and durable data are preserved. |
| Disk analysis and cleanup | See where the full data-directory size goes; select caches, logs, temporary files, and optional downloaded assets or indexes. |
| Wallpaper controls | Clean generated wallpaper textures, or explicitly disable wallpapers for a black background without deleting apps and their data. |
| Apps & Data | List installed apps by size, uninstall an app, or selectively clear its Documents or other private data. |
| Live service profiles | Apply a profile to an already booted simulator without an automatic restart, with readback verification and restart-needed reporting. |
| Simulator management | Boot, shut down, rename, clone, erase, or delete individual simulators. |
| Independent operations | Follow separate progress and logs for each device, with at most two heavy operations at once. |
| Boot-state preservation | Return a simulator to its original Booted or Shutdown state after a successful profile operation. |
- Clean Wallpaper Cache… now includes accumulated Home Screen runtime textures, with confirmation and preservation of wallpaper originals and settings.
- Disable Wallpapers… explicitly removes wallpaper originals, configuration, and snapshots and disables PosterBoard for a black background. Apps and their data are kept. This experimental mode was checked on iOS 27.2; it is separate from routine cleanup.
- Full Slim & Clean has compact checkboxes, all selected initially. Uncheck the service profile or any cleanup category to skip it. Resize the confirmation by dragging its edges or corners; the list scrolls in a smaller window.
See the 26.1.2 release notes for behavior, verification, and limits.
Five additional services join Full Slim: a new Device Management category, plus App Clips and accessibility asset downloads under Other Background Services. Individual services and categories can be kept enabled. See the 26.1.1 release notes.
Full Slim & Clean, per-app storage management, a complete disk breakdown, optional wallpaper/Siri/model cleanup, restart-free service changes, and a new simulator-and-RAM icon. Disk selection and analysis keep row heights, category order, and the toolbar layout stable. See the release notes.
These are captures of the running app with seven synthetic simulator entries and temporary sample files. Sizes and service states are demonstration data, not performance measurements. Main-window captures include the test banner; the app inventory capture shows only its sheet.
Disk Cleanup: selected size, cleanup controls, stable categories, and per-device progress.
Apps & Data: measured app bundles, Documents, other private data, and selective deletion actions.
Full Slim & Clean: resizable confirmation with compact, individually selectable steps. All are selected initially.
Wallpaper controls: clean generated caches or explicitly disable wallpapers.
Disable Wallpapers: separate confirmation explains the black background and which data is kept.
You need a Mac with Xcode and its simulator tools, plus an installed iOS Simulator runtime. Persistent slimming requires iOS 18.5 or later. The project uses Swift 6 and an Icon Composer app icon; use Xcode capable of opening those project resources. See the verification matrix for the recorded environment and its limits.
The published 26.1.2 release provides source archives, with no prebuilt app attached. You can download the release source or clone the current development version:
git clone https://github.com/Anywhere-Music-Player/SwiftSimSlim.git
cd SwiftSimSlim
open SwiftSimSlim.xcodeprojIn Xcode, select SwiftSimSlim → My Mac, then press Cmd-R to build and launch. The 26.1.2 source release includes the features described below.
- Select a simulator in the app. Use a disposable device or clone it first if you want to keep a separate copy.
- Choose the service categories to keep enabled for your app’s workflow.
- Choose Service State → Preview Service Changes, inspect the planned labels, then apply the profile. Slim also presents this preview before applying.
- Follow progress and command details in Activity. Use Restore Saved State to return to the saved managed-service profile, or Unslim to enable all managed services.
Disabling services can affect features that depend on them. A saved service state is not an app-data backup and cannot undo Erase or disk cleanup. Read the recovery behavior and limits before changing a device you rely on.
- Architecture and comparison with simslim
- How slimming works
- Preview, save, export, and restore
- Apply a profile without restarting
- Disk analysis and cleanup
- Full Slim & Clean
- Apps & Data
- Safety evidence and reproducible checks
- Measured service-update time
- Boot-state behavior
- Development and contributions
The interface and simulator logic live in one Xcode project. SwiftUI and Observation drive the interface; Swift concurrency handles command execution, cancellation, and progress. This keeps the app’s interface, simulator operations, and tests together in a single development workflow.
Operations on different simulators can run independently, with separate progress and logs. The app prevents overlapping changes to the same device and limits heavy operations to two devices at a time to avoid overloading CoreSimulator.
Swift does not make Apple’s simulator commands intrinsically faster. The speed improvement comes from changing how those commands are used.
| Area | Original simslim | SwiftSimSlim |
|---|---|---|
| Implementation | SwiftUI interface calling a Go CLI | SwiftUI interface and Swift backend in one Xcode project |
| Slim a booted simulator | Apply service commands, then restart | Stop first, merge overrides, boot and verify |
| Slim a stopped simulator | Offline override merge, boot and verify | Capture and save live original state, then stop, merge, boot and verify |
| Fallback service updates | Shell batches; unconfirmed changes retried serially | Up to eight concurrent direct launchctl commands |
| Apply an unchanged profile | Boot/readiness handling before checking the profile | Check a booted device first; skip boot and restart |
| Other devices during an operation | Mutation controls share a global busy state | Separate device reservations and progress; two heavy operations at a time |
The comparison refers to simslim at 4ae1659. Upstream subsequently merged the booted-device offline optimization and parallel service transitions in PR #51. The table and timings below describe the historical snapshot, not current upstream performance.
- Capture and check before changing anything. The app captures the original live state and saves a recovery point before a changed profile. If a booted simulator already has the requested profile, finish without another boot or restart. A stopped simulator is booted first for a trustworthy original-state capture.
- Apply the profile while shut down. If changes are needed, stop the simulator, merge the managed service overrides in one write, then boot and verify the actual service state. This also works when Slim was started on a running simulator, replacing hundreds of individual service commands with one restart.
- Use bounded parallel commands when needed. The offline override store is an undocumented CoreSimulator detail, so its results are always checked. If the store cannot be written or the runtime does not honor all changes, apply the remaining changes through up to eight concurrent
simctl spawn … launchctlcommands. Retry only failed transitions, then restart and verify persistence.
The fallback does not require a shell inside the simulator. The tested iOS 27 runtime contains launchctl but no /bin/sh, so shell-based batching cannot be relied on there.
Only allowlisted services are changed. Unmanaged overrides are preserved, and required compatibility services may only be re-enabled.
Choose Service State → Preview Service Changes (also in each simulator’s row menu). Slim and Unslim also show this preview before applying. It lists the exact labels to disable and enable for each selected UUID, including required-service repairs. Closing or refreshing the preview never boots a simulator or changes its services.
A booted device supplies live launchd state. A stopped device supplies an offline estimate, clearly labeled as provisional: the private override plist is not proof of runtime behavior. Applying freezes the reviewed profile settings. If a live preview has become stale, the operation stops and asks for a new preview. For an offline preview, actual changes are calculated from live state at apply time.
Before a profile change, the app captures launchd state and atomically saves a JSON recovery point under ~/Library/Application Support/SwiftSimSlim/ServiceBackups/<UUID>.json. A stopped device is temporarily booted for this capture. If saving fails, service changes do not start. A no-op preserves the existing recovery point. Each subsequent profile change replaces that device’s recovery point, so export it first if you need to keep an older one.
Select one simulator and use Service State, or its row menu:
- Restore Saved State restores the saved managed-service profile and saved Booted/Shutdown state, with live verification. The snapshot remains available after restoration and app relaunch.
- Export Saved State… writes the snapshot as JSON: capture date, exact UUID, device set, runtime, original boot state, and disabled labels. Export is for inspection/archiving; arbitrary JSON import is not supported.
- Unslim enables all managed services. It is different from restoring a saved partial profile.
Restoration only touches the current allowlist, always enables required compatibility services, and preserves current unmanaged overrides. Unmanaged labels in the export are informational. The snapshot is not an app-data backup and cannot undo Erase or disk cleanup. Successful Erase/Delete removes that device’s recovery point. Restoration rejects a mismatched UUID, device set, or runtime.
On failure, the original boot state is recovered when possible and the saved service state remains available for explicit restoration. Partially applied service changes are not automatically rolled back. Activity reports recovery failures too; inspect the log before retrying.
Version 26.1.1 adds Device Management (three declarative management and managed-asset services), plus App Clips and accessibility asset downloads in Other Background Services, following upstream #66. Full Slim includes all five; retain the category or individual services when your app needs these features. Disabling them prevents the corresponding management workflows, App Clips, or accessibility asset downloads from working. Core profiled and mdmd services remain outside the allowlist.
Category memory estimates come from upstream and are approximate; savings and compatibility of these additions have not yet been measured on a real simulator in this app. This changes the service profile, not disk cleanup rules.
In Preview Service Changes or Preview Unslim, enable Apply without restarting the simulator. It is available only when every selected simulator is booted. The existing restart mode remains the default.
The app saves the current service state before changing anything, then loads or unloads matching runtime jobs in batches and uses individual commands for unfinished transitions. It verifies both disabled overrides and loaded jobs afterward. Required compatibility services stay enabled and unmanaged overrides are preserved. A loaded job may be idle; this check does not claim that every related process is running or that every feature works.
If an enabled job cannot load in the current boot session, its label appears in an expandable warning beside the simulator. Restart Simulator is a separate, explicit action; the live operation never restarts automatically. A failed or cancelled operation can leave partial service changes; Restore Saved State uses the existing restart-based recovery path.
This applies the complete profile shown in the preview, including shared-service dependencies implied by the retained categories. It does not save an upstream CLI profile or install a background watcher. Restart-free application still takes time for service commands; no speedup is claimed until measured on a real runtime. Build and synthetic tests are separate from live and visual acceptance.
Switch to Disk Size and select one or more simulators. The Disk Cleanup bar above the list shows the selected cleanup estimate, Re-analyze Selected, and Clean Disk…. After a successful cleanup it shows the removed size for the selected devices during the current app session.
The total covers the entire simulator data directory. Cleanup categories and Retained Storage account for that total without counting the same path in multiple buckets. Retained storage includes installed apps and support data, Documents, user media, wallpaper originals/settings, other system assets, and remaining durable system data. Shared iOS runtimes are separate. Sizes use allocated blocks; APFS sharing and files changing during analysis mean this is not a guarantee of reclaimed space.
Routine cleanup selects caches, logs, and temporary files. Additional categories are opt-in:
| Category | Effect |
|---|---|
| Downloaded Language Data | Removes supported language downloads, which iOS can download again. |
| Wallpaper & Poster Cache | Clears generated snapshots in recognized Apple poster layouts, including accumulated RuntimeSnapshot-…-home.atx textures. Keeps source content and wallpaper configuration. It does not set a black wallpaper. |
| Downloaded Siri & Speech Assets | Removes allowlisted per-device catalogs. Speech features may stop working until iOS restores them; custom voices and unknown catalogs stay protected. |
| Other Downloaded System Models | Removes known model catalogs; dependent features may need to download them again. |
| System Intelligence History & Indexes | Clears IntelligencePlatform, Biome, and DuetExpertCenter data and resets learned personalization. |
The current development build also offers Clean Wallpaper Cache… directly in the wallpaper category. Its confirmation applies only to that category, regardless of other cleanup toggles. Files outside the recognized snapshot layouts stay under Wallpaper Originals & Other Data.
Disable Wallpapers… is a separate, confirmed reset. It disables only PosterBoard, shuts down the simulator, removes the wallpaper store (including originals and Home/Lock Screen configuration), then boots to verify that PosterBoard remains disabled. Apps, app documents, preferences, app groups, photos, and shared runtimes are outside this reset. Previously stopped simulators are stopped again; reopening previously booted simulators is optional. This experimental mode was checked on iOS 27.2: disabling PosterBoard alone still allowed MercuryPoster snapshots to accumulate, while removing the wallpaper store as well kept the background black across restarts. Restoring services may recreate default wallpapers; deleted custom wallpapers are not restored. It is never included automatically in Full Slim & Clean or routine cache cleanup.
Deleting assets does not disable services. iOS can regenerate caches, indexes, and downloads after boot even with optional services disabled. Remaining system data is not offered for blanket deletion; Erase Simulator… is a separate full reset that also deletes apps and user data.
Cleanup always shows a confirmation with a red, bold action button; no typed confirmation word is required. File deletion waits for shutdown, stays within validated simulator data, and protects app bundles, Documents, user media, unknown layouts, and shared runtimes. The reopen option controls whether previously booted devices are started again. Deletion is permanent; a saved service profile cannot restore files.
Analysis runs off the main actor and reports progress in the disk-size column. Categories keep their order and rows keep their height as selection and measurements change. Toolbar actions remain grouped left, center, and right in both modes.
Click Full Slim & Clean in the toolbar to open its confirmation directly, or use the same action in the Simulator menu. The resizable confirmation starts with Full Slim and every supported cleanup category checked, including optional speech/model downloads and learned system history. Uncheck any step to skip it. If Full Slim is selected, the app saves the original service state and applies and verifies the profile before cleaning the selected categories. A backup or profile failure stops before cleanup. Previously booted devices can be reopened afterward.
Apps, Documents, photos, and app settings are preserved. This is not an Erase, does not promise zero RAM use, and cannot prevent all future downloads. The required compatibility services remain enabled. If you need selective cleanup, use Clean Disk… instead.
Select one simulator and open Apps & Data from the Disk toolbar, Manage Apps & Data… inside the Apps & Data card under Retained Storage, or the row menu. The searchable list shows developer-installed apps, largest first, with allocated bundle, Documents, other private data, and known total sizes. Inspection works while the simulator is shutdown and does not boot it. System runtime apps are excluded. Shared App Groups and User Media are reported separately; extension data containers are not attributed to their parent app. Unknown sizes remain marked unknown. APFS sharing and changing app files mean these totals are not guaranteed reclaimed space.
Select one app, choose an action, and confirm with the red deletion button:
- Uninstall App uses CoreSimulator to remove that app and its private data. Shared group data may remain.
- Delete Documents clears only that app's Documents contents.
- Clear App Data clears its other private files, including preferences, databases, caches, and temporary files. Documents and shared containers remain.
These operations permanently delete the selected data and have no automatic backup. A simulator clone is the recovery option before deletion; saved service-state snapshots cannot restore files. The backend resolves the exact UUID and device set, revalidates the app's container registration through CoreSimulator, and shuts down before direct file deletion. It restores the original boot state even after an operation fails or is cancelled; a partial deletion is not rolled back. Previously shutdown simulators can briefly boot for validation or uninstall.
Open Photos in Simulator starts the selected simulator and opens Photos for selecting and deleting media there. The app does not directly remove Photos database files or shared App Group contents. The existing routine disk cleanup still excludes app bundles, Documents, and user media.
Validation covers temporary-fixture size accounting, selective deletion, container identity/path rejection, shutdown-before-clear, uninstall routing, and boot-state recovery. The UI test opens the inventory and deletion confirmation using temporary sample apps, then cancels; it does not delete real simulator apps.
Evidence types are separate. Passing synthetic tests does not establish runtime or UI compatibility, and a verified disabled override does not prove every related process has exited.
| Evidence | Environment | Services / checks | Result |
|---|---|---|---|
| Build and synthetic tests, 2026-09-22 | Apple M1 Pro, 16 GiB; macOS 27.0 (26A428); Xcode 27.0 (27A266a); My Mac | Read-only preview; snapshot persistence/export; stale preview; failed save; cancellation; partial-profile restore; compatibility/unmanaged boundaries; concurrent failure and selective retry | 53 tests passed, 0 failed; live/visual tests are opt-in |
| UI interaction, 2026-10-30 | My Mac; seven synthetic devices and temporary app files | Disk selection and analysis at three window sizes; toolbar distribution in both modes; app inventory and confirmation; combined cleanup confirmation | Captured in the screenshots above; no real simulator mutation |
| Service-command benchmark, 2026-09-21 | M1 Pro; Xcode 27.0; isolated iPhone 18 Pro, iOS 27.0 | Same 170 labels; restored state verified after reboot | Historical single-run result below; excludes lifecycle time |
| Visual snapshots, 2026-09-22 | macOS 27.0; synthetic models | Main view at 1500×900 / 1080×700; service preview at 690×640 | Rendered and inspected; does not establish interactive or runtime behavior |
| Live safety attempt, 2026-09-22 | M1 Pro, 16 GiB; macOS 27.0; Xcode 27.0; fresh isolated iPhone 18 Pro / iOS 27.0 | Boot/readiness completed in 101.44 s; fixture installation timed out at 120 s, before profile application | Failed during setup; no before/after memory or apply/restore timing obtained; test device deleted and set verified empty |
| Live follow-up, 2026-09-22 | Same M1 Pro / Xcode 27.0 / iOS 27.0 | Profile and reboot persistence passed, but the fixture crashed before and after Slim because it lacked scene lifecycle support | Failed; memory samples are invalid for performance claims. Fixture now uses scenes and the harness requires app readiness before Slim |
| Live follow-up after fixture changes, 2026-09-22 | Same host/runtime; heavy concurrent host activity | Installation completed; app launch timed out at 120 s before profile changes | Failed during setup; device deleted and set verified empty; full live acceptance remains pending |
| Other Apple Silicon variants; other Xcode/runtime combinations | Not measured for this change | Repeat the same procedure on each combination | No compatibility or speed claim |
To reproduce the optional snapshots, set SWIFTSIMSLIM_SNAPSHOT_DIR to an output directory in the Test scheme and run renderInterfaceSnapshot / renderServiceSafetySnapshot separately from live tests.
The recorded live attempt preserves the failure and host details. Its disabledLabels field is the requested catalog, not a claim that those services changed: this attempt stopped before Slim. Current RAM before/after, total apply/restore time, post-profile app launch, and real-runtime saved-state restoration remain unverified. The earlier combined live/visual attempt ended when its test runner exited before completion; its isolated device was also removed.
Follow-up evidence: fixture-crash run and launch-timeout run. The fixture crash also occurred before Slim (UIApplicationEvaluateRuntimeIssueForNoSceneLifecycleAdoption), so that run does not establish a service regression or valid memory savings. The fixture now adopts scene lifecycle, and the test waits for a new per-launch readiness marker and checks a unique pre-Slim document. The changed fixture builds, but its live acceptance is still pending after the later setup timeout. Further live runs were stopped; ordinary synthetic verification is separate.
The full profile means the full catalog in ServiceCatalog.swift, not every removable iOS service. The live report records the exact sorted labels rather than relying on a service count that may change between releases. Category memory estimates in the sidebar are not measurements of your current device.
Open SwiftSimSlim.xcodeproj, select SwiftSimSlim → My Mac, and run Cmd-B / Cmd-U. The ordinary scheme does not enable live acceptance or screenshots and does not mutate real simulators. Its unit-test host has no main simulator window. Explicit UI test modes display a banner identifying synthetic devices, an intentionally empty list, or an isolated device set. Formatting:
swift format lint --strict --recursive SwiftSimSlim SwiftSimSlimTests SwiftSimSlimUITests AcceptanceFixtureconcurrentProfilesIsolateMidBatchFailureRetryAndSavedRestore forces the command fallback on two synthetic simulators at once. One label on the first device fails on all three attempts while the second device completes. It checks separate reservations, original snapshots, retry counts (successful transitions run once), UUID-tagged logs, and restoration of only the failed device. This is deterministic fault injection, not a claim of real CoreSimulator failure recovery on every runtime.
Use disposable test simulators only. The opt-in test creates its own new device set and never accepts an existing simulator UUID.
- Build AcceptanceFixture → Any iOS Simulator Device in Xcode. Locate
Debug-iphonesimulator/AcceptanceFixture.appin the project’s default DerivedData products. - Switch back to SwiftSimSlim → My Mac. In Edit Scheme → Test → Arguments, temporarily add:
SWIFTSIMSLIM_SAFETY_ROOT=/private/tmp/SwiftSimSlim-safety-<new-unique-name>— the directory must not exist.SWIFTSIMSLIM_FIXTURE_APP=<absolute path to AcceptanceFixture.app>.- Optionally
SWIFTSIMSLIM_LIVE_RUNTIMEandSWIFTSIMSLIM_LIVE_DEVICE_TYPEusing exact installed identifiers. Defaults arecom.apple.CoreSimulator.SimRuntime.iOS-27-0andcom.apple.CoreSimulator.SimDeviceType.iPhone-18-Pro.
- Run only
isolatedServiceSafetyMatrixfrom the Test navigator, separately from builds and visual tests. Fixture installation has a 300-second deadline to allow first-boot installation work to finish. It installs the scene-based fixture, waits for a fresh readiness marker from each app launch, writes a unique durable document before Slim, waits 10 seconds before each memory sample, applies the full catalog through the same backup path used by the app, verifies after another reboot, launches the app again, checks its document, restores saved state, and repeats capture/apply/restore from Shutdown. - Read
safety-matrix.json,original-state.json, andoperations.login the supplied root. The operation log is written while the test runs, so it also survives an interrupted runner. Keep the.xcresultalongside the reports; test assertions determine pass/fail. The report includes Xcode/macOS/chip/RAM, labels, process counts, memory before/after, complete apply/restore times, and cleanup results. - Remove the temporary scheme environment variables afterward. Each rerun needs a new root. The test deletes its own device even after a thrown error. If the runner is interrupted,
created-uuid.txtidentifies the only cleanup target; use that exact UUID withsimctl --set <root>/Devices, neverallor the default device set.
Memory is the app’s sum of top MEM values for the simulator launchd process tree, not host-wide RAM saved. Both samples use the same fixture app and settling interval. Repeat runs and report sample spread before making performance claims. App launch and retained documents do not cover share-sheet interaction, location, StoreKit, notifications, or every application workflow; validate the functions your chosen profile needs separately.
Command Details / Copy Log includes device name, UUID, and operation ID. PLANNED, SAVED, APPLIED, FAILED, retry stages, VERIFIED, and RESTORED distinguish requested transitions, command outcomes, final state, and recovery. Boot-state recovery is explicitly separate from service restoration. The interface retains the latest 10,000 log entries; the live test writes its full trace.
TIMING operation-total measures from reservation through queue wait, execution, and its status refresh request (including refresh work when performed by that operation). TIMING profile-total includes original-state capture, backup, profile changes, shutdown, boot/readiness, verification, and recovery when attempted. It excludes queue wait, preview, and the later UI refresh. Separate records show shutdown, boot-and-readiness, offline-override-write, and service-state-read. service-commands-only includes retries but excludes the restart and final verification. Phase timings are nested observations; do not add them to the total. A timing emitted on failure measures the attempted operation, not successful completion.
Measured on September 21, 2026: Apple M1 Pro, 16 GB RAM, macOS 27.0, Xcode 27.0, and two newly created, isolated iPhone 18 Pro simulators with iOS 27.0. Both implementations used the same 170 service labels.
Simulator startup, shutdown, restart, preparation, and final verification are excluded. This compares the service-command phase, not total time after clicking Restore.
| Operation on an already booted, slim simulator | Original simslim | SwiftSimSlim |
|---|---|---|
| Re-enable the same 170 services | approximately 144 s | 24.3 s |
The original measurement runs from its “Re-enabling 170 background services” message to “Rebooting the simulator”, using log timestamps with one-second resolution. Its shell batches confirmed no changes, so all 170 services went through the sequential retry pass. The Swift measurement times applyServiceChanges directly, using eight concurrent commands. Both completed, and the restored service state was verified after reboot outside the timer.
This deliberately exercises SwiftSimSlim’s command fallback. Normal profile changes first try the offline merge described above and can avoid those 170 commands entirely. The difference comes from command scheduling and avoiding failed shell batches, not from Swift executing faster than Go.
These are individual local observations, not averages or guaranteed speedups. Mac workload and CoreSimulator response times still affect the commands themselves. Only newly created test simulators were used, and they were deleted afterward.
Preserve current boot state is enabled by default. Slim temporarily boots a stopped simulator to verify the profile, then returns it to its original state:
| State when the operation starts | Preserve current boot state | State after successful Slim or restore |
|---|---|---|
| Booted | On or off | Booted |
| Shutdown | On | Shutdown |
| Shutdown | Off | Booted |
Turn this option off before applying a profile if you want a stopped simulator to remain booted afterward. Returning to Shutdown does not undo slimming: the verified service overrides persist for the next boot. A simulator that started booted should remain booted after a successful operation; a failure or cancellation can interrupt that sequence and is reported in Activity.
Open SwiftSimSlim.xcodeproj and select SwiftSimSlim → My Mac. Use Cmd-B to build, Cmd-R to run, and Cmd-U for ordinary unit tests. Keep generated products in Xcode’s default DerivedData. The app and backend live in one Swift 6 / SwiftUI project; there is no bundled CLI, daemon, or helper service.
Read AGENTS.md for project conventions and safety boundaries. The ordinary checks include the formatting command; live acceptance is a separate, opt-in procedure using disposable simulators.
Bug reports and pull requests are welcome. Open an issue with the macOS, Xcode, and simulator runtime versions, reproduction steps, and relevant command logs. Remove personal paths or other sensitive details before sharing logs.
For a pull request, explain the behavior change and validation performed. Keep changes focused, preserve upstream attribution and simulator safety boundaries, and report unit tests, live-runtime checks, and visual verification separately. See UpstreamFollowUp.md for the recorded upstream comparison and follow-up.
Based on simslim by Interlap / MobAI, source snapshot 4ae1659a0c0265787c2a7047fab466b326ba6d7e. The initial interface, service catalog, and simulator-management behavior were adapted into this independent Swift app.
Distributed under the MIT license. The original Copyright (c) 2026 Interlap notice is retained; LICENSE is also included in the app bundle.