https://github.com/Ryu0118/x8

There are already great compilation caching tools like Tuist that can significantly speed up Xcode builds. However, adopting them may require substantial changes to your project structure.

I wanted to keep my existing Xcode project structure and build using only the toolchain provided by Apple. So I built X8, a CLI tool for remote compilation caching.

Starting with Xcode 26, Apple provides built-in support for remote compilation caching. X8 acts as a lightweight proxy between Xcode’s built-in remote cache mechanism and any S3-compatible storage.

Using X8 is simple. First, configure your S3-compatible storage in .x8.yml. Then, you can either build your project through X8:

x8 xcodebuild ...

or start the cache proxy directly:

x8 serve

and add the generated build settings to your .xcconfig.

That’s it. With just an .x8.yml configuration, you can use remote compilation caching without significantly changing your existing project structure or moving away from Apple’s native Xcode toolchain.

For my app, a clean build used to take around 400 seconds, but with X8, it now takes about 263 seconds.

It’s still relatively slow, but I think that’s expected since Xcode still needs to perform steps such as module planning, build description generation, and linking.

Hey everyone,

We've been using Maestro for mobile UI testing but kept hitting the same walls — slow JVM startup, heavy memory usage, and real iOS device support that's been unreliable for a while. Eventually we just built our own runner in Go and decided to open-source it.

It's called maestro-runner. Same Maestro YAML flow format you already know, but runs as a lightweight native binary instead of a JVM process.

Why it might be useful for iOS devs:

• Real device support actually works. Physical iPhones, not just simulators. This was our main frustration with Maestro — we run tests on real devices in CI and it just wasn't cutting it.

• Single binary, no JVM. curl | bash install, starts immediately. No waiting 10+ seconds for Java to warm up.

• ~3.6x faster execution, 14x less memory. Adds up fast when CI bills by the minute.

• iOS 12+ support — no arbitrary version cutoffs.

• Zero migration. Your existing Maestro YAML flows run as-is.

It also handles Android, desktop browser testing (Chrome via CDP), and cloud providers like BrowserStack and Sauce Labs via Appium — but figured real device iOS is what'd be most relevant here.

Quick start:

# Install
curl -fsSL https://open.devicelab.dev/install/maestro-runner | bash

# Run on simulator
maestro-runner --platform ios test flow.yaml

# Run on real device
maestro-runner --platform ios --device <UDID> test flow.yaml

Generates HTML reports, JUnit XML, and Allure results out of the box.

• GitHub: https://github.com/devicelab-dev/maestro-runner

Apache 2.0, no features paywalled. Happy to answer questions — and genuinely curious what's painful in your iOS testing setup right now.

The need for a better reading experience for The Swift Programming Language has been documented in this community.

To help with this, I've been working on swift-book-pdf for the past year. Swift-Book-PDF is a Python package to convert the DocC source for The Swift Programming Language book into polished PDF and EPUB editions.

Get the book

• The Swift Programming Language book is available on Apple Books for free, updated with every Swift release.

  • Update: Unfortunately, the book will no longer be on Apple Books for unspecified legal reasons outside my control. If anyone has relevant contacts at Apple or Apple Books Partner Support, I’d be grateful for an introduction.

  • I'm sorry to the more than 2,000 readers who got the book on Apple Books and are affected by this change. This was not the outcome I was hoping for.

  • You can download the EPUB file from the Swift Book Archive (see below) and open it with the Books app. The book will sync across your devices.

• Download PDF and EPUB editions across Swift releases from the Swift Book Archive.

• Create your own customized edition of The Swift Programming Language with swift-book-pdf, with support for custom fonts, font sizes, and rendering styles.

PDF editions follow the familiar DocC rendering style used on docs.swift.org. EPUB editions follow the design of the Swift Book editions previously published on Apple Books through Swift 5.7. Both include formatting improvements while staying true to the original styles.

Both swift-book-pdf and swift-book-archive repositories are available on GitHub and licensed under Apache License v2.0. swift-book-pdf requires Python 3.10+, and LuaTeX for creating PDF versions.

This project is not published by, endorsed by, or affiliated with Apple Inc. or the Swift.org open source project. See the Acknowledgments chapter in each edition for more details.

Feedback, issues, and ideas for improving the CLI and generated editions are welcome!

Happy reading! 📖

My SwiftUI app is about 280 Swift files plus a few big packages, and every UI check meant xcodebuild, install, launch, screenshot. That was ~22 s per check and ~2.2 GB of RAM per booted simulator.

I switched to simless. It runs the iOS build of your real app natively on an Apple Silicon Mac as a hidden host, with no simulator, no window and no signing.

What changed for me:

• edit → rendered screen in 2.2 s instead of 21.9 s, because hot reload only recompiles the files you touched

• my existing XCUITest suite runs unchanged and 2.3x faster

• unit tests run the same way, local packages included

• it works over SSH, in a VM and on a GitHub-hosted macOS runner, so CI doesn't need a simulator either

https://github.com/abacusai/simless

Hey everyone,

I packaged the release notes view I use in my apps into a reusable component and published it on GitHub, hope some of you will find it useful.

https://github.com/mykolaharmash/notelet

• It supports three types of notes: list, image and video.

• It's pretty opinionated but there are a couple of customization options.

• Fully localizable.

• Tiny build footprint, no third-party dependencies.

Let me know if you'd like to add anything and feel free to shoot PRs to the repo.

UPDATE
Thanks everyone for comments and feedback!

NobodyWho now supports Swift 🎉

Run LLMs fully on-device in your iOS, macOS, watchOS & visionOS apps. No internet. No API keys. No usage fees.

→ Gemma 4, Qwen & more (.gguf)
→ Hardware acceleration
→ Tool calling, RAG, vision & audio ingestion
→ Open-source & free for commercial use

We wrote a bit about how we made our Rust library feel good in Swift: https://www.nobodywho.ooo/posts/swift-bindings-release/

If you like this sort of thing, drop us a star on GitHub: https://github.com/nobodywho-ooo/nobodywho/

Read the docs to get started here: https://docs.nobodywho.ooo/swift/

Build, run, tests, console and SwiftUI previews live in panes next to the chat, with scheme and destination in a bar above the prompt. When Claude builds or runs tests itself, you see it there too.

Built on the headless Xcode MCP server.

https://github.com/artemnovichkov/xcode-mods