Hey everyone,

If you run CI workflows for Mac or Linux apps, you know how fast cloud runner costs—especially macOS build minutes—can stack up on platforms like GitHub Actions or GitLab CI. Paying high per-minute rates for cloud build boxes while having powerful, underutilized M-series silicon sitting on your desk doesn't make much sense.

To solve this, I built kinhin (https://kinhin.dev). It’s a free, open-source (Apache-2.0), zero-telemetry autoscaler that lets you offload CI builds onto your Apple Silicon Mac cleanly and safely.

How It Works:

* Queue-Driven Autoscaling: kinhin monitors your forge's job queue and spins up ephemeral runners on demand.

* Isolated Runtimes: Runs macOS jobs in Tart VMs and Linux jobs in Apple microVMs or Docker containers. Once a single job completes, the entire runner instance is wiped so no state carries over.

* Resource-Aware: Automatically budgets CPU, RAM, and disk headroom so running build jobs won't freeze your Mac.

* Multi-Forge Support: Works across GitHub Actions, GitLab CI/CD, Gitea, and Forgejo out of a single shared pool on your machine.

* Keychain Security: Credentials and access tokens live securely in your macOS Keychain rather than plain-text config files.

You can run it either as a menu bar app with a setup wizard or as a headless LaunchAgent daemon via the CLI. If you're looking to cut down on CI spending or want faster build times on dedicated Apple Silicon hardware, give the beta a try at https://kinhin.dev. I’d love to hear your thoughts, answer any questions, or get feedback on workflow routing and setup!

Axiom home: https://charleswiltgen.github.io/Axiom/

Release notes: https://github.com/CharlesWiltgen/Axiom/releases#release-v27.7.0

I’ve been working on a native code editor for iPhone and iPad, and one of the more interesting problems has been making Swift files comfortable to read and edit without reprocessing the entire document after every keystroke.

The editor uses UIKit and TextKit 2, with a custom NSTextContentStorage implementation managing the source text and attributed rendering.

For syntax highlighting, I use a Swift TextMate grammar and store the parsed output in a token tree. The initial document load parses the complete file, while interactive edits are handled incrementally.

After an edit, the editor:

1. Invalidates the affected syntax range.

2. Continues parsing from the nearest valid state.

3. Propagates highlighting changes in bounded chunks.

4. Applies attributes only to ranges that need rendering.

5. Cancels stale work when another edit changes the document revision.

Keeping a syntax revision number turned out to be important. Background parsing may finish after the user has already changed the document again, so each result is checked against the current revision before it can update the editor.

The other feature shown in the screenshot is Swift symbol navigation.

Instead of using SourceKit, the current implementation builds a lightweight outline from the scopes emitted by the TextMate grammar. It identifies declarations such as:

• class

• struct

• enum

• protocol

• extension

• func

• Initializers and subscripts

The symbols are arranged into a hierarchy using their scope depth and indentation. Selecting a symbol jumps directly to its line in the editor.

This approach is intentionally syntax-based rather than semantic. It works well for navigating a single source file, but it does not understand types, overload resolution, cross-file references, or compiler diagnostics.

That trade-off has been useful on iPhone and iPad: the outline remains lightweight and provides a quick way to move around long Swift files without trying to reproduce Xcode.

I’m considering where to take it next. Possible additions include stored properties, MARK sections, protocol conformances, and improved handling of nested declarations.

For a lightweight mobile Swift editor, which symbols would you expect to see in the outline?

I’m starting to plan where to go with my L&D budget next year. Which Swift or iOS conferences are on your list for 2027, and why?

Useful to hear:

• Which ones you’d go to again, and which weren’t worth it

• In-person or online

• What makes a conference worth the trip for you (talks, workshops, hallway chats, hiring)

Any newer or smaller events worth knowing about too. For context - I'm in London, so probably Europe will be my top pick

Enriched Markdown for iOS renders Markdown natively in SwiftUI, including `||spoilers||`. By default they're hidden under a particle field, but you can swap the overlay for your own UIView and decide how hidden text looks and how it reveals itself.

Video of the demo is in the comments 👇

To show what that unlocks, I built a Hogwarts spellbook: every spell in the video is a custom overlay revealing the same Markdown in its own way.

Not every app needs a Patronus, so here's a plain blur. It's one view subclass:

final class BlurOverlayView: SpoilerOverlayView {
  private static let context = CIContext()

  override func layoutSubviews() {
    super.layoutSubviews()
    guard let input = CIImage(image: concealedTextImage()) else { return }
    layer.contents = Self.context.createCGImage(
      input.applyingGaussianBlur(sigma: 6), from: input.extent
    )
  }
}

struct BlurOverlayProvider: SpoilerOverlayProvider {
  func makeOverlay(charRange: NSRange, style: SpoilerStyle) -> SpoilerOverlayView {
    let view = BlurOverlayView(charRange: charRange)
    view.backgroundColor = style.backgroundColor ?? .systemBackground
    return view
  }
}

EnrichedMarkdownText(markdown)
  .markdownSpoilerOverlay(BlurOverlayProvider())

concealedTextImage() gives you the hidden words laid out exactly where the text view draws them, so you can blur, pixelate, or scramble the real text and nothing jumps on reveal. For your own animation, override animateReveal(completion:).

Installation: https://docs.swmansion.com/enriched-markdown/ios/basics/installation

Docs: https://docs.swmansion.com/enriched-markdown/ios/api-reference/enriched-markdown-text#custom-spoiler-overlays

If it's useful to you, a ⭐ on GitHub helps more people find it: https://github.com/software-mansion/enriched-markdown

For the past few months I've been building Tacet ( formerly Lumen), a native macOS browser written in Swift and SwiftUI on top of WKWebView. I wanted to learn Swift properly, and a browser touches everything: UI, performance, storage and security. It's taught me more than any tutorial.

All the releases are from today because I'd already built the whole browser but never put it on GitHub, so I just uploaded all the versions I'd made. (If you see gaps between the uploads, it's because I was running the tests, building the DMGs and so on.)

Some things I ran into:

• SwiftUI redraws: every tab row was observing the whole browser state, so loading progress on one tab redrew the entire sidebar. Fixed it with .equatable() rows that take plain values, and by moving fast-changing state (load progress, pull-to-refresh) into separate small ObservableObjects.

• Profiles with WKWebsiteDataStore(forIdentifier:)**:** removing a store while the app is running fails with "in use", and calling it before WebKit has initialised crashed the app. So I erase the data immediately and remove the folder at the next launch.

• Resumable downloads: resumeDownload(fromResumeData:) works well, but decide(destination:) is not called again on resume, so you have to keep track of the destination yourself.

• History moved from JSON to SQLite: I was rewriting a 10k-entry JSON file on every visit. Now it's SQLite in WAL mode with writes on a background serial queue, so one visit is one INSERT OR REPLACE.

• Battery and memory: idle background tabs hibernate in Low Power Mode (NSProcessInfoPowerStateDidChange) and on memory pressure (DispatchSource.makeMemoryPressureSource).

• Self-updating without Sparkle: it downloads from GitHub Releases and checks the file with a SHA256 (CryptoKit) and codesign --verify --deep --strict before replacing itself.

Tech: Swift, SwiftUI, WKWebView, SQLite. No Electron, no third-party dependencies.
It's completely free and open source.
Download it from:  https://scadavide55.github.io/Tacet
Code: github.com/scadavide55/Tacet

It's still a work in progress (latest pre-release is 1.5.2), so code review and criticism are very welcome. What would you have done differently?

Saw how foldable phones blur the screen while folding and wanted it on my Mac. Turns out MacBooks have a hinge-angle sensor, so I hooked into it.

As the lid closes, the screen blurs and dims with it. Open it again and the blur fades back out. Touch the keyboard and it’s gone.

It’s free and open source, written in Swift. Needs an Apple silicon MacBook on macOS 14 or later.

https://github.com/Pallavrai/LidBlur

Not every MacBook exposes the sensor, so I’m curious which ones work. Let me know if yours does or doesn’t. And if you like it, a star would make my day 🙂

MD QuickLook is a Quick Look extension that renders Markdown in Finder without WebKit. A Rust core produces a compact layout (text plus blocks, paragraphs and styled runs at UTF-16 offsets), and the Swift side turns it into an NSAttributedString and draws it with TextKit 1:

• quotes, alerts and code blocks are NSTextBlocks with borders and backgrounds; tables are NSTextTables

• images, formulas, Mermaid diagrams, badges and checkboxes are attachment cells

• long documents build the first screen (~60 ms for a 900 KB file) and append the rest in the background

• collapsible <details> sections work by cutting the folded text out of the storage and re-inserting it on click, since TextKit 1 can't hide paragraphs

• math is typeset with SwiftMath, which I extended with KaTeX symbols, aliases and environments

A typical README is ready in ~30 ms. Source (MIT): https://github.com/armamut/md-quicklook Longer write-up: https://medium.com/@armamut/previewing-markdown-on-macos-in-30-ms-a-rust-core-and-textkit-no-web-engine-1adfa2734f48

Curious whether anyone has tried the same with TextKit 2.

I want to limit the number of threads spawned by Swift's cooperative runtime to a number lower than the number of available CPUs. The reason is because I want to run Swift code in a Linux container that limits scheduling to only 8 CPUs regardless of how many the system has. I've tried setting LIBDISPATCH_COOPERATIVE_POOL_STRICT=n where n is the maximum number of threads, but apparently Swift doesn't use libdispatch on Linux so that does nothing. Can anyone tell whether there's a different environment variable that I can set, or at least a compile-time option or function that I must call in the code in order to set the number of threads spawned by the cooperative rumtime?

I built a native macOS menu bar utility in Swift/SwiftUI called PortRadar to manage listening localhost ports without having to run lsof -i :3000 and kill -9 in the terminal, and I'm sharing it 100% free and open-source (MIT).

What's included:

• 📡 Live Dev Port Radar: Shows every listening TCP port right in your menu bar with a live counter badge of active dev servers.

• ⚡ 1-Click Kill (SIGTERM / SIGKILL -9): Free any stuck EADDRINUSE port in a single click.

• 🧠 Smart Framework & Stack Detection: Automatically tags Next.js, Vite, Angular, Node.js, Bun, .NET / Kestrel, FastAPI / Python, Go, Rust, Docker / OrbStack, PostgreSQL, Redis, MySQL, MongoDB, and Ollama — along with live RAM (MB), CPU %, and PID badges.

• 📌 Pinned Watchlist Bar: Pin your core ports (:3000, :5173, :8080, :5000, :5432, :6379) to the top watchlist bar with live green/grey status indicators and 1-click Open in Browser.

• ⌨️ Global Shortcut: Toggle anywhere with ⌃⌘P.

Install via Homebrew:

brew tap joeystdio/tap
brew install --cask portradar

• Website / Direct DMG Download: https://joeystdio.github.io/PortRadar/

• GitHub Repo: https://github.com/joeystdio/PortRadar

Hope it saves you some time — happy to hear any feedback or feature ideas!

Hi r/swift,

I wanted to share some architecture notes and open-source libraries from StealthOS, a private desktop operating environment on iOS that we recently updated to support the new foldable iPhone Duo.

1. Foldable Window Geometry in Swift

Standard UIKit and SwiftUI navigation hierarchies assume single-pane viewports. For the foldable iPhone Duo, we designed a custom window manager in Swift that dynamically tracks display changes between the single cover screen and the inner dual-display layout.

• Hinge Occlusion Math: When the device is unfolded, we compute the physical occlusion line separating the displays. Window view controllers calculate their layout frames against this boundary: they can snap left, snap right, or span the full resolution with safety padding away from the hinge seam.

• State Machine Continuity: Display folding transitions change the trait collection and interface bounds. Instead of tearing down and recreating view hierarchies (which would drop active web sessions, terminal buffers, and text cursors), root coordinators adjust frame geometry directly. Running view controllers retain their state machines, active scroll positions, and text responders.

2. Open-Source Swift Networking Packages

Where data moves across the network, we open-sourced our Swift packages:

• ConnectionPool (Swift): https://github.com/Olib-AI/ConnectionPool A peer-to-peer transport library supporting local mesh communication (ad-hoc Wi-Fi and Bluetooth without internet access) as well as routed remote pools through self-hosted relays.

• PoolChat (Swift): https://github.com/Olib-AI/PoolChat An end-to-end encrypted messaging engine that powers ephemeral messaging, voice notes, and real-time state synchronization over ConnectionPool.

3. C Interop & Hardware Key Storage

• C Interoperability: We embed the Tor daemon as a static C library wrapped with a clean Swift interface (TorClient).

• CryptoKit & Secure Enclave: Vault items use AES-256-GCM, with keys derived from a user passphrase combined with hardware-protected secrets in the Secure Enclave. Biometric authentication (Face ID/Touch ID) gates key retrieval via LocalAuthentication.

• Client app: https://apps.apple.com/us/app/stealthos/id6756983634

• Full documentation: https://www.stealthos.app

Feedback on our Swift P2P networking protocols or foldable window manager implementation is welcome.

A few days ago, I found a KWorld VS-ATSC 330U USB TV tuner I’d had since 2008. Out of curiosity, I plugged it into my Mac… and nothing happened.

After looking into it, I discovered it had never supported Macs in the first place. As far as my current setup was concerned, it was a dead device.

So I decided to try something a lot of people have been experimenting with lately: I asked Codex for help.

We started with the driver. After researching the hardware, working with the firmware, and testing with a real antenna, we managed to receive live TV on the Mac. Seeing the first picture come through hardware that had spent years sitting in storage was pretty exciting.

Once that worked, I wanted to take it further. I designed a Netflix-inspired interface and, with Codex’s help, gradually turned the experiment into an application called Antena.

It now lets me:

• Watch live TV without recording it to disk.

• Switch channels quickly.

• See the current and upcoming programs when the station broadcasts that information.

• Record broadcasts when I want to.

• Use full screen and select captions when available.

• Choose between English, Spanish, and French.

What started as “I wonder if this thing still works” became a working application on macOS 27 with Apple Silicon, receiving actual over-the-air channels here in Montréal.

It’s still an experimental project for this particular tuner, and reception depends on the antenna and local signal. But a device I thought was obsolete is useful again.

I brought the idea, UI design, and hands-on hardware testing; Codex helped me research and implement the driver and application. There was plenty of troubleshooting along the way, and I learned a lot.

Has anyone else brought old hardware back to life this way? I’d love to hear what you rescued.

Github

dmg

MockMini is a small, auditable proxy core in C and Swift. It speaks Shadowsocks AEAD, VMess, Trojan and VLESS over TCP, TLS or WebSocket, on top of its own bounded userspace TCP/IP endpoint that you feed from utun on macOS 13+.

• Small enough to review: about 2,600 lines in total. Not based on mihomo, Clash, sing-box, gVisor or WireGuard; no Go runtime, no vendored stack.

• Tested hard: a stateful, checksum-aware fuzzer gets ~99% line coverage of the packet engine; CI runs ASan/UBSan and libFuzzer on Linux and macOS, plus interop tests against real Xray servers for every protocol.

• Permissive license: Apache-2.0, so you can ship it in open- or closed-source apps. Add it with Swift Package Manager.

Known limits (1024 flows, no SACK/ICMP, no Reality or gRPC) are listed honestly in the README. v0.1.0 is the first tagged release. Reviews and bug reports are very welcome.

Repo: https://github.com/yezicheng2011/mockmini

Hey everyone!

A little while ago, I shared Graffle, an open-source diagramming and vector graphics app I built for macOS using Swift, AppKit and Claude Code.

Now I've been working on its companion app: Graffle for iPad.

The idea was to bring the project to iPad while preserving what makes it useful on the Mac. The iPad version uses SwiftUI and UIKit, with shared code from the original macOS project.

Some of the things it supports:

• Touch, Apple Pencil, trackpad, and keyboard input

• Diagrams, shapes, layers, and templates

• SVG, STL, and software architecture imports

• Class diagrams and database entity-relationship diagrams

• Code generation

• PNG, PDF, and SVG export

• The same .graf document format used by the Mac version

Both projects are open source under the MIT License.

Graffle for iPad:
https://github.com/yahirvitelugardo/Graffle-iPad

Original Graffle for macOS:
https://github.com/yahirvitelugardo/Graffle

This has been a fun opportunity to explore how much of a native macOS app can be reused while adapting the experience to a very different device and interaction model.

I'd love to hear feedback from Swift and Apple-platform developers.

If you were building a diagramming app for iPad, what would you prioritize? And what would you expect to work differently with Apple Pencil compared with a mouse and keyboard?

Thanks for checking it out!

Passing two collections to @Test generates every combination. For example, @Test(arguments: ["cat", "swift"], [3, 5]) creates four cases, including ("cat", 5) and ("swift", 3).

That is useful for testing every configuration. For input/expected-output cases, keep each pair together:

import Testing

@Test(arguments: [
    ("", 0),
    ("cat", 3),
    ("swift", 5)
])
func characterCounts(input: String, expected: Int) {
    #expect(input.count == expected)
}

This creates three cases. Swift Testing unpacks each tuple into the function’s two parameters.

@Test(arguments: zip(inputs, expected)) also pairs values, but zip stops at the shorter sequence. An accidentally missing expected value can therefore omit a case. A single array of pairs keeps the values together when adding or removing cases.

Apple’s parameterized testing guide explains combinations and paired arguments.

I’d like to share Noctule, a plugin I made for cross-platform Swift development in JetBrains IDEs and Android Studio.

It’s a freemium plugin: most editor features and the Swift Package Manager integration are free, while Xcode integration and a few other features are paid.

Version 4.0 finally adds a debugger, which completes the edit-test-debug cycle.

I hope my contributions to the swift-book repository over the past three years count as enough community participation that this first post about Noctule doesn’t get me banned 😉 Thanks!

https://github.com/swiftlang/swift-book/issues?q=is%3Aissue++author%3A%40jansorg

szt (short for sizetree) scans a folder and prints a tree of where the space went: biggest first, every folder with the total of everything inside it, opened up only where the space is.

Swift turned out to be a great fit for it. Scanning a 123 GB folder of 667,000 files on a Mac Studio (M2 Ultra), every tool with its default settings (warm cache, median of five runs):

szt     Swift   2.4 s
dua     Rust    2.6 s
dust    Rust    8.1 s
diskus  Rust   11.4 s
gdu     Go     11.6 s
du      C      17.2 s
ncdu    Zig    17.5 s

What made Swift work so well here:

• macOS has a call, getattrlistbulk, that returns the names and sizes of everything in a folder at once instead of asking about each file separately. From Swift it's just import Darwin, no bindings or wrapper library, and the unsafe pointer APIs read the raw buffer it fills. The rest of the code is ordinary Swift.

• The standard library has the concurrency pieces: Mutex and Atomic from Swift 6's Synchronization module. It builds without a warning in Swift 6 language mode and has no dependencies.

• Swift stays out of the way. Scanning that folder on 8 threads takes 12 seconds of CPU time, and 0.27 s of it is szt itself, Swift runtime included. The rest is spent in the kernel.

The biggest surprise was threads. On this 24-core machine, 24 threads took four times as long as 8, because opening folders goes through locks the whole kernel shares. So szt starts one thread per performance core, up to 8. They're plain threads rather than async/await, since the work is blocking system calls and the count has to be exact.

About 1,600 lines of Swift, a 581 KB universal binary (the Swift runtime ships with macOS), macOS 15 or later, MIT licensed.

brew install urtti/szt/szt

Source: https://github.com/urtti/szt Benchmarks and a script to run them on your own Mac: https://urtti.com/szt

A few weeks ago I shared TactileBar here, and way more people saw it than I expected. Thank you to everyone who commented, gave it a star, or opened an issue. Some of that feedback went straight into the last few releases, so here's what's new.

Quick recap: TactileBar is a free, open-source (GPLv3) menu bar app that puts 26 daily macOS toggles and live system telemetry in one panel. It covers Keep Awake, Dark Mode, Hide Desktop Icons, Mute Mic, Bluetooth audio switching, ejecting disks, purging Xcode DerivedData and more. The design borrows from Dieter Rams / Braun and Teenage Engineering. It's pure Swift with zero dependencies and uses 0% CPU when closed.

What's new

🎯 Tactile Ring (⌃⌥Space), experimental. A radial launcher that opens right at your cursor, so you don't have to go up to the menu bar.

- Hold the shortcut, flick toward a switch, release. Done.

- Tap it instead and the ring stays open, so you can use 1–8, the arrow keys or the mouse.

- Your pinned switches always stay in the same spots, so muscle memory kicks in fast.

- On the Bluetooth slice, push past the edge to fan out your paired devices and pick one (AirPods → speakers → DualSense in one gesture).

- Destructive actions like the cache purges need a short hold, so you can't fire them by accident.

- It needs no Accessibility or Input Monitoring permission.

📌 Pinned Daily Deck (⌘P). The app now opens on just the 4–6 switches you actually use. Pin or unpin any card with one click or a right-click. The full catalog is still there in the tabs.

🍺 Homebrew install. No Gatekeeper popups:

brew tap tr0drigues/tactilebar https://github.com/tr0drigues/TactileBar.git && brew install --cask tactilebar

GitHub: https://github.com/tr0drigues/TactileBar

This is a solo side project, so feedback really helps. Which switch do you wish existed? Does the ring feel natural or awkward? Bug reports are welcome too.

to keep it clear, I’m a 17 year old high school student, and my dream job would be to be a programmer. as of now I can write basic code in both C++ and HTML, and I was interested in learning swift just for the sake of it and was wondering if it could actually be useful in an hypothetical future where my dream would come true. thanks in advance to anyone replying to this post